Re: spf cookbook
David MacQuigg wrote:
Andy, I'll be glad to help with this. My suggestion is to keep it
short, concentrate on simple examples, and add more complex stuff
later. 90% of admins setting up an SPF record will probably not read a
manual. More likely, they will start by running a webtool and looking
at some examples. I'm thinking of something like mxtoolbox.com, but
with a few more buttons and one more textbox, where we can show the
final compiled record. This webtool should have the same user interface
as a tool they can download and install on their own server.
We should write the manual with the webtool in mind, so we can just copy
examples into the tool. We might even make the manual an HTML
document. Then we can link from the tool directly to sections in the
The first example should have nothing but an IP address. Edit the form,
putting in your own mail-server address, press a button and see a
properly formatted SPF record for your server in the textbox below.
The next example might have a +mx item. The "description" field next to
that item has a brief explanation, and a "What's This" button leads to a
more complete explanation, including motivation - "Why do we need this?"
At this point, and before getting into more complex syntax, we could
have an example of a big record with lots of ip4's, maybe large enough
to generate an m=ip/block in the compiled record. We'll find an example
like rr.com but even bigger, to make the point that you can set up some
very big domains using only the simplest syntax.
This will get us to the point where the vast majority of domains can set
up their records correctly and efficiently. The more complex syntax can
be an option for those who really want it.
I would suggest that will people come to this document with two
questions in mind:
1. What is SPF and what's in it for me ?
2. What should _I_ publish?
I would structure it like so:
Explains what SPF is, why is it needed, and who needs it.
- Typical use scenarios
Lists a recommended record for each user type.
- Vanity domain owner/small business/retail website
Explain the simplest form possible in simple terms.
This is for photographers/artists who want the whole internet thing
to be as little headache as possible. They use a service
provider that does everything for them (DNS/website/email/the works)
Suggest they ask their mail service provider to take care
of the details. "Dear service provider, I want SPF!"
- Power vanity domain owners.
Explain a simple record in slightly more technical detail.
Show how multiple ISPs can be used.
- Small domain owners.
The audience are hobbyists who know a fair deal, and like to learn
more about the technology. They run their own DNS/mail servers.
The explanations here can be as technical as it gets.
It should be mentioned that macros can be used to perform
more fancy checks if necessary, but should not dwell on it.
We don't want to encourage this. Those who need the complication
should know where to go, and are probably willing to look into
the details. In fact, use of macros and DNS mechanisms should
be discouraged. Those who really need them will know what
to do (read the standard, look at the ISP setup section below)
- Large domain owners.
Typically companies and small ISPs.
They care about the most reliable record possible.
A quick analysis of SPF vs. no SPF scenarios.
Outline the different mechanisms available.
Outline the DNS loads, and the risks involved (ie, a DNS server
with load-sharing features may not provide a complete list of
mail servers in reponse to a MX query or a complete list of IPs
in response to an A query).
Mention compiled record as a method to make mail more reliable
and DNS infrastructure less costly.
- Largest domain owners.
Yahoo, Ebay,etc + the popular ISPs (aol, rr, earthlink, etc)
A more in depth reliability vs cost analysis.
A quick analysis of SPF vs. no SPF scenarios.
Full technical details.
- Quick Reference.
List all mechanisms, what they can do, what configurations can
benefit the most from them.
At 07:12 PM 3/25/2005 -0600, you wrote:
I'd like to get the "SPF Cookbook and Best Practices" document going.
Let's work on it here on spf-discuss, and if we need to move it to a
dedicated mailing list, we can later.
The kinds of things asked on spf-help is a good place to start, I
assume, someone on spf-help will have to confirm that. But rather than
Frequently Asked Questions, it might be better to start with, for a
cookbook format, Frequently Provided Answers.
To kick things off, here's a list of areas that I think we should
* creating a record from scratch for various kinds of setups
* how those default records can be modified to expand or restrict
* examples that show when compiling your record is going to be a
The difference between the source record and the compiled record will be
obvious when seen side-by-side in the webtool.
* instructions on deploying SPF checkers for the popular MTAs
* instructions on deploying SPF compilers for popular name servers
We probably want to de-emphasize the built-in compilers, since that will
require a patch that some admins may be reluctant to install on a
running nameserver. Initially, a separate daemon can provide a common
interface to any nameserver. Later if there is an advantage, an SPF
compiler can be added to the nameserver. I think that would be up to
the vendor that makes the nameserver.