On Mon, 2004-07-26 at 13:02, Greg Connor wrote:
On Mon, 2004-07-19 at 17:44, Terje Petersen wrote:
...
A mismatch between the SUBMITTER address and the FROM address is a content
problem not a transport problem.
MTAs should deal with transport.
MUAs should deal with content.
I think the assumption hidden here is that 2821 defines transport data,
and never content, and 2822 defines content, and never transport.
Perhaps this is true, but there was LONG discussion during the first
phase of MARID about "Choice of identity to operate on" and it was
decided at the outset that we want to be able to validate BOTH 2821 and
2822 identities.
Subjugation of RFC 2821 MAIL FROM to PRA was "announced" more than
"discussed." This took place when Ming announcing "he" decided to
relinquish SPF to C-ID. It has been a hard road to pushing back the
changes this entailed. From XML syntax to now the RFC 2822 sender
identities. I see little justification for either of these changes and
may reasons for not allowing such changes.
In my opinion, if you want to define 2821 as Transport and 2822 as
Content, that is fine, but there are still cases where you need to sync
up the two. How do you solve this puzzle? If the MTA only has access
to 2821 identities, and the MUA can only see 2822 identities, then
neither of these can validate consistency without stepping out of its
assumed boundaries.
There are several proposals that handle RFC 2822 identities in a manner
they SHOULD be handled. Sender-ID will continue Phishing and "back
door" entry practices. Something like "DomainKey" or "Identified
Internet Mail" does exactly what a user would expect. Tell them WHO
sent the mail, or provide STRONG assurances of the domain. PRA can not
clearly define which identity should be checked, displayed, or how this
relates to the author of the message.
You mentioned spam filters and virus filters that are already blurring
the lines. There is good reason for that. Users want to REJECT bad
mail, not accept it and deliver it to an MUA which has no choice but to
file it in another folder. Administrators want to reject it during the
first conversation so that they don't have to generate a bounce message
later (commonly referred to as "blowback")
The large number of records required for this check and the need to read
the message ensures there is no savings with respect to the incoming
network load. Closing the "back door" or preventing "blowback" is best
done with RFC 2821 MAIL FROM checks. Allowing a different identity only
allows a means to side step any protections desired.
Also, RFC2476 defines the concept of an MSA (Submit server) which fills
all the functions of an MTA, but also does some content checking. For
example, it says that an MSA should check all of return path, Sender:,
Message-Id, and more). So the idea of checking both 2821 and 2822
identities in the same place is not new (RFC2476 is 5.5 years old,
though big ISPs and corporations still routinely skirt it).
RFC 2476: MSA
Unfinished messages need to be completed to ensure
they conform to [MESSAGE-FORMAT], and later requirements. For
example, the message may lack a proper 'Date' header field, and
domains might not be fully qualified. In some cases, the MUA may be
unable to generate finished messages (for example, it might not know
its time zone). Even when submitted messages are complete, local
site policy may dictate that the message text be examined or modified
in some way. Such completions or modifications have been shown to
cause harm when performed by downstream MTAs -- that is, MTAs after
the first-hop submission MTA -- and are in general considered to be
outside the province of standardized MTA functionality.
There is specific wording regarding checking the RFC 2821 return path
but only that compliance to RFC 822 be done to ensure "local only" paths
have the domain added, etc. I would not describe that as advice to
"check" that these RFC 822 paths are valid, only that they conform to
syntax requirements.
Another way of looking at this is: MARID doesn't require implementation
at the MTA level. SUBMITTER is a helper-function, but not a
requirement, and it is completely possible to implement MARID within the
spec by an MUA or an MUA-like filter like SpamAssassin. The spec itself
doesn't say "It must be in your MTA". But, if users are free to
implement it at whatever stage they choose, they are guaranteed to start
phoning Sendmail and asking for a MARID implementation :)
How easy would it be to spoof, if not done at the MTA? I did not think
the charter was to aid message filtering. By making the authorization
based upon the message (RFC 2822), rather than the MTA (RFC 2821), the
overly broad nature of this task removes a clear definition of the
identity being checked. In addition, the permission sets for this RFC
2822 check obscures which domain is administratively accountable for the
messages being emitted. At least, when done for the RFC 2821 MAIL FROM,
this had the benefit of directly blocking the "blowback". Checking the
RFC 2822 identity ensures an ability to continue the practice of using
RFC 2821 MAIL FROM spoofing.
-Doug