Page MenuHomePhorge

Sender, X-Sender and X-Authenticated-As mail headers
Open, NormalPublic


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 cannot just send out messages using an envelope sender address of -- 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., 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 sends an email with an envelope sender address of, we find that the X-Sender address is added -- seemingly without purpose.

When a user ( 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).


Ticket Type

Event Timeline

$headers['X-Sender'] = $from;
is actually hardcoded in

Actually, the sender is also hard coded in /usr/share/roundcubemail/plugins/kolab_delegation/kolab_delegation_engine.php :

// add Sender: header with current user default identity
if ($context) {
    $identity = $this->rc->user->get_identity();
    $sender   = format_email_recipient($identity['email'], $identity['name']);

    $message->headers(array('Sender' => $sender), false, true);

it does not take account of "sender_header" or "xsender_header".

vanmeeuwen lowered the priority of this task from 60 to Normal.Mar 28 2019, 8:13 AM

If the user sends e-mail via an e-mail client to the SMTP server, the presence and content of these headers is controlled by /usr/lib/postfix/kolab_smtp_access_policy which is configured in /etc/kolab/kolab.conf. Reading the source code of the former, I found that X-Authenticated-As: is only being added if an encryption key sender_header_enc_key is set in the kolab.conf. Setting this also avoids setting Sender: and X-Sender: headers (Off-topic: which contained the kolab user name in my case instead of the primary e-mail address). So now I have

cache_uri = mysql://kolab:xxxx@localhost/kolab
cache_retention = 86400
address_search_attrs = mail, alias
delegate_sender_header = True
alias_sender_header = True
sender_header = True
xsender_header = True
empty_sender_hosts =,
sender_header_enc_key = xxxxx

and no Sender: nor X-Sender: headers are being added any more, which is nice because Outlook users do not try to reply to my kolab username any more. But the behaviour is not obvious from the above settings, one needs to consult the script to find out why it behaves the way it does.