Jason R. Mastaler <jason-list-mailman-developers@mastaler.com> wrote:
barry@zope.com (Barry A. Warsaw) writes:
The only argument I'd make is that the standards are really geared toward cooperation of alien systems, i.e. two unrelated processes that need to exchange mail messages. In Mailman's case, an argument can be made that it and its MTA are working in tandem to perform a function.
That would be a practical and reasonable argument.
Yes. This means that if you're maintaining both the MTA and a MLM (mailing list manager) program which gives messages to it, then you can set things up so that the MLM expects the MTA to munge the messages in some ways that are not specified in the RFCs.
However, given that the GNU Mailman project maintains only an MLM and no MTA, and this MLM communicates with the MTA through an interface that is specified in an internet standard, there is IMO no doubt that it's Mailman's responsibility to comply with this standard.
Barry A. Warsaw <barry@zope.com> wrote:
"JRM" == Jason R Mastaler <jason-list-mailman-developers@mastaler.com> writes:
JRM> Then shouldn't you also have Mailman add a Message-ID header JRM> as well? SMTP on qmail doesn't add that either.I thought about the same thing, and /almost/ added it, but then I checked RFC 2822. While it requires one Date: header, Message-ID: is actually /not/ required, although it "SHOULD be present". I took that as license to be as conservative as possible. :)
The term "SHOULD" has a well-defined meaning in RFCs... RFC2822 explicitly invokes RFC2119, where this, and related terms are defined as follows:
MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
[..]
With other words, given that the Message-ID: header is a SHOULD, if you want to choose a diffferent course, you (as maintainer of Mailman) have a responsibility to understand and carefully consider the full implications of not adding a Message-ID: header to messages that are _originated_ by Mailman.
There are several such implications, in areas like automated filtering of duplicate messages, debugging mail problems (some MTAs log the contents of the Message-ID: header), and spam filters (I know of at least one ISP where all messages without Message-ID: are considered to be probably spam).
I think it's probably much less work to just add the header than to "understand" and "carefully weigh" all these implications.
Greetings, Norbert.
-- A founder of the http://DotGNU.org project and Steering Committee member Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://thinkcoach.com List hosting with GNU Mailman on your own domain name http://cisto.com