On Sun, 29 Aug 2004, wayne wrote:
The point remains that authorization is about the the sending MTA.
Exactly. And if there is no "Sending MTA" (more correctly called "client MTA")
involved in current stage of transmission, you can't be involved in
authorization.
Spamassassin already does identifies the SMTP servers involved with
receiving the mail. It does so by looking at the Received: headers.
Yes, it is not 100% accurate, but that is irrelevant.
Its very relevent.
First of as far as spamassasin, it can run after the transmission or can
be called directly from the mail server (in which case its simply part of
smtp service filter, like blacklist) with parameters of the transmission.
When it does get called after the fact, its directly after the tranmission
with no extra hops and as long as email server is known to spamassasin
(otherwise you'd not be able to install it), it can be certain that it'll
find info about SMTP client. In almost all cases spamassisin also runs < 1
second after the transmission, this is also relevent because you can assume
that authentication records on client SMTP side are equivalent to what it
was during transmission, but you can't make this assumption if you run the
same check unknown amount of time after the fact.
But in general you can not trust Received headers and even when you think
you can, IETF has not standartized them and there is no requirement for
SMTP server to put SMTP client ip in the Received header or EHLO name or
any other data. Going back to trusting Received headers if you're looking
at one that is more then one hop away, you need a way to verify that is
valid Received header really added by MTA listed there. There is no way
to do it right now the only way to verify pieces of data where there is
no direct connection between creator and verifier is to use cryptography.
There is currently no standard available for adding signature to Received
header (I did make suggestions that we should work on it several times on
ietf-smtp and other lists and later worked on it as part of MTA Signatures
draft, see http://www.elan.net/~william/asrg/mta_signatures.htm) and until
we do have signed received headers, using any received header can cause
both misdirection as to the source of the email and email path taken
and possibly cause innocent party to be considered involved which is
exactly what we're trying to avoid with SPF and similar proposals that
try to combat forgery of email (and it would be stupid idea to make one
forgery verification system be dependent on another parameter which itself
can be forged).
[long list of advantages of doing checks during the SMTP session]
I agree with those, but again, they don't change what is being
authorized.
The point is that they only correct and reliable way to verify something
about SMTP Session (RFC2821) Envelope parameters is to do it as part of
that SMTP Session.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam Research Worksite:
http://www.elan.net/~william/asrg/