ietf-822
[Top] [All Lists]

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

2005-03-04 14:12:03

On Fri March 4 2005 09:24, Keith Moore wrote:

Well, that was Wayne's comment.  From my perspective (as a mobile
user (i.e. connecting via an unpredictable IP address) with need
to use only a few domain names) I'd phrase the issue as "being
able to use any IP address"; and that's where SPF utterly fails.

or to put it another way, SPF is not applicable to that case.

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.

It's not immediately clear whether a domain holder has any right to
insist that mail traffic "from" that domain 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.

and a number of ISPs and networks are blocking 
outbound access to port 25, thus forcing their users to send
outgoing mail via their SMTP servers (they may permit use of another
network's submission server on port 587).

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.

it doesn't do much to address the 
problem of an MTA or recipient that wants to avoid handling 
unauthorized mail.

In the context of mail, i.e. requiring no prior arrangement
as noted in Dave Crocker's architecture draft, "unauthorized
mail" makes little sense. 

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>.

An SMTP receiver for some domain,
say example.net, might avoid relaying by refusing to accept
message DATA which is neither MAIL FROM its domain nor destined
for an RCPT TO its domain (and it had better not be too picky
about the MAIL FROM part, as legitimate users within the
example.net domain might desire or need to specify a different
mailbox for bounces).  As far as acceptance of messages for
RCPT TO in example.net, nothing else is relevant: the return
path (MAIL FROM) indicates where to send bounces, and plays
no role in any sort of authentication, EHLO/HELO domain is
often forced by client software to be the same as the return
path domain, so is uninformative, and IP address is irrelevant.

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.

what might be useful is for an MSA to use SMTP AUTH to establish 
credentials of an originator, and then use that to add headers to a 
message authenticating that message as being from that originator.  
(though you need some way for the originator to defeat that in case
he wants to be anonymous)

Maybe. My ISP (when I can reach it) does that, and if you check
past list messages (from more than a few days ago) you'll
probably see (assuming that you get list messages in  undigested
form) lines like:
X-Info: This message was accepted for relay by
      smtp02.mrf.mail.rcn.net as the sender used SMTP authentication
Whoopee -- anybody with a working printf can forge such a line,
so that doesn't seem to do much.

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)

Keith