Right, sorry. I was in a hurry when I wrote my follow up, so let me provide more detail about the headers, and my thoughts about the X-iness.
In general, Mailman should "play nice" but I also think it's not unreasonable to claim the Mailman-* prefix and just start using it for Mailman-specific headers. If the header has some more general utility, then keeping the X- for now and registering them may make more sense. On Oct 26, 2011, at 12:43 PM, Ian Eiloart wrote: >> X-Message-ID-Hash > >This could be replaced with DKIM sigs, I guess. Actually, no, this one comes from here: http://wiki.list.org/display/DEV/Stable+URLs I think there was a discussion about this ages ago, although it might have been (partly) a private discussion with the Mail Archive folks. The idea is that given only the List-Archive or RFC 5064 Archived-At header and Message-ID header, you should be able to calculate a stable url for an archived message. If you only know the Message-ID then using the hash should allow you to search an archive for the message. X-Message-ID-Hash is essentially just a convenience, since it can be calculated from the Message-ID. I think it's still appropriate to leave this one an X- header, although it might be interesting to register it, and even more interesting to propose an RFC as an extension of RFC 5064. >> X-Mailman-Rule-Hits >> X-Mailman-Rule-Misses > >This might be useful for diagnostics, but probably wants to be off in >general. My view is that Mailman should not be doing message filtering. Mailman's always done some form of message filtering, so this is just MM3's way of recording the results of the various tests for acceptance. In MM2, the processing pipeline contained both moderation handlers (e.g. "is this administrivia") and modification handlers (e.g. "futz with the headers"), but this has been refactored in MM3 so that there are different processing subsystems for moderation and modification. The headers above will contain a list of the moderations rules that matched or missed, so their inclusion in the outgoing message is *mostly* diagnostics. Since they'll probably be hidden anyway, I think it's useful to keep these on by default. They could certainly lose the X- prefix. >> X-BeenThere > >I guess that's useful for avoiding list loops, perhaps? Right, but MM3 uses List-Post for that now, so this is legacy. I think this can be eradicated from the MM3 source, since I think it makes no sense to recognize the MM2 loop-detection header in MM3. https://bugs.launchpad.net/mailman/+bug/883158 >> X-Mailman-Version > >I think this should be replaced with X-Mailer, or even User-Agent. That's not >currently an SMTP header, but I think it should be. And it is in quite >widespread use. This is just the version of Mailman that sent the message. It can lose the X- prefix. >> X-Mailman-Approved-At This is a time stamp, so it'll help you understand why a message you sent to a list a year ago is only showing up now <wink>. It can lose the X- prefix. >> X-Archive >> X-No-Archive These are Postel's law headers which control whether a message is archived or not. Yeah, we've seen them both. MM3 doesn't set them, so ignore these for the purposes of this discussion. >What does this mean? > >> X-Ack >> X-No-Ack Similarly, these control whether an acknowledgment of a post is sent to the original author. MM3 does set this to "no" when a user's noack flag is set. These should keep the X- prefix. >> X-Peer Ignore this, it's used in the test suite only. lazr.smtptest sets it based on the host:port of the connecting socket. >> X-MailFrom >> X-RcptTo These are also primarily used in the test suite. Again, lazr.smtptest sets them, however MM3's LMTP server does add this header based on the RFC 5321 MAIL FROM value. It's mostly used as a diagnostic though. I think we could probably rename this to Mailman-LMTP-MailFrom if we still wanted to keep it. >> X-Originally-To Mailman only sets this in gate_news.py when it needs to rewrite the To: header. Probably not worth changing. >> X-Original-CC >> X-Original-Content-Transfer-Encoding >> X-MIME-Version Ignore these. They are used in the news gating code when it has to rewrite duplicate headers. E.g. if a message destined for NNTP has more than one CC header, MM3 collapses this into a single X-Original-CC and deletes all of the original CC headers. At least at one point, NNTP software did not accept messages with multiple CC headers. >> X-Mailman-Copy This one is used when VERP is enabled. When a message is posted to the list, personalization is enabled, and a user wants to receive duplicates (i.e. they have not enabled list-copy suppression), the copy of the message coming from Mailman will have X-Mailman-Copy: yes set. This is probably a fairly useless redundancy, since I always tend to use one of the List-* headers to determine whether a copy comes from the list or not. It also probably does no harm. It can either be removed or lose the X- prefix. >> X-List-Administrivia Honestly, I don't remember what the purpose of this header is. It used to be used when reduced RFC 2369 header were requested by the list administrator, e.g. because they had users with, um, unhelpful mail clients and got complaints about all the List-* headers. Now we don't support reduced headers so X-List-Administrivia is just useless and should be removed. >> X-Content-Filtered-By This is an identification header added when MIME contents of the original message are filtered. I'm not sure how useful it is, except that it does signal to the recipient that the message they received via the list has been modified. I think this should be renamed to (X-)Mailman-Content-Filter. >> X-Topics This contains a list of all the topic names that matched the message. >> X-Mailer > >I think we should use User-Agent here. Thunderbird does, as do some other >mail clients. Or, we should push for introduction of a List-Agent header. Mailman's autoresponder is the only thing that adds this, and it only contains an identity string. It may or may not be useful to keep this or change it. I'm not sure User-Agent would be right though. >> X-List-Received-Date This only gets added when the message is sent to the archive. It's consumed by the scrubber to help calculate the directory that attachments are saved in. >> X-Approve >> X-Approved These are used for admin bypass of the posting rules. We could change these to Mailman-* headers, but we'd still need to keep the above two for backward compatibility, so I'm not sure it's worth it. >Generally, I think we should avoid the use of headers that duplicate other >existing headers. Where we want to add more information, then extend the >List-* header set if the information might be generally useful for mailing >list software. Otherwise, use X-Mailman-* (or even Mailman-*) so that people >know where the header came from. I generally agree. https://bugs.launchpad.net/mailman/+bug/883193 -Barry
signature.asc
Description: PGP signature
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
