spf-discuss
[Top] [All Lists]

Comments on spf-draft-20040209.txt

2004-03-21 22:10:00

 quoting from spf-draft-20040209.txt,


8.5 Conformance with regard to a particular SMTP transaction

   An email message during delivery is conformant if SPF evaluation
   results in a "pass", "neutral", or "softfail".

So presumably "fail" means that it isn't conformant.  Should that be
explicit?


8.7 Rejection of non-SPF conformant email

   Mail from a domain SHOULD NOT be automatically treated as suspect
   just because the domain doesn't publish SPF records.

This seems to only be talking about SMTP transactions which result in
"unknown" from SPF processing.  which rather leaves "fail" out in the
cold.
I think 8.7 should be completely removed, along with all other
mentions of rejecting or accepting email except those in (what is now)
8.8. This includes removing the references in the start of section 3.



8.8 Rejection of SPF conformant email

   An SPF email system MAY choose to reject or discard email on the
   basis of local policy.  SPF is one component in an overall
   email-policy engine.  SPF merely makes it possible for policy
   decisions to be made with confidence at the sender-domain level.  The
   actual policy decisions are outside the scope of this document.

This section correctly emphasises that SPF is merely one input to a
mail control policy.  Possibly that emphasis should be strengthened,
and, as I mentioned above, any reference to policy elsewhere should be
removed. 
SPF is a mechanism for mapping an IP address and a responsible sender
to one of None, Neutral, Pass, Fail, Softfail, Unknown, and Error.

I think the spec should not say anything about how the MTA (or MUA or
whatever) might respond to these status, but should be very explicit
about exactly what information is carried

As I understand it:

   None:      no information is available (through omission).
   Neutral:   no information is available (deliberately).
   Unknown:   no information is available (due to incompetence I
              think)
   Error:     no information is available now, though it might be
              later. 
   Pass:      the return address can be assumed to be authentic
   Fail:      the message did not come directly from the given
              address, though it might have come indirectly.
   Softfail:  the message may have come directly from the given
              address, but such usage in being phased out.

Possibly there should be a separate document that discusses how the
information provided by SPF can be incorporated into a
junk-mail-control policy.

In short, I would like to see the distinction between Mechanism and
Policy even clearer than it currently is.

NeilBrown


<Prev in Thread] Current Thread [Next in Thread>
  • Comments on spf-draft-20040209.txt, Neil Brown <=