[Mailman-Developers] [Mailman-Users] Sender field
barry at python.org
Sat Apr 29 01:45:46 CEST 2006
Now that I have a few minutes to breath ;) I'll try to summarize my
thoughts on this, and then perhaps go back later and follow up to
specific points later in the thread.
I'm sympathetic to ripping out the Sender: field munging. It was always
primarily a workaround for buggy MTAs. If the majority of MTAs out
there now Do The Right Thing, then of course we want to be RFC
compliant. Outlook's behavior has always been a wart but so far, the
benefits have outweighed the costs. If the benefits are minimal now,
then it should go.
The question that must be answered is: if we no longer munge Sender:
header, what are the right headers to set to increase the likelihood
that bounces will go where we want them to?
I don't care about the minority of still-deployed buggy MTAs that may
send bounces to the wrong place as long as we can be reasonably assured
they won't send them to /some/ wrong places. For example, I think it
would be bad if they started spamming list owners with bounces, very bad
if they spammed the original message authors, and worse if they spammed
the mailing list with bounces. We have almost none of that now and if
we removed the Sender: header and saw a huge increase in this bad
behavior, then the benefits of munging the header go way up.
Of course, we might not know until we start deploying, which would be
too late. I encourage those of you who want to get rid of Sender:
munging to modify your Mailman 2.1 code now and see what happens. :) Of
course, you'll let us know how that goes! My recommendation would be to
record the results in the wiki.
I agree that the RFCs are a bit murky in this area, but it's relatively
clear that the RFC 2822 'secretary' example illustrates the intent of
Sender:. Our list owners are not the agents transmitting the messages,
so listname-owner should clearly not go in Sender:.
We really want to increase the chances that Mailman will process all
bounces. As I mention above, we absolutely can't be a vector for
spamming people with bounces they can't do anything about. If some
buggy MTAs throw bounces away though, tough luck for their users. There
should be enough compliant MTAs out there that the added cost of keeping
bogus addresses on a list because we never saw their bounces should be
I don't really like list or site options for this kind of thing. For
one thing, we already have too many options and adding list options
complicates the U/I and cognitive load for list admins who usually
really don't want to be bothered with this nonsense. We should be
reducing the options a list admin has to worry about, not increasing
This is not really appropriate for a site admin either because that's
too coarse of a decision. A Mailman site talks to a huge array of MTAs
and MUAs, so I don't think you could make a good choice. If anything,
should we determine that Sender: munging has to stay, it should be a
user option because only the user knows whether their MUA will present
them with an ugly message display. A user could decide to turn off
Sender: munging, but I suspect it's still more than the typical user
will want to deal with. And of course per-user options get into all the
personalization vs. performance issues.
Is listname-bounces confusing? Yes, and I wouldn't be opposed to
changing this, although I'm not sure what we'd use. listname-processor?
Well, let's hope we can just get rid of Sender: munging instead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 309 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20060428/e0e77216/attachment.pgp
More information about the Mailman-Developers