[Mailman-Users] [Mailman-Developers] Sender field
Stephen J. Turnbull
stephen at xemacs.org
Sat Apr 29 17:00:14 CEST 2006
>>>>> "Brad" == Brad Knowles <brad at 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.
More information about the Mailman-Users
mailing list