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 listname-bounces+jim=reader.domain.com@mailman.server.com On behalf of fred@poster.domain.com". (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.0000 00000 -0600 +++ mailman-2.1.5/Mailman/Handlers/SMTPDirect.py 2006-04-26 13:48:45.0000 00000 -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()
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 msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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 listname-bounces+jim=reader.domain.com@mailman.server.com On behalf of fred@poster.domain.com". (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, brad@stop.mail-abuse.org
"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, 1755LOPSA member since December 2005. See http://www.lopsa.org/.
On Thu, 2006-04-27 at 22:46 -0500, Brad Knowles wrote:
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.
Probably Original-Sender:
-Barry
On 4/28/06 6:06 AM, "Barry Warsaw" barry@python.org wrote:
On Thu, 2006-04-27 at 22:46 -0500, Brad Knowles wrote:
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.
Probably Original-Sender:
Probably, indeed. But what happens if that header was already "taken" in the process that brought the message to mailman for distribution to the list?
(As usual, I have only questions, not answers.)
--John
John W. Baxter wrote:
Probably, indeed. But what happens if that header was already "taken" in the process that brought the message to mailman for distribution to the list?
As I noted in my previous response, I believe that the correct field (if Mailman were to add a "Sender:" header) to add would be "Resent-Sender". Please see RFC 2822, section 3.6.6. The "Resent-Sender" field may be multivalued, so this isn't a problem. However, Mailman should not be modifying the Sender: field at all.
"Original-Sender" is a header used when gatewaying X.400 messages into RFC 822 messages for use in JNT mail networks. It would not be appropriate for use here.
On Fri, 2006-04-28 at 13:05 -0500, Neal Groothuis wrote:
As I noted in my previous response, I believe that the correct field (if Mailman were to add a "Sender:" header) to add would be "Resent-Sender". Please see RFC 2822, section 3.6.6.
Whatever else we decide, I don't agree, or at least, it won't help us. $3.6.6 says that Resent-* headers are to be added by a user. It also says that these are purely informational headers, so I don't see how adding them will instruct a receiving MTA usefully.
-Barry
At 7:50 PM -0400 2006-04-28, Barry Warsaw wrote:
On Fri, 2006-04-28 at 13:05 -0500, Neal Groothuis wrote:
As I noted in my previous response, I believe that the correct field (if Mailman were to add a "Sender:" header) to add would be "Resent-Sender". Please see RFC 2822, section 3.6.6.
Whatever else we decide, I don't agree, or at least, it won't help us. $3.6.6 says that Resent-* headers are to be added by a user. It also says that these are purely informational headers, so I don't see how adding them will instruct a receiving MTA usefully.
Siunce the RFC doesn't specifically talk about "relay agents" as separate from "users", I think we could argue that Mailman would qualify as a "user" in this context. Therefore, the Resent-* headers seem to be most appropriate.
But you are correct that these are purely informational and will be completely ignored by any MTA. If we need something that will be noticed by other MTAs beyond the envelope sender and the "Return-Path:" & "Errors-To:" headers, then we're going to have to carefully think about this.
I am still opposed to blindly making this change and letting the community find out what happens.
I think we need to gather a lot more information about the likely outcome from this change, and I think the best way to achieve this is through giving admins (either site admins or list admins) the ability to set an option and choose whether or not they want to see what happens.
-- Brad Knowles, brad@stop.mail-abuse.org
"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, 1755LOPSA member since December 2005. See http://www.lopsa.org/.
"Brad" == Brad Knowles brad@stop.mail-abuse.org writes:
At 7:50 PM -0400 2006-04-28, Barry Warsaw wrote:
>> Whatever else we decide, I don't agree, or at least, it won't
>> help us. $3.6.6 says that Resent-* headers are to be added by
>> a user. It also says that these are purely informational
>> headers, so I don't see how adding them will instruct a
>> receiving MTA usefully.Sender doesn't instruct *conformant* MTAs at all, does it? AFAIK the only thing that a RFC 2821-conforming MTA looks at is the Return-Path header, and it's supposed to remove that.
So this is purely a matter of pragmatic self-defense against broken MTAs that do bounce to Sender.
Brad> Siunce the RFC doesn't specifically talk about "relay
Brad> agents" as separate from "users", I think we could argue
Brad> that Mailman would qualify as a "user" in this context.
Brad> Therefore, the Resent-* headers seem to be most appropriate.Agreed. For a number of reasons, I think this information can be useful. As I mentioned elsewhere, the Resent-Message-Id field can be used to supply a UUID that we can trust (eg, for constructing canonical archive URLs). Unlike the Received headers, these are readable by humans who aren't wall-eyed, helpful in tracing delays, for example.
Brad> If we need something that will be noticed by other MTAs
Brad> beyond the envelope sender and the "Return-Path:" &
Brad> "Errors-To:" headers, then we're going to have to carefully
Brad> think about this.What's an Errors-To header? I can't find it in the usual suspects.
But I don't see any particular need for thought. Conforming Internet MTAs don't look at message headers, period.
-- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
At 12:00 AM +0900 2006-04-30, Stephen J. Turnbull wrote:
Brad> If we need something that will be noticed by other MTAs Brad> beyond the envelope sender and the "Return-Path:" & Brad> "Errors-To:" headers, then we're going to have to carefully Brad> think about this.What's an Errors-To header? I can't find it in the usual suspects.
That's the oldest technique for handling bounces. It has been deprecated for a while, but I would be inclined to continue to at least provide the appropriate information.
-- Brad Knowles, brad@stop.mail-abuse.org
"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, 1755LOPSA member since December 2005. See http://www.lopsa.org/.
On 4/29/06 8:00 AM, "Stephen J. Turnbull" stephen@xemacs.org wrote:
Sender doesn't instruct *conformant* MTAs at all, does it? AFAIK the only thing that a RFC 2821-conforming MTA looks at is the Return-Path header, and it's supposed to remove that.
There is no Return-Path: header during transmission of a message. The Return-Path header is added in the process of delivery. There is a return path, stated in the MAIL FROM:example@example.com SMTP command. (That command *can* have more stuff related to authentication.) The return path is what should be used as the address of a bounce if a mail system foolishly accepts a message and then creates a bounce.
Notice that if an MTA rejects a message (or one or more of the recipients of the message), it is not bouncing or creating a bounce. It is issuing an error response...the MTA (or MUA in the case of message submission) that was trying to send creates a bounce message if appropriate (for message submission, the MUA notifies the user--or pretends to: Microsoft by default hides the notification remarkably well).
While multi-line text associated with the rejection code is provided for, MUAs are very poor about showing it if a submission is rejected--some show only the first line; some only the last line. Even some MTAs "improve" the text of the rejection.
--John
On Sun, 2006-04-30 at 00:00 +0900, Stephen J. Turnbull wrote:
Sender doesn't instruct *conformant* MTAs at all, does it? AFAIK the only thing that a RFC 2821-conforming MTA looks at is the Return-Path header, and it's supposed to remove that.
So this is purely a matter of pragmatic self-defense against broken MTAs that do bounce to Sender.
Correct, and what we're trying to figure out is whether we need that self-defense any longer. The change to test this may be as simple as commenting out "msg['Sender'] = envsender" in bulkdeliver() inside SMTPDirect.py (a little more complicated if you want to do it just for one domain though -- you'd want to test for something like "if 'xemacs.org' in mlist.host_name")
Agreed. For a number of reasons, I think this information can be useful. As I mentioned elsewhere, the Resent-Message-Id field can be used to supply a UUID that we can trust (eg, for constructing canonical archive URLs). Unlike the Received headers, these are readable by humans who aren't wall-eyed, helpful in tracing delays, for example.
It's an intersting idea.
-Barry
On Fri, 2006-04-28 at 19:12 -0500, Brad Knowles wrote:
I think we need to gather a lot more information about the likely outcome from this change, and I think the best way to achieve this is through giving admins (either site admins or list admins) the ability to set an option and choose whether or not they want to see what happens.
I agree that we need a lot more data, but I'm not sure making this an option is the best way to gather that data. Besides, if we do it that way, it'll be Mailman 2.3 (or whatever <3.0 wink>) before we make the change.
I'd like to work up an unofficial diff to Mailman 2.1 for people like Stephen who are willing to give it a try on a live site. We just have to agree as to what that change should be!
-Barry
I'd like to work up an unofficial diff to Mailman 2.1 for people like Stephen who are willing to give it a try on a live site.
I'm not sure this is even necessary.
Ezmlm doesn't touch the Sender: header at all, Majordomo sets it to the owner of the list, and (AFAICT) Listserv sets it to the list itself. This would seem to me to indicate that incidences of mail being returned inappropriately to the sender are infrequent, at worst.
The important question would seem to be "what's appropriate?" From RFC 2822, 3.6.2: "The originator fields indicate the mailbox(es) of the source of the message." Given this, the definition of the Sender and From headers, and the example given in this section, it seems that Outlook's interpretation of the fields ("SENDER on behalf of FROM") is reasonable. Mailman is not the originator of the message, so it should not be tampering with the From: or Sender: fields at all.
It might be appropriate for Mailman to add Resent-* headers, depending on how one reads RFC 2822, 3.6.6. I personally don't think it's necessary or useful, since list servers add their own List-* headers, per RFC 2369. The Resent-* headers seem to exist for individuals resending messages, not automated systems. This is supported by the RFC: "Resent fields are used to identify a message as having been reintroduced into the transport system by a user."
Neal Groothuis wrote:
Mailman is not the originator of the message, so it should not be tampering with the From: or Sender: fields at all.
This is arguably not true. Mailman may add a list header and/or list footer to the body of the message as well as potentially filtering or scrubbing various MIME parts. The message sent by Mailman can be significantly different from the one originally received.
-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Mon, 2006-05-01 at 18:16 -0700, Mark Sapiro wrote:
Neal Groothuis wrote:
Mailman is not the originator of the message, so it should not be tampering with the From: or Sender: fields at all.
This is arguably not true. Mailman may add a list header and/or list footer to the body of the message as well as potentially filtering or scrubbing various MIME parts. The message sent by Mailman can be significantly different from the one originally received.
The copy that Mailman sends is almost always modified in some way, and given the ambiguities in the standards, I think it's defensible to say that Mailman is the originator of the messages received by list members.
-Barry
On Mon, 2006-05-01 at 13:27 -0500, Neal Groothuis wrote:
I'd like to work up an unofficial diff to Mailman 2.1 for people like Stephen who are willing to give it a try on a live site.
I'm not sure this is even necessary.
Ezmlm doesn't touch the Sender: header at all, Majordomo sets it to the owner of the list, and (AFAICT) Listserv sets it to the list itself. This would seem to me to indicate that incidences of mail being returned inappropriately to the sender are infrequent, at worst.
As I said, I think it's defensible to claim Mailman is the originator, but practicality beats purity, and I do think a list manager falls into a gray area here.
Having said all that, you might be right, in that we really don't need to do much except remove the addition of the Sender: header in bulkdeliver().
-Barry
On Fri, 2006-04-28 at 10:29 -0700, John W. Baxter wrote:
On 4/28/06 6:06 AM, "Barry Warsaw" barry@python.org wrote:
On Thu, 2006-04-27 at 22:46 -0500, Brad Knowles wrote:
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.
Probably Original-Sender:
Probably, indeed. But what happens if that header was already "taken" in the process that brought the message to mailman for distribution to the list?
(As usual, I have only questions, not answers.)
Original-Original-Sender:
(and so on, and so on... :) -Barry
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.
Don't forget to consider things like SPF, which I think uses the sender field. Whatever is used for SPF _must_ be the domain of the mailman box, or you're gonna run into a pack of trouble.
...Trouble similar to a current problem I am having with AOL: they are bouncing all email with the FROM: address of a specific AOL user, when mailman delivers the messages to -any- aol or cs.com address. Its a very bad problem, because AOL is saying its a SPF problem, when it clearly isn't (as other aol people can post to the list and receive their posts), and all the aol users are being automatically unsubscribed from lists that this guy posts on. But I digress...
Bob
Neal Groothuis wrote:
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.
<snip>
On Fri, 2006-04-28 at 14:08 -0400, Bob Puff@NLE wrote:
...Trouble similar to a current problem I am having with AOL: they are bouncing all email with the FROM: address of a specific AOL user, when mailman delivers the messages to -any- aol or cs.com address.
Have you tried turning on full personalization so that every recipient gets their own copy?
-Barry
Yes, and it still happens. Apparently, AOL has some filter based on a FROM: address matching a specific list, and bounces it with an SPF error, which it clearly is not.
Bob
---------- Original Message ----------- From: Barry Warsaw barry@python.org
Have you tried turning on full personalization so that every recipient gets their own copy?
-Barry
------- End of Original Message -------
What I have noticed is most of our Outlook users are confused by the
presence of the word 'bounces' in the From field more than they are
annoyed at the way Outlook deals with the Sender header. When they
see 'bounces' they assume something went wrong. For our uses just
changing that list-bounces address to something less ominous looking
would help.
DallasOn Apr 28, 2006, at 9:02 AM, Neal Groothuis wrote:
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-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers% 40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman- developers/dallas%40dreamhost.com
Security Policy: http://www.python.org/cgi-bin/faqw-mm.py? req=show&file=faq01.027.htp
Dallas Bethune wrote:
For our uses just
changing that list-bounces address to something less ominous looking
would help.
It definitely looks to me as if something needs to be done. I think perhaps offering 3 options either to the list admin on a per-list basis with a site default or just a site option. I lean towards per-list although it's more work to add to the GUI.
The options I see are
current behavior with perhaps the addition of putting the original Sender: in another header.
like 1) only use list address instead of list-bounces.
don't touch Sender: at all.
-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
I strongly second the idea of replacing the listname-bounces address by a different address which does not suggest that something went wrong. This brings to mind another example of an unfortunate choice of words: on some of my mailing lists people got outright paranoid because they received a message that their submission was not accepted because of "suspicious headers". They thought they were being censored. Appearances sometimes mean a lot.
Hans G. Ehrbar
-- Hans G. Ehrbar http://www.econ.utah.edu/~ehrbar ehrbar@economics.utah.edu Economics Department, University of Utah (801) 581 7797 (my office) 1645 Campus Center Dr., Rm 308 (801) 581 7481 (econ office) Salt Lake City UT 84112-9300 (801) 585 5649 (FAX)
On Fri, 2006-04-28 at 14:13 -0600, Hans G. Ehrbar wrote:
This brings to mind another example of an unfortunate choice of words: on some of my mailing lists people got outright paranoid because they received a message that their submission was not accepted because of "suspicious headers". They thought they were being censored. Appearances sometimes mean a lot.
I totally agree that we need to do something about the "suspicious headers" message. I'm always getting questions from users who see this asking what they've done to deserve such a dire message (answer: usually nothing! :).
-Barry
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 low.
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 them.
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.
-Barry
participants (10)
-
Barry Warsaw -
Bob Puff -
Bob Puff＠NLE
-
Brad Knowles -
Dallas Bethune -
Hans G. Ehrbar -
John W. Baxter -
Mark Sapiro -
Neal Groothuis -
Stephen J. Turnbull