On Fri, 1 Oct 2004, John Glube wrote:
|Recently, Stuart has suggested that the SPF record is a
|great place to publish sender policy, but that the idea of
|publishing designated senders by IP may be questionable. I
I think that designated IPs work great for the first hop, and should
be kept. I just think that SPF should incorporate other methods
as well. The designated IP is extremely efficient for the first hop.
I envision additional methods coming after first hop validation.
Here is an example that can be done now with SPF classic:
example.com IN TXT
"v=spf1 mx a:smtp.example.com exists:%{l}._ses.example.com -all"
First, the IP is checked. If this is a first hop and it matches, GREAT, the
SPF record was probably cached and we have validated the MAIL FROM
(or HELO) with a minimum of resources.
Otherwise, the local part (which has been SES signed) is validated with
a custom DNS server (which can be behind a standard DNS server via
delegation for security and stability). If it validates, the mail is
good regardless of forwarders etc. If it doesn't, it is a forgery.
An SES signature can follow any system desired by the sender. My version
has a message id, time stamp, hash key. Positive validations for a given
message id are limited to prevent mass replays from a stolen signature (each
message has a unique timestamp/id). Seth's version currently hashes a
canonical version of the entire message - thus signing the RFC822 headers in a
manner much more efficient than Domain Keys. No message id is needed in that
case. (But you are screwed by forwarders that modify the message in ways that
break canonicalization.)
Notice that mistakes in the IP address validation resulting in FAIL are not
fatal, they simply result in additional queries to the SES validator. With
proper logging, (with input from additional macros in a more complex exists
clause), the error will be automatically identified and the sysadmin notified
to be fixed as time is available.
Mistakes in the IP section that allow forgeries are more serious, but
do not result in good mail getting rejected.
If the sender does not have access to a trusted MTA (e.g. their ISP
blocks port 25 but stupidly does not then bother to prevent cross customer
forgery), then their SPF record would rely exclusively on exists with SES
(or some future scheme).
This is all with SPF classic. There are no protocol changes to SPF. This is
all a matter of software installed by the sender. The only roadblock to my
version of such software for Python is getting a small version of a Python
Custom DNS. I don't want to include the entire Python Twisted framework.
Pointers welcome. I am currently slowly finding time to retrofit an
old version of dnspython.
In the future, additional modifiers can refine this and add additional
mechanisms. For instance, it would be nice if a sender could indicate when the
SES signature includes a hash of the message - allowing the receiver to
validate RFC822 headers as well. (Although currently, that can be indicated by
a special format for the SES signature.)
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.