On Thu, Jan 29, 2004 at 11:21:52AM -0600, wayne wrote:
| In <4019371B(_dot_)8070207(_at_)phase(_dot_)org> Wechsler
<wechsler(_at_)phase(_dot_)org> writes:
| > He may well have, but not everyone has had that chance, and knowledge
| > locked away in Meng's head does not allow the rest of us to discuss
| > things any more clearly.
|
| Yeah, I agree. This is one of the problems with these behind-the-scenes
| standard development processes. Many eyes make shallow bugs.
I would share the Caller-ID spec if I could, but MS asked me not to circulate
it.
I can talk about it, though! Here is the fundamental difference in a nutshell:
SPF is designed to authenticate the ENVELOPE SENDER based on the smtp client
IP.
Caller-ID is designed to authenticate the HEADERS based on the smtp client IP.
These appear to be very similar, related goals. ASTA (aka AMEY++) want
MS and SPF to "converge" so we can present a united front.
The great thing is, we can do actually do this "convergence". The goals
are not contradictory. Most people do want to authenticate both.
You want to authenticate the ENVELOPE because
- you protect the envelope sender from *joe jobs*
- the MTA can can stop forgeries before DATA without touching the MUA
You want to authenticate the HEADERS because
- you protect the "from" address from *phishing*
- you can do this in the MUA without touching the MTA
These two goals do not have to compete. Authenticating the envelope
sender is most naturally done by the border MTA. Authenticating the
headers is most naturally done by the end-user MUA. If people want to
do both, they can!
If the MTA has a problem with the ENVELOPE, it can reject the message
during SMTP time (thereby achieving FP-friendliness) or by adding a
"Received-SPF: fail" header to be parsed by a downstream MDA or MUA.
If the MUA has a problem with the HEADERS, it can mark the message as
suspicious by doing some kind of display-time ornamentation, eg. a cute
little animation of a robot going DANGER WILL ROBINSON.
The SPF framework itself is formally agnostic about the issue of
envelope vs. headers. SPF's designated sender mechanisms just tell you
if an IP is good for a given domain. That IP could be plucked from a
live TCP connection, or it could be dug out of the Received headers.
The same SPF declarations can be used in service of either kind of
authentication. Historically, we have focused on the envelope, because
getting into headers opens a huge can of worms. But an intelligent MUA
is welcome to apply the test to the headers. SpamAssassin is already
performing SPF checks on the Return-Path, but it's having a lot of
trouble with odd or noncompliant MTAs that munge the Return-Path. If it
wants to work on the headers, that might make life easier. (Justin, let
me know what you think.)
The first thing that comes to everyone's mind is "but what about forgery?"
The Caller-ID spec proposes a way to authenticate headers by first
looking at Resent-Sender, then Resent-From, then Sender, then From.
That algorithm probably needs to mature but until something
cryptographic comes along that is really is the best that we can do. It
isn't perfect but it seems like it might work. And people really,
really want header authentication in addition to envelope authentication.
Now, what are the implications for the SPF project? Absolutely none.
As far as I'm concerned the best place to do SPF tests is still at the
border MTA and the natural subject of authentication is the envelope.
The only functional difference is that forwarders now have to prepend
some sort of "Resent-*" header, but since they're already groaning under
the weight of rewriting the envelope sender this will be quite trivial.
I don't think they'll mind.
But here's the good news: if people want to go ahead and start testing
the headers using the Caller-ID algorithm, they are very welcome to do
that. If the shadowy but precocious AI that sits spider-like at the
heart of the Apple product design oracle is listening, hey, maybe Mac
Mail can start developing in this direction.
If people feel positive about this new inclusiveness, I will make some
editorial changes to the spec to shift the emphasis. The subject of
authentication doesn't have to come from the envelope. People can use
any domain they like and on their head be it.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
Wiki:
http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/HomePage
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