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 
> manual.
> 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:

- Introduction
  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.


My 2c.

Radu.









> 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
> > concentrate on:
> >       * creating a record from scratch for various kinds of setups
> >       * how those default records can be modified to expand or restrict
> >         their use
> >       * examples that show when compiling your record is going to be a
> >         net gain
>
> 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.