Subject: [spfbis] Implementation status of draft-ietf-spfbis-4408bis

From: S Moonesamy <[email-masked]>
Date: Thu, 11 Apr 2013 03:17:47 -0700

Hello,

I would like to have some information about the implementation of 
draft-ietf-spfbis-4408bis [1].  If you have implemented the draft, 
could you please send me the following information:

   (a) Implementation name

   (b) Description of implementation (please include a link to a
       web page if it contains information about the implementation)

   (c) The versions of the draft which were implemented

   (c) The parts of draft-ietf-spfbis-4408bis which were implemented

Regards,
S. Moonesamy

1. http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-14

---

From: Hector Santos <[email-masked]>
Date: Thu, 11 Apr 2013 13:52:48 -0400

Hi, SM as you made aware, I had a heart attack this pass June 2012 and I 
have been on a 1 year sabbatical to regained my health and healthier 
living.   As part of my stress management, I have also minimized my IETF 
participation.

For SPF, I do wish for it to be properly completed some day, but I do 
wish to get all my concerns all out now and not dwell much time with it. 
I won't be getting into debates.  I will use your questionnaire as an 
entry point for my WGLC comments and all I wish to say about SPF, our 
implementation and the concerns with 4408BIS.

See inline comments.

Thanks

>    (a) Implementation name

wcSPF as part wcSAP - Wildcat! Sender Authentication Protocol

>        web page if it contains information about the implementation)

wcSPF is part of a suite of testing tools lump together under WCSAP. For 
a technical interest, the default order of where SPF calls in the 
testing is:

     SAPFLT - Rules written by the sysop.

     SAPRBL - DNS RBL sites, default is spamcop

     SAPSPF - SPF check, rejects (550) on a -ALL failed policies

     SAPCBV - Call-Back Verifier (CBV), based on a SMTP
              Return path MUST be VALID design premise.

http://www.winserver.com/public/Security
http://www.winserver.com/public/aup/topic-wcsap.htm#SAPSPF
(not all newer options are show here, thanks for the reminder, jotted down).

A wcSAP  testing Site was implemented since 2003:

http://www.winserver.com/public/wcsap.wcx

Ten years of SPF-based reject statistics has been collected daily:

http://www.winserver.com/public/antispam

For comparison, I would like to know of any other implementation with 
the steady accumulated data over MARID 2003.   Statistics for SMTP 
rejections show the growth over the years of hard fail SPF policies from 
negligible 0.00% in 2003 to as high as 20% today 2013!

Default installation for all customers enabled wcSPF and honors a SMTP 
reject policy for SPF hard fails domain policies.  Deployments CAN NOT 
currently change the reject but they can change/set the SMTP reply code.

>    (c) The parts of draft-ietf-spfbis-4408bis which were implemented

SPF was implemented circa 2003 starting with the MARID era SPF draft 
specifications and later the full RFC 4408 when completed but not much 
was changed other than setting recursion limits (total count limit).

This was needed because there were clear immediate support issues due to 
reaching software stack limitations with a very few amount of SPF 
policies. But catches of errors and using 45x (using "fail-safe" 
approaches early on during the exploration) caused redundant sender 
retries.  I believe it was finally updated and set to a permerror and a 
55x to at least stop the redundant retries.

There is only one thing about this 4408bis draft that encouraged me to 
explore and it is source of major engineering dilemma I have with this 
SPF BIS effort.  That is adding the option to FAIL-ACCEPT a transaction 
as opposed to what is currently implemented - FAIL-REJECT. I strongly 
believed a FAIL-REJECT was the intent and only intent for a SPF hard 
failure. What a receiver actually does, well that depends on the 
implementation and also the administrator. Sure, it can do what it 
wants, but in my strong opinion  the protocol intent was for rejection.

I am concern that this 4408BIS doc will lower the high 20% rejection we 
are realizing over the past 10 years or at least keep it at this level 
assuming that this document will not encourage SPF -ALL domains to relax 
to a SOFTFAIL (~ALL) which in my opinion is a wasteful policy which 
causes more wasted DNS traffic unless it is coupled with something else. 
  What is that "Something Else?"  Its not common, I would suggest.

Why would domains change it?  Well, it would be, IMV, due to better 
support AUTH-RES because I would suggest most (by packages, not by 
volume) are using Received-SPF headers and nothing (N/A) for FAIL-REJECT 
approaches.  That is what I wanted to do.  We added AUTH-REF for DKIM 
and ADSP so why not for SPF as well.  It make sense.

Unfortunately, we will need to drastically change our backend in order 
to secure (by separation) a FAIL-ACCEPT transaction.  The document did 
address/touch based with this security issue, but not enough emphasis on 
the separation part. I believe it would be part of the SPF Protocol for 
a FAIL-ACCEPT design option.  It is important for others to be aware of 
this who fall in the same current design predicament (they always 
rejected the -ALL).  We can't use say that based on PARETO, most SPF 
implementers already do a FAIL-ACCEPT, but what I haven't heard that 
they ALL also separate the mail.  It must be done others for a POP3 pick 
up, you would be passsing the failed message to the end-user and unless 
he has a super smart MUA offline reader that is not only SPF ready, but 
also "Received-SPF: fail"  and/or "Auth-Res; spf=Fail" ready as well.

