Subject: RE: MTAs should do what they're good at

From: "Terje Petersen" <[email-masked]>
Date: Wed, 21 Jul 2004 16:27:47 +1000

>>>    Terje> 2. Dump messages where FROM <> SUBMITTER.
>>>
>>But an MTA can reject the message at the MTA level. 

In theory an MTA can server up web pages and wash laundry also. However
it's 
not in the standards. Just because some MTAs can or currently do some 
function that does not mean that it's a good idea to make it a standard 
function for all MTAs (or all MARID compliant MTAs). And just because 
washing laundry is not a standard MTA function it does not mean that you
are 
stopped from having an MTA that does wash laundry. 

I agree that it's bad for an MTA to dump email silently. However I was 
saying that the MUA should do it not the MTA. Still I would agree that
this 
is also not such a good idea so let's propose the following:-

As a default a well designed MUA would be expected to check that
SUBMITTER 
equals FROM and if it does not then the SUBMITTER address should be 
displayed to the user as the SENDER of the email instead of the FROM
address. This way nothing gets silently dumped.

Certainly the SUBMITTER address might be forged (so might the FROM
address) 
but since the SUBMITTER address is likely to have been SPF checked at
the 
MTA level it is a safer bet. 

>Right -- the MTA can easily look at the header as it receives the
>message data and reject the message at the end of the data if it fails
>the test.

Yes but that means that forever more the content of email is locked down
by 
the way that we have made MTAs work. MTAs should not fail just because
we 
decide at some future date to redefine the way that content is
structured.
That's how layering should work. 

And making the SUBMITTER/FROM comparison an MUA function does not stop
your
anti-virus/spam gateway rejecting email actively in real time due to 
malformed content. However it's purely a proprietary implementation to
suit 
a local policy decision in that instance. Not an MTA standard.

As a proprietary solution we could right now make MTAs that reject the
transmission of email if the DATA section contains a virus or spam. We
don't need a standard to make this possible. It's just a local policy
decision. 

>While I sympathize with the goal of separating function, it's been
>apparent for a long time that you often need to combine the
>implementation of multiple levels to get acceptable performance. If I
>had to push all my MTA spam filtering into the MUA, the load on my
>mail servers would go up an order of magnitude.  Even if it has to
>read the whole message before rejecting it, MTA time rejection is a
>lot cheaper than MUA rejection because it avoids the entire queue and
>deliver process.

Your anti-spam gateway is already doing stuff that is not defined as a 
standard MTA function. It is already a proprietary "MTA+MUA gizmo". So
in 
essence you have already put such stuff in the MUA. 

And rejection during transmission is not much cheaper than letting the
MUA 
deal with it. You still need to receive the entire DATA section before
the 
MTA can make a reject response.

---

From: "David Beveridge" <[email-masked]>
Date: Wed, 21 Jul 2004 21:23:32 +1000

On Wed Terje wrote

> In theory an MTA can server up web pages and wash laundry also. However

You know what, MTA's today are good at is transmitting spam.  Are you
suggesting they just stick to that or, do we make some changes.

It's all very well to let the MUA block it but what if you get 100 spams to
every real email.
That means your email costs just got multiplied by 100.

Your are not solving the problem by using MUA filtering.

And what do you do when the MUA blocks, you can't reject it's too late, so
you're going to pester the poor sucker that got joe-jobbed for not
publishing spf records.

You need to change your thinking from "accept & bounce" to "reject"

Rejecting can only be done by the MTA.  Rejection puts the emphasis onto the
sender to prove their authenticity.

dave