ClearOS Bug Tracker


View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000869ClearOSapp-zarafa - Zarafa Enginepublic2012-12-04 18:482019-03-14 06:04
Reporterdloper 
Assigned To 
PrioritylowSeverityfeatureReproducibilityalways
StatusclosedResolutionsuspended 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000869: Minor Feature/bug for send as alias for non-primary domain.
DescriptionThis is not the same feature/bug as zarafaSendAsPrivilege!

When you add an alias in ClearOS to the Aliases field in the User module it adds an attribute in OpenLDAP called clearMailAliases. This works great for incoming email. It even works for multiple domains as defined in the smtp server module for destination domains.

However, it does NOT work for sending out AS that alias that is defined. The reason why this is crucial and the zarafaSendAsPrivilege doesn't help here is that for zarafaSendAsPrivilege to work it would have to be a user which consumes a license and setting up a user for an alias is painful. So what does work is having the full email address as an attribute for clearMailAliases. So if my email alias address is testing@example.com then the following apply:

clearMailAliases: testing (works for incoming addresses)
clearMailAliases: testing@example.com (works for outgoing email)

Without the full address the Zarafa will reject sending out as the address.

Currently, the aliases field rejects full email addresses with the error message **mail_extension_mail_alias_is_invalid**

A suggested way to resolve this is to create an attribute for each iteration of an alias on the destination domains.

For example...if the following is the list of domains in the SMTP server:

Domain: domain1.com
Destination Domain: domain2.com
Destination Domain: domain3.com
Destination Domain: domain4.com

and the alias added was: bob

Then the following attributes would be added to the user's account:
clearMailAliases: bob
clearMailAliases: bob@domain2.com
clearMailAliases: bob@domain3.com
clearMailAliases: bob@domain4.com

The email bob@domain1 is NOT added because it is the main domain.

For deletion of alias, the user account should be enumerated for all address in the clearMailAliases and for each where the name deleted exactly matches the string before the @ symbol, an LDAP deletion should be made.

When a destination domain is added to the system, the clearMailAliases attributes which do NOT have an @ in them should be enumerated and the new destination domain should be added to the user's account.

When a destination domain (ie. domain4.com) is removed from the system, the clearMailAliases which contain the [a-z]@domain.com should be removed from the system.

Lastly, full email addresses in the clearMailAliases field can also be used in conjunction distribution groups so that an individual from that distribution group can send as that distribution group. This feature is perhaps too advanced to be added at this time but this is how you would do it. If the attribute exists, the email outbound will pass.

This method avoids disabling security aspects which are meant to be anti spoofing in nature.

TagsNo tags attached.
Attached Files

- Relationships
related to 0000930closeduser2 Disable always_send_delegates by default, expose option in UI 

-  Notes
(0011321)
NickH (developer)
2019-03-14 06:04

Migrated to: https://gitlab.com/clearos/clearcenter/app-kopano/issues/3 [^]

- Issue History
Date Modified Username Field Change
2012-12-04 18:48 dloper New Issue
2012-12-04 18:48 dloper Status new => assigned
2012-12-04 18:48 dloper Assigned To => user2
2013-01-10 13:15 user2 Relationship added related to 0000930
2013-01-10 13:15 user2 Project ClearCenter => ClearOS
2013-01-10 13:15 user2 Category app-zarafa - Zarafa => General
2013-01-29 20:51 user2 Severity minor => feature
2013-01-29 20:51 user2 Category General =>
2013-01-29 20:51 user2 Product Version 6.4.0 =>
2013-01-29 20:51 user2 Target Version 6.4.0 =>
2013-01-31 12:23 user2 Category => app-zarafa - Zarafa Engine
2018-12-14 12:11 user2 Assigned To user2 => tracker
2019-03-14 06:04 NickH Note Added: 0011321
2019-03-14 06:04 NickH Status assigned => closed
2019-03-14 06:04 NickH Assigned To tracker =>
2019-03-14 06:04 NickH Resolution open => suspended