ietf-mxcomp
[Top] [All Lists]

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

2004-09-14 11:21:18

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 


<Prev in Thread] Current Thread [Next in Thread>