David Woodhouse <dwmw2(_at_)infradead(_dot_)org> wrote:
Take CSV and SPF, for example. Of course the details vary, but in
practice they do exactly the same thing.
They're looking at different fields in the SMTP header, so they're
doing *something* different.
Precisely because SPF validates only one hop, it's achieving no more
than CSV is.
I disagree. SPF validates the use of a name in MAIL FROM for *any*
hop. CSV validates that an SMTP client is affiliated with a domain
name it's using in EHLO.
The validations are orthogonal, because they are validating
different fields which do not have to be correlated.
That sounds like a description of SES. You try to send mail from me to
somewhere like sourceforge.net, and they'll call _my_ servers and ask if
I send MAIL FROM:<dwmw2(_at_)infradead(_dot_)org>. When I say no, they'll
reject
the mail you're offering. Try it.
There are multiple ways of doing this kind of check. The original
one was RMX, which had it's benefits and limitations. SES looks to be
a little more general, in that it doesn't have the IP address
restrictions that RMX has.
The issue SES has that RMX doesn't is that the cryptographic tokens
it uses can be copied. e.g. Grab tokens from somewhere, and for a
short period of time, use them to send spam to third parties. While
there are ways to fix this issue, most involve a re-thinking of what
we mean by "sending email".
"its name". But yes. The question is how you identify that traffic.
Use of the name in a field in a protocol. e.g. EHLO or MAIL FROM.
In the case of mail, we all agree it would be stupid to identify
the traffic by the MAC address on the packets. Many of us think it's
similarly stupid to use the IP address on the packets. Many of us
are offering other ways you could identify it.
Cryptographic approaches solve a lot of problems inherent in
IP-based approaches, because they tie authentication to identity, and
not to location.
Alan DeKok.