[Mailman-Developers] Re: Cutting "Received:" headers (John A. Martin)

[Tom Neff]

jam at jamux.com (John A. Martin) wrote:
>[Roman Sinelnikov wrote:]
>> Dear colleagues, one more idea, it would be very convenient
>> to have an optional cutting of "Received:" headers in any
>> e-mail message before its sending by Mailman to the list
>> members.
> 
> Rfc2822 Section 3.6.6

Concise, but wrong for the following reasons.

 1. "Received:" is a Trace field, not a Resent field, and hence is covered in
RFC 2821, not 2822:

	http://www.ietf.org/rfc/rfc2821.txt

 2. The rules laid out in RFC2821-2 for preserving Trace and similar fields
explicitly apply to SMTP relays and gateways, i.e., nodes whose job is to
transport mail from sender to an explicit recipient.

A mailing list manager is not an SMTP relay or gateway.  It is an automated
correspondent -- one that collects the results of one or more successful
(RFC2821-2 compliant) mail transactions, and then under controlled
(moderated, filtered, digested, etc) circumstances, causes zero or more NEW
RFC-compliant mail transactions to be created as a result.

Mailing list managers are under no obligation to masquerade themselves as
SMTP relays or gateways, and in general they don't try to do so.  They make
all kinds of changes to envelopes, headers, message bodies, etc, that no SMTP
relay or gateway would be permitted to do.  The entire concept of a Digest
(plain text or MIME) would break RFC2821-2.  The entire concept of the
List-XXXX: headers would break them.  Per-message suffixes break them.  And
so forth.

The purpose of the Received: trace field is to allow a mail administrator to
identify and, if necessary, troubleshoot the relay path that a message
followed before reaching his or her site (which might not even be the
intended destination, mail problems being what they are).  The case can be
made that once a message has successfully arrived at the listserv/Mailman
collector, this information is of no further use and may as well be dropped.
(In that case, listmembers would still have Received: headers in their list
messages, but only from the path between the posting host and their own
machines.)

On the other hand, I know of lists where the members are much more net.savvy
than the listowner of record, so that if something does come up, their
ability to see all the Received: headers can be helpful.

I would be in favor of a "clean_headers" per-list option which, if True,
would remove all but a minimal, rational set of headers from messages before
they are reposted.

In the meantime, any site admin who wants to do this kind of cleaning can
easily insert "formail" or "reformail" into the alias pipeline for the
posting address.  These are utilities supplied with "procmail" and "maildrop"
respectively, and widely available on the Net.