May 11

url referer :

Some users of the MS Outlook MUA find that mail they receive that has been sent out by a Mailman list server is displayed on the Outlook GUI with a ‘From’ field that is structured like this:

From On behalf of

or this,

From On behalf of

or even this:

From On behalf of

This is because of the way Microsoft software including Hotmail/Windows Live Mail and many versions of Outlook interpret the meaning of the Sender header. Here is the relevant passage from RFC2822:

The “Sender:” field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the “Sender:” field and the mailbox of the actual author would appear in the “From:” field. If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the “Sender:” field SHOULD NOT be used. Otherwise, both fields SHOULD appear.


Given this description, Microsoft’s display choice is not entirely unwarranted (surprisingly enough).

This author knows of no way to stop this behaviour by Outlook; if you do then add it to this FAQ page.

Of the three examples given above, the first, using the -admin list alias is what comes from a MM 2.0.x installation.

The second, using the -bounces list alias comes from a MM 2.1 installation.

The third is from a MM 2.1 installation that is sending out VERP’ed e-mail (for more information about VERP see So what is this VERP stuff).

It appears that not all versions of MS Outlook have this behaviour. If you know of versions that do or do not, then add the information to this FAQ page.

MS MUA/Version with the behaviour described:

MS Outlook 2007
MS Outlook 2003 (including SP2)
MS Outlook 2002
MS Outlook 2000

MS MUA/Version without the behaviour described:

MS Outlook Express 6

Note: The change from the -admin suffix to -bounces suffix (introduced by MM 2.1) was to separate the incoming e-mail to Mailman between what was bounced e-mail being returned and what was other administrative stuff. This was part of the changes in 2.1, including VERP’ing, aimed at improving bounce handling.

A partial ‘solution’ to this problem you can try, is a hack at the file $prefix/Mailman/Handlers/ in the MM 2.1.2 released code. If you change line 342 in the function bulkdeliver() from:

msg[‘Sender’] = envsender


msg[‘Sender’] = mlist.GetListEmail()

then it will (hopefully) shorten:




in what the subscriber’s Outlook MUA displays in its ‘From’ field’.

The risk with this hack is that any response sent to the address in the Sender: header gets sent to the list not to the list’s bounce alias. But an MTA generating a bounce message should not be using the address in the Sender: header of the message but the address of the sender from the envelope of the SMTP transaction.

But no warranty with the hack. Take a copy of before you start. Be careful with the editing. Remember source code indentation is syntactically significant with Python. Try some tests, including adding duff mail addresses to your test list to check what happens when things bounce.

The change described below has also been proposed but is questionable because RFC2822 says: ‘The “Sender:” field specifies the mailbox of the agent responsible for the actual transmission of the message’. Which in our case is the mailman list.

Using the listname-bounces or listname aliases seems to be within the spirit of the RFC.

The following suggestion proposes having no Sender: header or leaving the incoming Sender: header intact. This does not seem to be a valid interpretation of the RFC; nevertheless, you can comment out a line in $PREFIX/Mailman/Handlers/ in Mailman 2.1.x released code in the function bulkdeliver(). You end up with:

#msg[‘Sender’] = envsender

And then restart mailman: $prefix/mailman/bin/mailmanctl restart

Leave a Reply