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.