ietf-822
[Top] [All Lists]

Re: rfc2822bis -- adding clarifying Sender: text

2008-01-16 07:39:41

Charles Lindsey wrote:
 
there are situations where an existing Sender currently
IS modified, that being regarded as good practice.

The precise number of RFCs discussing to *modify* an
existing Sender header field I'm aware of is zero, what
do you have in mind ?

The best example is where the message is being forwarded
by a mailing list expander

2821 and 2821bis say MUST NOT, and if anything else is
regarded as "good practice" folks supporting this view
didn't show up before the end of the 2821bis Last Call.

This is rather critical for DKIM SSP if they drop their
odd "first author" magic in favour of a 2822upd sender.

Just because some mailing lists do whatever they like
doesn't mean that Internet Standards have to sanction
these practices.  Manipulating "in transit" mails could
be considered as illegal where I live.  

(or, equivalently, it is being gatewayed into Netnews)

IMO gateways are not equivalent, they are discussed in
a different chapter of 2821bis, IIRC also in mail-arch.

Those cases are customarily justified on the grounds
that it is a brand new transmission (even though the
original Message-ID is retained).

If it's "brand new" then retaining the Message-ID *is* 
broken.  Even Resent-* has its own Message-ID, and the
old "de facto" NetNews standard s-o-1036 (its successor
waiting for an RFC number is likely not yet well known)
offers clear advice why that's a bad idea:

| Above all, prevent loops

"Same Message-ID" means "same article" for NetNews.  

I don't say that it cannot be done as you want it, but
to do it this way requires substantial modifications of
2821bis, 2822upd, mail-arch, maybe 4409, PRA, and more.

Until that happens wannabe "mailing lists" mutilating
valid mails are non-standard junk, not "good practice".

 Frank