Re: [Mailman-Users] Sender Field - was: (no subject)

[Mark Sapiro]

Everett Johnson wrote:

>Why is it normal for a bounce processor to be the sender when there are 
>no bounces?  This confuses some list members.

It is done because there are/used to be non-compliant MTAs that would
return bounces to the Sender: instead of the envelope sender. There
was an extensive discussion of this last month beginning at
.

Also see the FAQ on this at
.

-- 
Mark Sapiro <[EMAIL PROTECTED]>   The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Users] Sender field

[James Ralston]

On 2006-04-27 at 22:46-05 Brad Knowles <[EMAIL PROTECTED]> wrote:

> At 10:40 AM -0500 2006-04-27, Neal Groothuis wrote:
> 
> > Again from RFC 2822 3.6.2, the Sender: header should contain the
> > address of the agent responsible for transmitting the message,
> > meaning that a person who sends mail to the address in that header
> > should expect to reach said agent, not suggest to Mailman that a
> > message bounced.
> 
> Right.  Mailman is the agent responsible for transmitting the
> message, and this needs to be reflected.

This is not correct.  Quoting RFC2822 section 3.6.2:

3.6.2. Originator fields

The originator fields indicate the mailbox(es) of the source of
the message.  The "From:" field specifies the author(s) of the
message, that is, the mailbox(es) of the person(s) or system(s)
responsible for the writing of the message.  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.

The Sender header should be employed by the orignator of the message,
and only the originator.  Mailman is not the originator of a message
sent to a list; it is merely a relay agent.

I will grant that the phrasing of the RFC is suboptimal here--it uses
"transmission" when a better word choice would have been "submission".
But the immediately proceeding example (of a secretary sending mail on
behalf of another person) clarifies the intent beyond any claim of
ambiguity.

> [Outlook's behavior] is an MUA problem.  See FAQ 2.3.

No, it's not.  As much as it pains me to say it, Outlook's behavior
matches perfectly the intent of the RFC.  It is Mailman's behavior of
rewriting the Sender header that is the problem.

> However, we want to make sure to capture any potential messages that
> may be routed to the "Sender:" field and have them automatically
> processed through the part of the system that is designed to do that
> sort of thing.

Mailman's "processing" behavior is to treat a reply to the Sender as a
bounce.  This is incorrect behavior, because many mail clients will
include address of the Sender header in a "reply-to-all" function,
causing Mailman to treat the reply as a bounce.

So, in summary, the disadvantages of Mailman's behavior of rewriting
the Sender header is that doing so is not in the intended spirit of
RFC2822, causes subscription grief, and breaks Outlook.  The advantage
is that it helps Mailman detect bounces from a slim minority of
brain-dead MTAs that send bounces to the Sender header.

> The problem is that you said you wanted to implement an option to
> allow people to turn it off, not to rip this feature completely out
> of the system.

I would argue that the best course of action is to excise Sender
header rewriting entirely and provide no option to turn it on.
(Mailman has way too many options already.)

If, however, an option is created to control the behavior, it should
definitely default to OFF (no Sender header rewriting), not on.

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA

--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Users] Sender field

[Neal Groothuis]

It does not appear that Mailman modifies the "Sender:" field to comply 
with RFC 2822.  The list-bounces address is not the mailbox of the agent 
responsible for transmitting the message, as required in section 3.6.2. 
 The mailbox of the agent responsible for the transmission of the 
message would be the list-owner address.


Mailman's use the "Sender:" field does not seem to be in line with the 
intent of the RFC, nor with current usage of the field.   The example 
given in the RFC is of a secretary sending an email on behalf of someone 
else.  Outlook obviously interprets it this way.  Some versions of 
Thunderbird display both the Sender: and From: lines to the user, which 
may prove confusing if the Sender: address is not a person or an obvious 
alias for one.  Gmail uses it if you choose a "From" address that is not 
your gmail.com address.


Further, if Mailman is going to change the "Sender:" field, it should 
add Resent-* headers, per section 3.6.6 of RFC 2822; otherwise, the 
original sender information is lost.  The RFC does say that this is to 
be used when "users" reintroduce a message into the system, further 
providing evidence that automated components of the mail routing system 
shouldn't be changing these.  (Note that MTAs don't change the Sender: 
field, despite being, by their nature, agents responsible for 
transmission of messages.)


RFC 2369 provides headers which are to be used by mail list software to 
identify the various ways of interacting with the list, and Mailman 
already adds them.  This makes adding this information to the Sender: 
field redundant.


Based on all of this, Mark's note that there are some MTAs which bounce 
to the Sender: address is the only reason that I've seen why this 
behavior should continue.  Does anyone know what MTAs these are, or if 
they're even still in use?  If these buggy MTAs are common, I would 
suggest that an option be added to the list to enable this behavior, 
marked as an accomodation for buggy MTAs, and defaulting to "off".  I'll 
see if I can scrounge up the time to submit a patch to accomplish this, 
if it'll actually get included in a future release; otherwise I won't 
waste my time.  If these MTAs are not in use, I stand by my original 
recommendation to comment out/remove the two lines responsible for the 
behavior.


At any rate, the "keep patching" suggestion is unhelpful.   This is 
obviously a problem that many people are running into, enough that 
there's a FAQ entry about it.  It should be addressed.
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Users] Sender field

[Brad Knowles]

At 10:40 AM -0500 2006-04-27, Neal Groothuis wrote:

>  I would like to request that a feature be added in the next version of
>  Mailman to allow a list administrator to disable rewriting of the
>  "Sender:" header, or (better) for this behavior to be eliminated from
>  Mailman altogether.

Have you filed an RFE at the appropriate SourceForge page for Mailman?

