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

[Rick Moen]

Quoting Daniel Gimpelevich (daniel at gimpelevich.san-francisco.ca.us):

> Thanks for the pointer on the DNS report site. I have used it to check my
> domain, and one of the warnings it issued troubles me, regarding an SPF
> record. I have never heard of one of those before. Do you have any
> pointers on how not to muck one of those up?

The best sort of pointer:  There's a CGI generator to concoct them.
It's a lazy sysadmin's dream.

But, first, to explain:  One of the long-term problems of the mail
system is forgery.  To a large extent, the ability to forge SMTP is
inherent and can't easily be fixed.  For example, the only header
information in an individial e-mail, received from some other SMTP
server, that you as an SMTP server admin might have reason to regard as
trustworthy, is the Received header that was appended by _your_ SMTP 
server to record the handoff from the immediately preceding SMTP host --
which header of course might be buried in a thicket of forged ones.
Even that header may contain lying information from the preceding SMTP 
host (a claimed hostname) -- but it'll have one actual real datum, the
host's IP address.

In early 1997, a spammer in Chicago figured out how to _also_ forge the
"envelope" information that is conveyed to the receiving SMTP host.  He 
used this new trick to hoodwink most of the anti-spam community into
attacking reputable Web-hosting provider Joe Doll of Saratoga,
California.  (Doll had thrown the spammer off for violating his terms of
service.  The spammer wished to punish him for that.)  I was among the 
recipients of that infamous revenge spam, which gave us the term "Joe-Job".

I have information on that incident inside http://linuxmafia.com/kb/Mail/ .

SPF records are, quite simply, a type of DNS record that gives others
information sufficient to let them detect (and thus not be fooled by)
Joe-Jobs.  The idea is analogous to that of "NS" records:  A domain's
"NS" records indicate to the public which IP addresses are the sole
authoritative nameservers for the domain.  By analogy, a domain's SPF
records indicate which IP addresses are the sole authorised MX hosts
(mail exchangers) for the domain -- the sole IP addresses that all
legitimate SMTP mail from that domain must come from.

There are situations that don't readily lend themselves to SPF
authentication, notably mail forwarding and the sloppier varieties of 
mail handling during mobile computing.  There are also countermeasures
to adapt those situations to a changing world that has SPF records in
it.

Here's the informational Web site:  http://spf.pobox.com/
Notice the "SPF Wizard" on the middle left:  That will ask you some
questions and generate an appropriate SPF RR for your domain.

Notice that SPF records are hidden away inside specially formatted
contents for "TXT" RRs:  There's a reason for that, and it's covered in
the SPF FAQ on that site.

Implementing _use_ of SPF records by a mail server is a slightly more
difficult (and separate) problem, but _advertising_ SPF records for
one's own domain is dead-simple, and I see no reason why all domain
owners wouldn't want to do it.  For one thing, doing that allows other
sites that _do_ check SPF RRs on incoming mail to reject all forged mail
with forged envelopes purporting to come from your domain but actually
originating from third-party SMTP hosts elsewhere.  So, you win
immediately, on that.

> I also noticed the lack of a check for validity of my RP record. Any
> online checks for that?

No, I don't.  And I actually hadn't heard of Responsible Person RRs
until you mentioned them, so I thank you for calling them to my
attention.  Here's one online reference I found, just in case anyone
else was confused:  http://users.aber.ac.uk/ahj/dnshome1.html#RP

Looks like they would be difficult to mess up, in any event. ;->