On Fri, 2004-07-09 at 16:43, Seth Goodman wrote:
In Unified SPF, the semantics are there to do both SPF classic and MTAMARK,
among other things. My argument is that if a netblock owner expresses a
policy on the permitted use of their netblock by publishing an SPF record,
then in case of conflict with the domain owner's published policy, Unified
SPF shouldn't build in a mechanism that makes the domain owner's policy
dominant. That's all I'm arguing.
The domain owner controls the use of their domain name and is free to
publish "v=spf1 +all". Their domain, their rules. However, a netblock
owner (ISP) can also express a policy, which could be "v=spf1 mx:/24
ip4:192.1.2.3/18 -all", which designates their own MTA farm and their static
IP netblock. Their MTA, their netblock, their rules.
Let's switch to a different context: Imagine that unified SPF were
extended to not only allow an ISP to disclaim responsibility for direct
SMTP initiated from within their netblock, but to also allow an ISP to
disclaim responsibility for ssh sessions initiated from within their
netblock.
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?
If your answer is "no", then why is the answer different for email?
In the PTR scope proposal, just as in the ssh example above, if a
netblock owner greylisted (?) a section of their netblock like that,
recipients implementing the PTR policy would require an unequivocal
level of authentication and (possibly) a positive reputation statement,
*and* would know that they could not complain to the IP-block owner
about icky content.
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.
As a general rule, I don't care to enforce someone else's policies.
However, I have no objections to listening to someone else's statements
on how to authenticate claims that are purportedly made on their
behalf. Yes, that's tracking someone else's policies, but it's within a
very limited scope (authentication) and it's a scope that I find
personally useful.
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)?
Why should *I* work to strictly enforce such a policy of *theirs*,
especially if a reputable and authenticatable party emails (sshs) me
from there?
However, a policy listing of "we don't email from this netblock" is
specific, and it's a direct authentication claim that's useful to me.
So, I *do* care if their policy item 3b-5 says that emails claiming to
be from them (in whatever sense), can _never_be_authentic_ if they come
from this netblock.
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.
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.
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.)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com