[conspire] How not to muck up DNS & domain registration

[Rick Moen]

Quoting William R Ward (bill at wards.net):

> OK, so before I put it back, can someone help me with this SPF thing?
> This is the string that I got from the wizard:
> 
> v=spf1 a mx ptr include:comcast.net ~all
> 
> My smarthost is the host identified by the A record, but I might
> conceivably switch the smarthost to comcast's server or to the host
> that serves as my MX server (incoming mail server).  So that looks
> right to me... any thoughts?

OK, please understand that I generally _don't_ go to all the trouble
required to parse all that gobbledygook:  My own strategy is to use the
CGI at spf.pobox.com, and 

1.  Answer the questions attentively, and then
2.  Trust that the resulting TXT record correctly implements what I told
it to implement.

But you asked if yours "looks right".  Only you can decide if what it
says looks right, but -- after sufficient deciphering -- I can probably
tell you what it means.  OK?  Let's delve in.

http://spf.pobox.com/draft-mengwong-spf-00.txt  is SPF creator Meng
Wong's draft RFC.  It says (section 2) that SPF records generally follow
the form 

   SPF-record  = version *( 1*SP ( directive | modifier ) )

So, as a first-level step, yours (above) breaks down as:

SPF version is "v=spf1"
Directives are:
  a
  mx
  ptr
  include:comcast.net
  ~all

The "~" character is described as being a prefix specifying "softfail".
Quoting the explanation of that concept:  "The message does not meet a
domain's strict definition of legitimacy, but the domain cannot
confidently state that the message is a forgery.  MTAs SHOULD accept the
message but MAY subject it to a higher transaction cost, deeper
scrutiny, or an unfavourable score."

There are several other modifiers (prefixes) besides "~", but your SPF
RR doesn't use any of those others, at the moment.

The "all" mechanism at the end of your record (with the "softfail"
modifier") is a catch-all.  If none of the preceding directives match,
it will.

The "include" directive says that an SPF client, reading your SPF RR,
would be instructed to also search SPF records at (and for) comcast.net
for a "pass" result.  (I haven't gotten to explaining the prior "a mx
ptr" stuff, yet.)  If it gets a pass on comcast.net records, then the
mechanism matches.

"a":  This mechanism matches if the sending host resolves to one of the
target domain's (your domain's) IP addresses.

"mx":  This mechanism matches if the sending host is one of the MX hosts
for the target domain.

"ptr":  This mechanism matches if the sending host's IP reverse-resolves
to within the target domain.


So, in a nutshell, messages (that profess to be from your domain, and)
that match the "a", "mx", or "ptr" mechanisms would return an SPF "pass"
result, as would messages that get a "pass" result by using
comcast.net's SPF records.  And you've said that any messages that claim
to be from your domain and _don't_ meet any of those tests might be
yours, anyway.

That last bit sounds pretty wishy-washy.  Aren't you in a position to
know which SMTP hosts are authorised to generate mail from your domain?  
If you are, then that should be "-all" (generate fail if no match),
rather than "~all" (generate softfail if no match).  Otherwise, I see
little value in bothering to say "Well, you should think it might not be
mine, but don't be too sure."

If any of the above sounds unclear, you're advised to read the RFC.
Heck, I might have flubbed interpretation of the RFC, so you might want
to read it anyway.

Personally, I just use the CGI.

linuxmafia.com's SPF record says, very simply:

                    IN      TXT     "v=spf1 a mx -all"

In other words:  "Any mail that claims to be from linuxmafia.com had
better be from an IP address that matches my domain's published A record
or my MX record.  If it doesn't, you can be sure it's a forgery because
I don't have authorised MXes anywhere else."