SPF as basis for combined proposal

On Thu, Oct 23, 2003 at 01:25:21PM -0400, Alan DeKok wrote:
| 
|   It's the most complete proposal so far.  It's reasonable to use it
| as a base for a combined proposal.

There are a number of domains already publishing records, and there's a
growing base of implementation code, so this seems sensible.

I'm making incremental changes so keep your eye on
  http://spf.pobox.com/draft-mengwong-spf-02.txt
for any updates.

|   My concerns with it are that it doesn't clearly address the warnings
| given in section 7 of RFC 2821 It discusses the issue, but I believe
| that it should specifically reference & quote that section, and
| address the issues raised in it.

This is the text I have come up with.

  5.4 Reasons for Adoption

   A domain owner may wish to restrict the set of hosts permitted to
   send email that identifies itself as coming from that domain.  SPF
   provides a consensual mechanism for domain owners to announce that
   set of hosts, and for SMTP receivers to check incoming mail against
   it.

   In response to RFC2821 section 7.1, forged email currently
   represents a significant burden on Internet infrastructure.  This
   proposal suggests that the very usability of Internet email is so
   threatened by unwanted and forged messages that adoption of SPF
   would currently do more good than harm.  See RFC1958 section 1.

   Domains whose email practices would be inconvenienced by SPF
   compliance are not required to implement it.


|   It also needs some text on dealing with attacks via non-existent
| domains.  e.g. "MAIL FROM: [email protected]".
| 

I have put this in:

5.6.3 Conformance with regard to receiving e-mail systems

   To describe itself as SPF-conformant, an SMTP receiver is REQUIRED to
   perform SPF tests where it is appropriate to do so.

   SPF tests need not be performed while an SMTP transaction is ongoing:
   if the MDA performs the test, that is sufficient.  A server NEED NOT
   reject a message; but if it does not, it SHOULD add a Received-SPF
   header.  If a server rejects a message, it SHOULD include any
   <explanation> provided by the SPF publisher.

   Receiver systems SHOULD exclude special addresses such as postmaster@
   and abuse@ from SPF processing.  See RFC2142.

   An SPF-conformant SMTP receiver is NOT REQUIRED to perform SPF tests
   on messages whose dispositions have already been decided on the basis
   of other policy.  For example, if an SMTP receiver requires that
   sender domains must possess MX or A records, and rejects transactions
   where they do not, SPF tests are moot.