|
Size: 5249
Comment:
|
← Revision 9 as of 2010-10-12 18:47:52 ⇥
Size: 5097
Comment: Migrated to Confluence 4.0
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #pragma page-filename DOC/versions/4292740 | #pragma page-filename DOC/versions/4030534 |
| Line 3: | Line 3: |
| Line 21: | Line 22: |
| This is because of the way Outlook (in certain versions; see below) interprets the meaning of the Sender header. Here is the relevant passage from RFC822: | 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: =================================<<BR>> 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. [[http://www.faqs.org/rfcs/rfc2822.html|http://www.faqs.org/rfcs/rfc2822.html]] |
| Line 25: | Line 30: |
| [[../The "Sender"|The "Sender"]] field contains the authenticated identity of the AGENT (person, system or process) that sends the message. It is intended for use when the sender is not the author of the message, or to indicate who among a group of authors actually sent the message. If the contents of the "Sender" field would be completely redundant with the "From" field, then the "Sender" field need not be present and its use is discouraged (though still legal). In particular, the "Sender" field MUST be present if it is NOT the same as the "From" Field. Since the critical function served by the "Sender" field is identification of the agent responsible for sending mail and since computer programs cannot be held accountable for their behavior, it is strongly recommended that when a computer program generates a message, the HUMAN who is responsible for that program be referenced as part of the "Sender" field mailbox specification. [[http://www.faqs.org/rfcs/rfc822.html]] ================================= Given this description of, Microsoft's display choice is not entirely unwarranted (surprisingly enough). |
Given this description, Microsoft's display choice is not entirely unwarranted (surprisingly enough). |
| Line 41: | Line 38: |
| The third is from a MM 2.1 installation that is sending out VERP'ed e-mail (for more information about VERP see [[http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq02.002.htp]]). | 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|So what is this VERP stuff]]). |
| Line 43: | Line 40: |
| It appears that not all version of MS Outlook have this behaviour. If you know of versions that do or do not, then add the information to this FAQ page. | 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. |
| Line 48: | Line 45: |
| MS Outlook 2007 | |
| Line 59: | Line 57: |
| Note: The change from -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. | 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. |
| Line 95: | Line 93: |
| 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: | 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/SMTPDirect.py in Mailman 2.1.x released code in the function bulkdeliver(). You end up with: |
| Line 97: | Line 95: |
| Remark line at $PREFIX/Mailman/Handlers/SMTPDirect.py in Mailman 2.1.6 released code. This line is in the function bulkdeliver(). So, it should be that: #msg[[../'Sender'|'Sender']] = envsender |
{{{ #msg['Sender'] = envsender }}} |
| Line 103: | Line 101: |
| ''Last changed on Thu May 3 22:40:55 2007 by'' Chad Whitacre <<Color2(Converted from the Mailman FAQ Wizard, col=darkgreen)>>This is one of many [[../Frequently Asked Questions|Frequently Asked Questions]]. |
{{{#!wiki caution As of Mailman 2.1.14, if the site accepts the Defaults.py setting "ALLOW_SENDER_OVERRIDES = Yes", there will be an include_sender_header setting on each list's General Options page that controls whether or not Mailman rewrites the Sender: header. }}} Converted from the Mailman FAQ Wizard This is one of many [[../Frequently Asked Questions|Frequently Asked Questions]]. |
2.3. From field displayed by Microsoft Outlook
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 listname-admin@mailman.server.com On behalf of fred@poster.domain.com
or this,
From listname-bounces@mailman.server.com On behalf of fred@poster.domain.com
or even this:
From listname-bounces+jim=reader.domain.com@mailman.server.com On behalf of fred@poster.domain.com
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.
http://www.faqs.org/rfcs/rfc2822.html
=================================
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/SMTPDirect.py in the MM 2.1.2 released code. If you change line 342 in the function bulkdeliver() from:
msg['Sender'] = envsender
to:
msg['Sender'] = mlist.GetListEmail()
then it will (hopefully) shorten:
test-bounces@listdomain.tld
to:
test@listdomain.tld
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 SMTPDirect.py 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/SMTPDirect.py 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
As of Mailman 2.1.14, if the site accepts the Defaults.py setting "ALLOW_SENDER_OVERRIDES = Yes", there will be an include_sender_header setting on each list's General Options page that controls whether or not Mailman rewrites the Sender: header.
Converted from the Mailman FAQ Wizard
This is one of many Frequently Asked Questions.