Subject: RE: MTAs should focus on email TRANSPORT not email CONTENT

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 26 Jul 2004 18:17:29 -0700

Procedural note, each time I reply to a mail from this individual
he has a robot send me spam. If he is serious about stopping spam
he will shut his robot up.

> Absolutely. At 2821 stage, we currently have ONE un-ambiguous 
> sender identity, which is MAIL FROM.

As has been explained at length in this forum, MAIL FROM is not 
un-ambiguous. In fact the real semantics of the field as defined
by the protocol are that it is the bounce address.

> It is obvious to common sense that we should base our 
> controls upon the 
> provided identity that is given to us, rather than having to 
> reinvent, dig 
> out from the 2822 headers thru complex circonvolutions or 
> whatever, another 

It seems obvious to me that a mail authentication mechanism should
try to authenticate the mechanism that is seen by the user, accepting
that we may need to get MUAs to act in a more coherent manner.

The RFC 2821 / RFC 2822 distinction is really not relevant to
this, the message format and the transport have numerous 
interactions and in any case we would be breaking the model of
total separation of concerns between layers by introducing an
interaction between IP layer transport and the application layer.

---

From: "Terje Petersen" <[email-masked]>
Date: Tue, 27 Jul 2004 16:35:32 +1000

-----Original Message-----
From: Roy Badami [mailto:roy@] 
Sent: Wednesday, 21 July 2004 5:15 AM
To: Terje Petersen
Cc: [email-masked]
Subject: RE: MTAs should focus on email TRANSPORT not email CONTENT

>>>>> "Terje" == Terje Petersen <[email-masked]> writes:

    Terje> 2. Dump messages where FROM <> SUBMITTER.

But an MTA can reject the message at the MTA level.  Quietly dumping
messages anywhere is a bad thing, and it violates the spirit of the
reliable mail delivery prinicple, even if perhaps not the letter.

	 -roy

=================================
=== RESPONSE FROM TERJE BELOW ===
=================================

Having thought about this some more it is now even more obvious to me 
that the MUA can easily handle this job without "dumping" email
silently.

The MTA receives a command such as:-

	MAIL FROM:<[email-masked]> SUBMITTER:<[email-masked]>

Now even before we look at content both email addresses MUST pass an SPF
check and be authorised (and arguably confirmed correct). 

So if the MUA subsequently finds that the email content is malformed
because 
it does not have the correctly matching headers then the email can be
safely 
bounced by the MUA back to fred. After all that address was
authenticated
previously by the MTA. 

And whether the MUA bounces the message or the MTA bounces the message
the 
entire content had to be received first up anyway. 

And at the risk of flogging a dead horse I will just say once again
there is
nothing stopping proprietary solutions from incorporating MUA checks
into 
mail gateways. It just that the standards should regard it as an MUA 
function.