Subject: [spfbis] New issue? A language complementary to RFC 2119

From: Alessandro Vesely <[email-masked]>
Date: Fri, 06 Apr 2012 16:10:58 +0200

SPF did a number of pioneering endeavors, so maybe this one deserves
being here as well.  OTOH, it is quite overstretching  to include this
issue in the charter, so maybe it should be aired somewhere else.

RFC 2119 defines imperatives that are required for interoperability.
A message delivery is typically not interpreted in such way, so we
cannot write "Receivers MUST reject if the result is Fail".  As a
consequence, we are forced to use circumlocutory language that is
often not clear enough.

Should we define some imperatives that express the actions that a
receiver is expected to take according of the meaning of protocol
tokens such as "-all"?  If we do, then we'll be able to confer a
precise technical meaning to sentences like, e.g., "Receivers NEED
reject if the result is Fail, CAN reject on PermError, and DARE reject
on TempError".  Uh?

Just wondering

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 06 Apr 2012 10:24:14 -0400

> reject if the result is Fail, CAN reject on PermError, and DARE reject

No.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 6 Apr 2012 14:49:07 -0000

>No.

+1 on that No.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Fri, 06 Apr 2012 11:48:09 -0400

Alessandro Vesely wrote:

> tokens such as "-all"?  

Yes. Already done.  A sender violation of a SPF HARD FAIL domain 
policy should always be a rejection.  Ignoring this defeats the high 
benefit SPF potential and purpose SPF offers and wastes everyone's 
time across the board when not honored. It certainly violates the 
domain's wishes to secure and protect its brand. Note, of course, a 
receiver can decide to accept the failed SPF message and tag it or 
whatever, but its certainly not doing the DOMAIN any favor.

> If we do, then we'll be able to confer a

No.

Rejection Mandates could only be technically justified as a zero false 
positive/negative (depending on your pov) verification or validation 
result where there are absolutely NO accidents or errors, in which 
case, it is indeterminate state and the protocol failed.

It is a blessing and curse.  Its blessing when the protocol works as 
expected and there no errors.  Its a curse when the protocol doesn't 
work or weak policy provisions are used because it continues to 
provide the legacy loop hole for "bad-guys" to get around any sort of 
strong rejection policies without a zero-false positive result.

On the other hand, there is nothing stopping an implementation from 
learning the failure rates and using some scoring concept where an 
indeterminate condition could be promoted/demoted to a more stronger 
actionable state.

-- 
Hector Santos, CTO
http://www.santronics.com
http://hector.wildcatblog.com