From: Mark Shewmaker
Sent: Friday, July 09, 2004 6:25 PM
<...>
In other words, not only could an ISP use a PTR scope to say: "No
emails from this netblock", that they could also say: "No ssh
connections from this netblock".
Then suppose your machine gets an ssh connection attempt from that
netblock, a connection that used the correct private key of the user,
and used their password also.
Should you reject the incoming ssh session because the ISP says they
won't accept any complaints about its content?
SPF has nothing to do with anything but email, and ssh connections are a
whole different kettle of fish from SMTP connections. That being said,
there is another distinction that you made that I believe is incorrect.
A netblock owner publishing a policy that says no legitimate email comes
from these IP addresses does not remotely imply that they will not
accept complaints. You are correct that they will probably not be
concerned with the _content_ of any emails sent, but they will be
appreciative of complaints about the _use_ of their IP's. In either
case, the result will be the same.
<...>
In both the SMTP and SSH examples, the recipient need not be concerned
about the ISP's policy on what they approve of or not--but
only with the
ISP's policy on what *they* will authenticate and stand behind.
I completely agree. Without the much-ballyhooed accreditation services,
however, there is currently no other way to authenticate the sender. I,
for one, do not believe that such services will be available in the
foreseeable future other than from a small selection of mega-companies
(the usual suspects), so I am unlikely, as will be many others, to take
advantage of them.
<...>
A policy listing of "we don't allow any emails from this netblock" is
too general to be of much use to me. Why should I care that their
policy item 3b-5 says that it's against their AUP to email from that
netblock, (or that it's against their AUP to ssh from that netblock)?
Because they are ultimately responsible for the traffic that emanates
from that IP until they either delegate it to someone else or change the
PTR record to some domain other than theirs. As long as they are
accountable for the traffic on those IP's, they should have the
authority to make binding policy statements on the use of those IP's.
That's why an SPF test based on the PTR domain has such importance. It
is a real statement of accountability and responsibility.
As a practical matter, they are really saying that the particular IP's
are consumer grade, dynamic IP lines and it is very likely, though not a
certainty, that the operators are incapable of maintaining an MTA.
Since the IP is dynamic, blacklisting it based on spamming would be
pointless. In actual fact, most mail traffic coming from those IP's is
spam or viruses. Users who want to maintain their own MTA need a
designated IP so that _they_ can be held accountable for what they send
out. In that case, the ISP changes the PTR record to the end-user's
domain. If the IP block is a /24 or larger, the ISP usually delegates
the block to the user and is done with it. Again, the PTR domain really
indicates who is accountable for the traffic on that IP, so that's the
party whose policy statement we should listen to.
<...>
If SPF is about authentication, then the PTR scope that was suggested
makes perfect sense to me, as it basically says to me that if there is
an issue with an email from that netblock, that complaints to the
netblock owner will fall on mostly-deaf ears, so you had
better be sure
that you can separately authenticate the party in question and that
they're reputable.
I don't agree with the assertion of complaints falling on deaf ears.
Just because they publish a policy of no emails from a certain netblock
doesn't mean that they aren't interested in complaints on that. In
fact, it is in their economic interest to solicit such complaints.
Everything remains related to authentication and standing behind
published statements. Very sensible, and I don't see a problem with
that.
Side note one: (nitpicking) Domain owner policies wouldn't
completely
trump the netblock owner's policies, as the recipient would
only accept
the message if the domain owner had both a PASS and a positive
reputation--so the domain owner merely has a higher bar to pass than
normal.
As far as I can see, these reputation systems are simply pipe dreams.
They may come about and they may not. Right now, without the reputation
systems, we are considering building a mechanism into SPF that allows a
malicious party to override the published policy of the netblock owner.
I respectfully suggest that is a poor idea.
Side note two: One thing I really like about the whole idea of PTR
scope is that it allows for the possibility of a time in the
future when
ISPs can safely unblock port 25. (If SPF takes off like wildfire, and
people publish PTR scope carve-outs, then virus-writers who make their
taken-over machines send random mails through port 25 will largely be
wasting their resources, as folks won't accept mail from that block
except from provably authentic and still-reputable
domains--and so virus
writers will probably switch to different and more
effective-in-spf-world strategies for use in their taken-over
machines.)
I completely agree with this. How does that square with your position
of allowing the domain owner even a partial override of the netblock
owner's policy? This seems to require a reliable reputation service.
What if such services were only provided by certain corporate behemoths
on a subscription basis? Does that say we are building an
authentication system that only works well if you purchase a monthly
subscription from [fill in your least favorite corporate behemoth]?
Without a reliable reputation service, I'm sure you'd agree that most
mail coming from the IP's in question is junk (think Comcast).
IMHO, our open source authentication system ought to work well without
outside reputation or accreditation systems wherever possible. I
believe this is one case where it is possible. Following is a
suggestion that I believe could make everyone happy.
I propose that we make it the default behavior that a PTR SPF fail
should give an overall SPF fail result. However, recipients with access
to a reputation system can configure the SPF parser to override a PTR
SPF fail with the MAIL FROM: result _if_ the reputation score is high
enough (however that is determined). In that case, the default setup
would honor the netblock owners policy, if it exists, and a recipient
without a reputation service would avoid the huge preponderance of
forgeries that come from those IP's. To receive desired mail from IP's
that the netblock owners say are verboten for MTA's, a recipient without
access to a reputation service would whitelist particular IP blocks (or
IP block/domain combinations, if we want to get fancy). OTOH,
recipients with access to a reputation service get the behavior that you
would like by flipping a configuration switch. That sounds like a
win-win.
--
Seth Goodman