Nonetheless, this issue regarding FAIL-ACCEPT plus a few others I have 
outlined here are the basic issues I have with this BIS:

1) SPF "payoff" value will be lower, less need to use it. Too much DNS 
overhead will be realized.

2) Higher Development cost in adding a FAIL-ACCEPT PLUS A MAIL 
SEPARATION design I feel is required to support this FAIL-ACCEPT logic.

3) AUTH-RES is incomplete.  I don't think we should need to kludge the 
reporting using comments parts of this particular trace line.

4) Lack of SUBMITTER support.  The Check-Function is too limited. 
Doesn't match reality or at a minimum, fails to acknowledge it and how 
it COULD BE implemented and used.

5) Minor:  I do think the BIS is very verbose.

  I don't need to support this for the two extra new (more emphasis) 
things about this BIS (FAIL-ACCEPT, AUTH-RES). I am not sure yet if I 
should endorse, encourage, recognize it for usage. Not if its going to 
alter how domains set their policies. Worst case is domains who 
currently follow -ALL and they relax it to ~ALL because of 4408BIS, not 
because they have to for technical reasons. Perhaps they because that 
MOST systems already have some other exploration thing related to DMARC 
or some other MFA (Mail Filtering Agent) thing going on.    If they did, 
we are not currently ready to support that, DMARC or anything else.  In 
that way, its more of a possible concern in seeing a lower payoff until 
we do a FAIL-ACCEPT-SEPARATION SPF design.

--
Hector Santos, CTO/CEO
Santronics Software, Inc.

---

From: Hector Santos <[email-masked]>
Date: Thu, 11 Apr 2013 14:13:00 -0400

I forgot to outline this additional concern:

6) SPF records with PTR

As described in our documentation section titled

    SPF Records for Wildcat! Sysops

We encourage the usage the PTR for simplicity and generality. Less DNS 
management requirement, means less support cost for our customers and us 
as well.   4408BIS will cause this to change.

Questions will be for us: Do we want to change our recommendations? Is 
there a harm by not following it? There was a higher harm in the past, 
but believe it is lesser today. Do we need to do this?

On 4/11/2013 1:52 PM, Hector Santos wrote:
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
>
>

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 11 Apr 2013 16:33:32 -0400

> 1. http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-14

Here's a list of known SPF implementations, mostly based on RFC 4408:

http://www.openspf.org/Implementations

Given the minimal changes in functional requirements in 4408bis, I think they 
should still count in the mix some how.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Thu, 11 Apr 2013 16:50:11 -0400

I believe it would be very productive for most people who are just 
scanning/perusing this stuff if you can summarize what are the key 
considerations and changes per software change needs, if any.

- New Fail Accept Considerations
- No more Type 99 considerations
- Recommendation to not publish PTR directives in policies.
- New consideration for AUTH-RES to use with and/or replace Received-SPF
    - Not 100% direct replacement

What else?

In other words, are there any surprises?  is it PnP (Plug and Play) 
ready?  Do people need to change software? Change setups? in order to 
declare they are (still) "compatible" with 4408BIS?  What happens if no 
one supports 4408BIS? If there any harm if no one follows it, like 
doesn't change PTR to direct IPx directives?

--
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Apr 2013 16:41:20 -0700

> - New Fail Accept Considerations

None; we always put the action-on-fail in the hands of the user, and
defaulted it to add an A-R header field and pass the message.

> - No more Type 99 considerations

None; we never queried type 99.

> - Recommendation to not publish PTR directives in policies.

None; 4408bis didn't remove support for PTR, only discouraged it.  I
wouldn't change anything here.

>    - Not 100% direct replacement

None; we never implemented Received-SPF.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Thu, 11 Apr 2013 23:22:32 -0700

Hi Hector,
At 10:52 11-04-2013, Hector Santos wrote:
>Hi, SM as you made aware, I had a heart attack this pass June 2012 
>and I have been on a 1 year sabbatical to regained my health and 
>healthier living.   As part of my stress management, I have also 
>minimized my IETF participation.

I hope that you are getting better.

>For SPF, I do wish for it to be properly completed some day, but I 
>do wish to get all my concerns all out now and not dwell much time 
>with it. I won't be getting into debates.  I will use your 
>questionnaire as an entry point for my WGLC comments and all I wish 
>to say about SPF, our implementation and the concerns with 4408BIS.

I'll comment as document shepherd for  draft-ietf-spfbis-4408bis.  If 
there are any concerns that you consider as not addressed after the 
end of the WGLC please send me an message about them.  I will include 
them in my write-up or bring them to the attention of the Responsible 
Area Director.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Mon, 15 Apr 2013 03:12:36 -0700

>should still count in the mix some how.

I'll try and get more information about the implementation status of 
draft-ietf-spfbis-4408bis by sending this message (Bcc) to the email 
addresses listed on the web page.  Please see the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03347.html for 
more context.  The list of changes to the SPF specification is in 
Appendix J ( http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-14 ).

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Tue, 23 Apr 2013 14:52:52 -0700

Hi Scott,

I did not see any response to the comments posted at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03350.html and 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03351.html 
Could you please review the messages and comment?

Thanks,
S. Moonesamy (as document shepherd)