[forwarded here so that people are aware of discussions on spf & dns]
---------- Forwarded message ----------
Date: Wed, 12 Jan 2005 22:08:36 +0000
From: Paul Vixie <paul(_at_)vix(_dot_)com>
To: namedroppers(_at_)ops(_dot_)ietf(_dot_)org
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt
i'm trying hard to limit my comments on this thread to the dns-relevant bits.
Rapid deployment has, for better or worse, influenced many of our decisions
if you're basically just pandering to your installed base, why not admit this,
tell the IETF what you've done in the form of an FYI, and give yourself a rest?
The zone cut stuff is working, in practice, for me in my beta-code.
If it can't be made to work, or we can find another idea that would
work better, I'm all for dropping it.
anything can be made to work in beta-code. when you seek universal deployment,
the size of that universe dictates that you work within the letter and spirit
of the spec rather than within the loopholes and enforceability limits.
the way this would look in your draft is something like:
"SPF Clients should take precautions to reject e-mail containing
nonexistent domain names; SPF Publishers should be aware that this
will occur, and avoid emitting legitimate e-mail containing such
domain names."
Again, always rejecting email from non-existent domains doesn't solve
all of the problem that the zone cut tries to solve. You are
requiring that all email senders fix their systems to not issue bad
MAIL FROM/HELO domains, rather than just those domain owners that want
to use SPF.
i have been running this way for a couple of years. rarely i'll get a phone
call from somebody who tried to HELO me from a NAT'd host whose hostname was
not visible in external dns. i always apologize and then give them my "fax"
number. this hasn't happened since spring 2004, and i get a LOT of mail from
a LOT of places. are you sure your information on this is as current as mine?
(Or, another way to look at it is that you are requiring SPF clients
to reject legitimate email just because they check SPF records.)
here, we're quibbling over what it means for e-mail to be "legitimate". the
spirit of HELO is "this is my hostname". while "HELO localhost" is legitimate
under the letter of RFC 2821, i'd argue that it's a violation of the spirit of
RFC 2821. given that you're asking RFC 2821 server-side implementations to
consider rejecting e-mail for reasons not contemplated by RFC 2821, it's hard
for me to understand you when you say...
That won't fly, deployment wise.
but whatever. let's move on.
Also, the zone cut language doesn't just deal with cases of
non-existent domains. It also means that you don't have to publish
SPF records for all the hosts in your domain. You just need to
publish the ones that are involved with non-forged email.
i was thinking that you'd publish SPF records for things that had MX
records, or at worst, from things that had (MX or A or AAAA) records.
if you're having trouble doing this, take a look at the "m4" or "cpp"
preprocessors, or ask your DNS vendor for a built in macro processing
facility.
This is getting somewhat out of the area of DNS and into email. What
would be extremely useful for SPF, and other anti-forgery systems such
as Yahoo's DomainKeys or Cisco's IIM, is the ability for a domain
owner to be able to speak for their entire domain. Can we find a DNS
way of doing that?
ultimately your concern is about nonexistent subdomains. if a forger can
get more value out of spoofing nonexistent subdomains than from spoofing
nonexistent unrelated domains, then i've been out of the anti-spam world
longer than i thought. here's what it sounds like you ought to do.
1. codify current behaviour (not the beta-code behaviour; the global one)
2. explain the good and bad aspects of the current dns wildcard features
3. launch a separate effort to add a rrtype-specific wildcard dns feature
... I think it would be reasonable to require domain owners that wish
to use the zone default SPF record to have a working zone. As long as
broken zones don't cause problems for SPF checkers, that shouldn't be
too bad.
i'm thinking of all dns queries that will be received by nonparticipants,
and sent by SPF Clients to those nonparticipants upon every inbound SMTP
session.
(one non-dns-related side note: somebody around here told me recently that
they had had to delete their SPF records because one or more SPF Clients
had implemented SPF improperly, and were rejecting mailing list e-mail
based on the mismatch between the header From: and the list exploder. all
this proves is that no matter how careful a specification is authored, it
still has to run the gauntlet of wide scale implementation.)
--
to unsubscribe send a message to
namedroppers-request(_at_)ops(_dot_)ietf(_dot_)org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>