On Mon, Mar 08, 2004 at 04:31:38PM -0600, David B Funk wrote:
>
> Have you looked at the SPF "Objections Addressed" page?
> http://spf.pobox.com/objections.html
>
I wanted to address this in a bit more detail, so here's a summation of
each addressed objection on that page:
1) Traveling Mailman problem.
Solution: SPF exceptions, SASL (infrastructure change).
Problems with solution: Limit to number and size of TXT records, rapid
burgeoning of number off TXT records individual/group must maintain,
leading to huge administrative headache. Also, the "change your
infrastructure to address problem we created" solution is not just a
non-starter, it's simply rude.
2) Cybercafe.
Solution: MSA (infrastructure change).
Problems with solution: Again, their response to "SPF creates a
problem" is, "solve the problem by changing your infrastructure."
Unacceptable. Furthermore, their justification for this solution is
that ISP's block port 25 outbound. What in Ghu's name makes anyone
think they won't simply start blocking 587 outbound as well?
3) Forwarding and Return-Path.
Solution: Use your ISPs domain for all outgoing email, or connect
through a single (or handful of) "blessed" MXes for whichever domain you
wish to use. The ability to, say, send email using a domain you own
from the dynamic IP granted you by your ISP (as I do) will disappear.
Problems with solution: Many ISPs do not respond to MX problems in a
timely manner. Many ISPs handle a load that unnecessarily increases
delivery times. Many ISPs do not deserve the de facto free advertising
granted them by using their domain name instead of one owned by the
end-user. Many end-users find themselves behind ISPs other than the
one controlling the domain they use for email on a regular basis
-- business travellers, vacationers, busy people with home computers, work
computers, and mobile devices, each with their own ISP and IPs, but each
capable of sending an email with a single domain as the RHS of an email
address. Many end-users take advantage of .forward files and
/etc/mail/aliases functionality to have email sent to other addresses
instead of or including the original destination. Here again, their
solution is "rearchitect your MTA". And here, again, that solution is
simply unacceptable, because it says, "we created a new problem. It's
up to you to fix it. We can't be bothered."
4) Conscientious Objectors (aka "People who don't publish SPF records")
Solution: Treat anyone without an SPF record as suspect.
Problems with solution: This is not a good way to ensure a smooth
transition to a new approach, particularly not one as disruptive as SPF.
Know what the end result will be? Many sites advertising SPF records,
and nobody acting on them.
They even have the nerve to say (and I quote directly from the page):
"Domains who do this are the same domains who run open relays."
I beg to differ, and I find the tone -- and the underlying implications
-- insulting.
5) Throwaway domains.
Solution: SPF doesn't have a solution to this.
Problems with solution: Spammers will simply flock to this gaping hole,
as well as begin dredging up old DNS spoofing and poisoning attacks.
(By the way, that last bit about reputation systems seems to have been
added since last I read that page. I find it interesting, since that's
the approach I favor (and have done some work on), and I've insisted all
along that it must be coupled with other approaches. What bothers me
tremendously about SPF, aside from what I mention above, is that they're
willing to deploy without this crucial dependency, whereas I'd never
advocate rolling out one without the other! Without both pieces in
place, rolling out either is suicide.)
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
