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 <http://www.lopsa.org/>.
------------------------------------------------------
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
