From: Frank Ellermann
Sent: Friday, July 09, 2004 6:45 AM
Frank, this was not a personal attack, I was criticizing an idea that Meng
proposed in his slides. I don't own or run an ISP, I'm not out to get
people who like to do things their own way and I'm certainly not out to
disabuse domain owners from their right to express _any_ domain policy they
wish. I'm just trying to debate one specific point proposed in Meng's
slides concerning Unified SPF. While I'm not 100% sold on this concept
either, it's what is currently on the table.
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. Since PTR domains are
a permitted source for SPF query domains in Unified SPF, the ISP's policy
would result in an SPF fail for any dynamic IP that sends email when the
recipient uses the PTR domain for an SPF query. In that case, we could
easily say, "let the recipient decide". While that is clearly in the spirit
of letting anyone do anything, it is not in the interest of forgery
prevention, which is what, IMHO, SPF has always been about. Sender really
has several meanings in this context: the individual sending the message,
the owner of the purported domain and the owner of the IP being used to
introduce the message to the Internet.
So why not let the recipients decide in cases of conflict? First of all,
SPF tests are required to be deterministic in their evaluation. That is,
two different implementations MUST produce the same SPF result. Any
recipient can decide what they want to do with that result, but the result
returned by SPF cannot vary across implementations. This means that there
must be a way to resolve such conflicts within SPF so that compliant
implementations always produce the same result.
The policy statement of the netblock owner should trump the policy of a
domain owner, not because I like netblock owners (I am a domain owner, not a
netblock owner) or because I care if they make money (I don't). The reason
is that a netblock owner is ultimately responsible for the behavior of the
IP they own. ISP's can terminate a customer for bad behavior, but that
action only occurs _after_ a lot of abuse has taken place.
While allowing white hats to circumvent the netblock owner's policy to do
benign things is harmless and even fun, it is a real problem if we
facilitate black hats doing malicious things. The fact that they will
ultimately be discovered and kicked off the service is small consolation to
the domains they abused before that happened. If netblock owners express a
policy in an SPF record that they will ultimately enforce by termination
irrespective of the domain owner's wishes, why not make that the SPF default
and give recipients a better shot at rejecting forgeries? The alternative
encourages recipients to accept forgeries and then report them to blacklists
and the ISP. Recipients who wish to avoid accepting forgeries in the first
place would have to become sophisticated in their use of regexp's and
blacklists just to get around a deficiency of SPF.
A clear benefit of making the PTR domain record dominant in case of conflict
is that it allows recipients who use SPF to reject mail that the netblock
owner says cannot legitimately originate from that IP. It does not prevent
recipients from whitelisting anyone, which is easy. The reverse is not
true: it is not trivial for recipients to determine whether an IP is static
or dynamic, or if it is static but no MTA's permitted. There are
unfortunately hundreds of variations of node naming conventions in PTR
records and no single regexp or DNSBL will give the desired result.
Allowing the domain owner's policy to override the ISP's policy also
discourages ISP's from publishing at all. Why bother if any spammer can
override their SPF record with their own? Rather than encouraging ISP's to
act responsibly, we would be hampering their efforts. OTOH, if the netblock
owner does not publish a policy, or it publishes a policy that allows MTA's
on dynamic IP's, there is no conflict within SPF. In case of conflict
between the two policies, however, we have to decide which to honor.
In terms of your contention that a lot of legitimate small businesses
operate MTA's on dynamic IP's, I respectfully disagree. Unless the business
is computer programming services, most small business owners do not have the
time, skill or inclination to administer a mail server. Purchasing such
managed services outside is cheap compared to the time it takes to do it
yourself, widely available from a variety of sources large and small and not
an impediment to an operating business. As a small business owner myself, I
don't consider any entity that operates this way as anything more than a
hobby business. Call that arrogant if you like, but that's my view of it.
Corporate registration, corporate bank accounts, credit references, credit
history, business cards, letterhead, etc. are all optional, too. Most
people won't take businesses without these seriously, so don't be surprised
that inability to reliably deliver their email might be on that list. I'm
not saying that no one can do this. That is a matter of personal choice.
I'm just disagreeing with your suggestion that doing anything that
interferes with the ability of someone to run an MTA on a dynamic IP line
against the published policy of their ISP will cause problems for a
significant number of legitimate businesses.
--
Seth Goodman