Re: [Mailman-Developers] The bulk issue
[Ken Manheimer]
More importantly, after reviewing the vacation man page, i realized that the precedence: bulk header would be redundant for mailing list traffic, since most of the kinds of things that respect it also refrain from responding to messages that do not have the recipient's address explicitly mentioned among the destination addresses, which is inherently the case for maillist traffic - so the precedence: bulk is unnecessary.
I'd say inserting a "Precedence: list" header is a good thing anyway.
Consider the case of a vacation program not knowing which addresses maps to which mail users -- such a vacation program (which is not at all uncommon) would have (very nearly) no idea whether the address in the To: header is a mailing list address or some strange alias pointing to the mail user it is trying to do it's thing for. Giving such a vacation program an additional header to base it's judgement on is IMHO a good thing.
I have no idea where, or even if, "Precedence: list" is standardized in any way, but I think that thath is what majordomo is inserting. Being compatible with majordomo when it doesn't cost us anything is also, IMHO, a good thing.
The only reason I see for _not_ adding any Precedence: header, is that Mailman-delivered messages have half a truckload of headers as it is. But that, IMHO, isn't really a strong argument -- as long as all the headers are there for some good reason, they _should_ be in there.
Just my ยค.02,
Harald
"HM" == Harald Meland Harald.Meland@usit.uio.no writes:
HM> I have no idea where, or even if, "Precedence: list" is
HM> standardized in any way, but I think that thath is what
HM> majordomo is inserting. Being compatible with majordomo when
HM> it doesn't cost us anything is also, IMHO, a good thing.
As far as I can tell, it is not documented anywhere; not even in the update to RFC 2076. I'll see if I can search around in Majordomo to see what they do, but if anybody else can verify this, it would be helpful.
HM> The only reason I see for _not_ adding any Precedence: header,
HM> is that Mailman-delivered messages have half a truckload of
HM> headers as it is. But that, IMHO, isn't really a strong
HM> argument -- as long as all the headers are there for some good
HM> reason, they _should_ be in there.
Yeah, and the IETF draft adds 9 more headers ;-(
-Barry
"Barry A. Warsaw" wrote:
"HM" == Harald Meland Harald.Meland@usit.uio.no writes:
HM> I have no idea where, or even if, "Precedence: list" is HM> standardized in any way, but I think that thath is what HM> majordomo is inserting. Being compatible with majordomo when HM> it doesn't cost us anything is also, IMHO, a good thing.As far as I can tell, it is not documented anywhere; not even in the update to RFC 2076. I'll see if I can search around in Majordomo to see what they do, but if anybody else can verify this, it would be helpful.
I've signed Listserv support list for sometime and this was a frequent question. The Precedence: list header isn't in any standard. If I remember well you will find info just in sendmail docs. It was invented by Eric Allman, who is the author of Sendmail mail and of the vacation program. Listserv refuses to add it since it isn't in the standards.
HM> The only reason I see for _not_ adding any Precedence: header, HM> is that Mailman-delivered messages have half a truckload of HM> headers as it is. But that, IMHO, isn't really a strong HM> argument -- as long as all the headers are there for some good HM> reason, they _should_ be in there.Yeah, and the IETF draft adds 9 more headers ;-(
I agree that there's no problem adding it, since it avoids problems to the list.
[]s
Paulo Eduardo Neves PUC-Rio de Janeiro Pager: Central: 292-4499 cod. 213 99 64 ou use a URL: http://www.learn.fplf.org.br/neves/mensagempager.html
Okay, I have added "Precedence: bulk" headers to both normal deliveries and to the digest envelopes. While there's some disagreement among people, this definitely helps some folks, and shouldn't hurt everyone else.
I am not adding other non-standard mailing list related headers, since that's *a lot* more headers for IETF draft support of a feature with marginal value. We could add these later easily.
-Barry
participants (3)
-
Barry A. Warsaw -
Harald Meland -
Paulo Eduardo Neves