RE: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822

[Douglas Otis <dotis@xxxxxxxxxxxxxx>]

On Tue, 2004-09-14 at 07:18, william(at)elan.net wrote:
> On Tue, 14 Sep 2004, Danny Angus wrote:
> 
> > I'd also strongly support the notion that the user had reintroduced the
> > message by knowingly sending a mail to a mechanism designed to re-introduce
> > it to the system, such as a mailinglist.
> 
> In such a case if you believe user has reintroduced the message, that
> user would have be listed in Resent headers (as per RFC2822 text below), 
> but in reality it is mailing list that is to be listed in
> Resent-From headers per the marid-core draft.

> Additionally mailing lists reguarly modify email message and both add
> their own headers (List-Id, List-Unsubscibe, List-Archive are the
> ones added by imc mailing list software for example) and modify existing
> headers (Sender header is replaced by email address, many lists modify
> Subject, some modify To and Cc) and add new content (mail list footer
> added to the buttom of the email message). But RFC 2822 says:
> 
>    Resent fields are used to identify a message as having been
>    reintroduced into the transport system by a user.  The purpose of
>    using resent fields is to have the message appear to the final
>    recipient as if it were sent directly by the original sender, with
>    all of the original fields remaining the same.
> 
> I emphasise that it says "all the original fields remaining the same",
> so it would appear RFC2822 specifically says that Mail lists can not
> be considered a true user reintroduction of the message and thus
> Resent-From is inappropriate to be used in such a case.

This issue goes away when the MTA EHLO domain is used instead.  It also
allows the mailbox domain, MAIL FROM or From, to specify a simple name
list that can be obtained in a single, non-sequential lookup, to
authorize or note as nominal the MTA senders.

-Doug