Subject: [spfbis] Suggestions for SPF-BIS

From: Hector Santos <[email-masked]>
Date: Tue, 27 Dec 2011 12:29:17 -0500

The following suggestions I believe are reasonable for SPF-BIS, 
overall four items:

      1) Dynamic vs Post SMTP SPF processing
      2) Support for SMTP SUBMITTER Extension (RFC 4405)
      3) Support for AUTH-RES (RFC 5965)
      4) Dealing with Transition Points

1) Dynamic vs Post SMTP SPF processing

SPF-BIS should make it very clear the two basic methods that it can be 
implemented:

    - Dynamic or Online SMTP processing,
    - Post Mail Acceptance, session ended mail processing.

The first one is a SMTP level rejection and this is long followed the 
US EPCA requirement for satisfying User Expectation with an immediate 
notification.

The 2nd one provides an 250 acceptance and User Expectation for 
delivery. Per US EPCA, a delay notification is required if delivery 
can not be met.   To get around this,  SPF-BIS, like ADSP, needs clear 
protocol standard semantics that a POST mail acceptance DISCARD is 
acceptable.

SPF-BIF should have two sections that basically talks about:

  1.1) The need to pass the SPF inputs to the PAYLOAD meta information
       so that a post smtp SPF process can take place.  This not a 
standard
       format nor do I think it should be, but it needs to be pointed 
out to
       implementators what they need to pass.

  1.2) Clear Technical Allowance for DISCARDING of mail for SPF HARD FAIL
       results, no bounce required.   This is not related to a report
       channel if that is desired.

2) Support for SMTP SUBMITTER Extension (RFC 4405)

SPF-BIS should include a section on the optional SUBMITTER support and 
describe how it is used by receivers and also what is required of them 
to make any forwarding of MAIL FROM persistent with any SUBMITTER keyword.

For POST SMTP SPF processing, the question I have is how is SUBMITTER 
passed to the payload or if its necessary since the POST SMTP SPF 
processor would be able to do SENDER-ID logic with the available 
payload.  This is probably a generic question regarding adding the 
Return-Path per SMTP receiver requirement.  Does that include any 
keywords passed in in MAIL FROM?

3) Support for AUTH-RES (RFC 5965)

I think it is reasonable from an engineering standpoint to offer 
support for AUTH-RES that SPF implementators can use either in place 
of Received-SPF or both.

The main reason is that today, SPF is not the only game in town. DKIM 
is also part of the SMTP receiver mail processing.  I don't think we 
have reached a point where we are beginning to couple multiple results 
for a final results, but when we do get to that point, it will be an 
easier design for algorithms based on looking at all the result 
entries in AUTH-RES.

4) Dealing with Transition Points

It has been long understood since day one that the basic problem with 
SPF was how the LMAP domain::ip association is no longer valid after 
the first hop (transition points) or relays.

Its the reason why SENDER-ID existed,  the reason also DKIM first 
existed and was considered as a SPF replacement as a possible IP path 
independent solution.

I think SPF-BIS should have a clear section that talks about this and 
want are current possible solutions to the problem.  The section 
should also focus on what policies are used and how a particular 
policy can have an affect on transition points.

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