ietf-mxcomp
[Top] [All Lists]

Re: MTAs should focus on email TRANSPORT not email CONTENT

2004-07-26 13:02:06

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.

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.

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")

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).


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 :)