ietf-822
[Top] [All Lists]

Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt

2005-03-06 12:35:21

On Fri March 4 2005 16:11, Keith Moore wrote:

The problem is that if the ISP that handles my *incoming* mail
decides to use SPF and list only their *outbound* MTA IP addresses,
I am screwed.

For that matter, if your ISP that handles your incoming mail lists the
wrong MX records, you are also screwed.  You can think of it as a flaw
in SPF, but most of our protocols require correct configuration of DNS
to work properly in practice.

But there is a crucial difference in the two cases; MX records are
by definition associated with inbound mail.  SPF conflates inbound
and outbound. 

It's not immediately clear whether a domain holder has any right to
insist that mail traffic "from" that domain

There isn't really any such thing as "mail 'from' [a] domain";
there is only the return path (for delivery error notifications,
which is not necessarily related to anything other than the desired
path for such notifications), and the forward (recipient delivery)
path(s).

only originate via  
particular IP addresses - my guess is that if nothing else, it's error-
prone, as too many network admins will assume (without adequate
justification) that all mail "from" their domains is sourced via some
set of well-known IP addresses.

That, in a nutshell, is the (flawed) set of assumptions behind SPF.
 
Yeah, that's the situation I have at the moment (local ISP blocks
25, my ISP doesn't use SSL (port 465) or run a submission server
on port 587).  The local ISP isn't so fascist that they block
465 and 587, but I suppose some might do that also.

Especially given that RFC 2476 doesn't require authentication.

If you've looked at the draft successor which was intended to be
elevated to Draft Standard status (and for which Last Call has
already ended), you may have noticed that AUTH is now required.

I should clarify that by "unauthorized mail" I meant sending a message
using MAIL FROM:<address> and/or From:<address> without having the
authorization of the party associated with <address>.

There's simply no way to detect that situation in current
protocols (and SPF does nothing to change that, due to the
flawed assumptions noted).

There are a lot of stupid policies out there.  People are so desperate
to block SPAM that they block a lot of legitimate mail in the process.
Our job is to improve the reliability of mail - which includes both
telling people how to do a better job of blocking unauthorized mail
and telling people which countermeasures do more harm than good.

Which is another reason why producing a purely descriptive
document (as Informational) that accurately documents SPF 
isn't a big deal; the logical next step would be to move
that document to Historic status on the basis that what is
described is harmful (and that is one of the criteria for
reassignment to Historic given in RFC 2026).

Well, duh.  Obviously you need something stronger than a header field
which doesn't contain any way of verifying what message it was attached
to.  Take the input message, canonicalize it, hash that, sign the hash,
put the signature in the header field.  Not rocket science (though the
canonicalization step is a bit tricky to get right)

Which is why I suggested MIME security-part wrapping; it avoids
the tricky canonicalization and prevents downstream munging.
Now that might still have similarly low chances of being
(currently, at least) widely deployed, but at this stage that's
an irrelevant detail (as neither of us seems to be making any
sort of specific proposal).