>   - Outlook treats the Sender field as a person sending on behalf of
>  another.  This seems to me to be a reasonable interpretation of the
>  Sender field, per RFC 2822 3.6.2.  When a "bounces" address is included
>  in the sender field, Outlook displays something along the lines of "From
>  [EMAIL PROTECTED] On behalf of
>  [EMAIL PROTECTED]".  (See Mailman FAQ entry 2.3).  This is undesirable.

This is an MUA problem.  See FAQ 2.3.

>   - Useful information (the original content of the Sender: header) is
>  lost by doing this.

If the previous value of the "Sender:" field is being lost, then 
that should be corrected.  At the very least, the value should be 
saved in an "Old-Sender:" or "Previous-Sender:" or some other 
suitable renamed sender field.

>   - Bounces go to the envelope sender or Return-Path: header, not the
>  Sender: header, so this is not necessary for proper bounce handling.

Mailman does not modify this header for the purpose of routing 
bounces to the appropriate place.  Mailman modifies this header 
because the original "From:" header is left unchanged and the RFC 
specifies that we should indicate when the message has been forwarded 
or sent by someone/something else on behalf of the entity in the 
"From:" field.

>   - Again from RFC 2822 3.6.2, the Sender: header should contain the
>  address of the agent responsible for transmitting the message, meaning
>  that a person who sends mail to the address in that header should expect
>  to reach said agent, not suggest to Mailman that a message bounced.

Right.  Mailman is the agent responsible for transmitting the 
message, and this needs to be reflected.  However, we want to make 
sure to capture any potential messages that may be routed to the 
"Sender:" field and have them automatically processed through the 
part of the system that is designed to do that sort of thing.

>   - Information regarding interacting with the list is provided by the
>  List-* headers; including it in the Sender: field is unnecessary.

No, it is necessary.  It's required by the RFCs.

>  Removing this (IMO) unwanted functionality is trivial:

The problem is that you said you wanted to implement an option to 
allow people to turn it off, not to rip this feature completely out 
of the system.

Implementing the option and putting in the necessary UI features 
so that site and list administrators can choose whether or not to 
modify the headers in this way is a considerably more complex task 
than just ripping out a feature you don't like.


Give us some suitable code to make this feature optional and 
controllable by the site admin (and something that can be delegated 
to the list admin), and you'll have a much better chance of getting 
someone to pay attention to your request.

Otherwise, keep applying the patch to each new version of Mailman 
as you install it.

-- 
Brad Knowles, <[EMAIL PROTECTED]>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

 -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
 Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See .
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

Re: [Mailman-Users] Sender field

[Mark Sapiro]

Neal Groothuis wrote:
>
>I would like to request that a feature be added in the next version of
>Mailman to allow a list administrator to disable rewriting of the
>"Sender:" header, or (better) for this behavior to be eliminated from
>Mailman altogether.


The best place to make this kind of request is in FeatureRequests in
the sourceforge.net tracker, and it is already there at
http://sourceforge.net/tracker/index.php?func=detail&aid=1460796&group_id=103&atid=350103.
Please look at that item and add your own comments as you wish.

Note however that there is motivation for keeping the Sender behavior
as is because there are still broken MTAs that will return bounces to
the Sender:, so anything that actually is implemented would likely be
an option with current behavior as the default.

Also, RFC 2822 arguably requires a Sender: header in the case of a list
sending mail on behalf of a poster.

-- 
Mark Sapiro <[EMAIL PROTECTED]>   The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp

[Mailman-Users] Sender field

[Neal Groothuis]

To reopen an old discussion:

I would like to request that a feature be added in the next version of
Mailman to allow a list administrator to disable rewriting of the
"Sender:" header, or (better) for this behavior to be eliminated from
Mailman altogether.

Rationale:

 - Outlook treats the Sender field as a person sending on behalf of
another.  This seems to me to be a reasonable interpretation of the
Sender field, per RFC 2822 3.6.2.  When a "bounces" address is included
in the sender field, Outlook displays something along the lines of "From
[EMAIL PROTECTED] On behalf of
[EMAIL PROTECTED]".  (See Mailman FAQ entry 2.3).  This is undesirable.

 - Thunderbird also displays the sender field, which presents similar
confusion.

 - Useful information (the original content of the Sender: header) is
lost by doing this.

 - Bounces go to the envelope sender or Return-Path: header, not the
Sender: header, so this is not necessary for proper bounce handling.

 - Again from RFC 2822 3.6.2, the Sender: header should contain the
address of the agent responsible for transmitting the message, meaning
that a person who sends mail to the address in that header should expect
to reach said agent, not suggest to Mailman that a message bounced.

 - Information regarding interacting with the list is provided by the
List-* headers; including it in the Sender: field is unnecessary.


Removing this (IMO) unwanted functionality is trivial:

diff -ru mailman-2.1.5.orig/Mailman/Handlers/SMTPDirect.py 
mailman-2.1.5/Mailman

/Handlers/SMTPDirect.py
--- mailman-2.1.5.orig/Mailman/Handlers/SMTPDirect.py   2004-01-22 
17:02:07.

0 -0600
+++ mailman-2.1.5/Mailman/Handlers/SMTPDirect.py2006-04-26 
13:48:45.

0 -0500
@@ -348,9 +348,9 @@
 # the Sender header at all.  Brad Knowles points out that MTAs tend to
 # wipe existing Return-Path headers, and old MTAs may still honor
 # Errors-To while new ones will at worst ignore the header.
-del msg['sender']
+# del msg['sender']
 del msg['errors-to']
-msg['Sender'] = envsender
+# msg['Sender'] = envsender
 msg['Errors-To'] = envsender
 # Get the plain, flattened text of the message, sans unixfrom
 msgtext = msg.as_string()

--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Security Policy: 
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp