Hello,

I'm doing what I hope are the final bug fixes on an authentication record compiler.  No more manual assembly of Registry records!!  This compiler will help senders set up their SPF and other DNS records so that we can extract a concise list of authorized transmitters for their domain.  The compiler will accept a simple list of IP blocks, or references to other records, including A, MX, TXT, and SPF records.  SPF records are searched recursively to four levels.  See Registry Records for details.

I have an email interface to this compiler, not as slick as our webtool, but it's got all the essentials.  You'll need to use this interface for a final test, even if you use the webtool for the setup.

I've tested for simple errors - records too long, random garbage, etc. The ideal final test is 1000 users making subtle errors in their authentication record setup. Since that will take a long time, we can accelerate the process with a few clever admins throwing me their best curve balls.

Try a simple setup first, then see if you can mess it up.  Try wierd, unexpected stuff, like a dot where we expect a comma, etc.  All is fair except a DoS attack.  We don't have enough servers yet.  Don't forget to put your DNS records back to normal when you are done testing.

Here is an example setup:


_auth.example.com. TXT
    "method=SPF,DK helo=87.228.80.244/28,72.21.196.0/23,69.9.25.0/24,87.228.80.230-42"

And the resulting display of the compiled record:
   method = spf,dk
   options = df:8
   69.9.25.0-255           256           small blocks as ranges
   72.21.196.0/23          512           large CIDR block
   87.228.80.230-55         26           merge of two blocks
           Totals:   3     794


Just change example.com to <your domain>, change one of the IP address blocks to include your transmitter, add this record to your DNS, then send a test mail to "test at open-mail.org". You should get a response by email if everything is OK, or an SMTP REJECT if not. The response should show your IP blocks in "canonical form" (overlapping blocks merged, sorted, and displayed in a nice tabular format). Read the response message, then plan your next move.

The REJECT messages are not yet as polished as I would like.  The goal is to make them so clear and concise that they provide a complete, easy-to-use test system for your authentication records.  Let me know if there is confusion, or you can think of any improvements.

All suggestions are welcome. Thanks for your help.

-- Dave


P.S. If you don't have convenient access to the HELO and MAIL FROM names on your regular server, a simple telnet session will do.  You can repeat the rcpt command to do a sequence of tests.

$ telnet open-mail.org 25
220 open-mail.org ESMTP Sendmail 8.13.1/8.13.1; Thu, 19 Jul 2007 18:03:29 -0400
helo phred.box61.com                                 [Note 1]
250 open-mail.org Hello box61.com [65.99.217.159], pleased to meet you
mail from:<dave at box61.com>                        [Note 1]
250 2.1.0 <dave at box61.com>... Sender ok
rcpt to:<test at open-mail.org>
250 2.1.5 <test at open-mail.org>... Recipient ok   [ OR a REJECT message ]
quit
221 2.0.0 open-mail.org closing connection


[Note 1] Be sure to use your own registered domain name in both the HELO and MAIL FROM commands.  This is necessary to avoid abuse of our test address.