When an email is sent via a Kolab SMTP server, it is the SMTP Access Policy that ensures the user who sends the message is authorized to send mail using the envelope sender address associated with the email.
This preserves the integrity of communications, such that a user firstname.lastname@example.org cannot just send out messages using an envelope sender address of email@example.com -- unless specifically permitted.
This would enable the recipient to trust and verify that the user who sent the message is authorized to do so.
To allow the recipient to verify who sent the message, the SMTP Access Policy may add either or both of Sender and X-Sender headers to the email, the contents of which refer directly to the canonical result attribute of the user authenticated.
For cases where the actual user who sends the message needs to remain undisclosed (i.e. firstname.lastname@example.org), we offer a configuration option that should suppress the use of plaintext Sender and X-Sender headers, and instead uses an encrypted X-Authenticated-As header. The recipient is then left with verification on whether or not a second email originates from the same actual user as a first email.
In a standard deployment however, when email@example.com sends an email with an envelope sender address of firstname.lastname@example.org, we find that the X-Sender address is added -- seemingly without purpose.
When a user (email@example.com) sends an email using an envelope sender address for which the user himself is not also the recipient, i.e. "a delegated address", Sender and/or X-Sender headers allow the recipient to determine that it was John who sent the message.
Furthermore, we've had reports of Sender or X-Sender addresses being added despite X-Authenticated-As being the intentional target for the user's authentication.
Long story short, we need to create inventory on which programs may add headers themselves (the SMTP Access Policy has no way to remove existing headers), determine their configuration options to suppress them from doing so (if any), assess whether or not the MTA needs to be configured to strip these headers (if no configuration options are available).