Subject: SPFBIS LAST CALL: SenderID Framework (PRA, SUBMITTER)

From: Hector Santos <[email-masked]>
Date: Thu, 22 Aug 2013 10:29:37 -0400

Hi SM,

Besides the SPF type issue, I believe there are still a number of 
integrated protocol issues to address.  How does the following RFCs 
play into SPFBIS output, the SPF type and the overall BIS document? 
Should RFC4408BIS update any of these documents?

[1] RFC4405  SUBMITTER SMTP Service Extension
[2] RFC4406  Sender ID: Authenticating E-Mail
[3] RFC4407  Purported Responsible Address (PRA)

For example:

In RFC 4406 (SenderID), section 3.1 says:

    This section replaces the definition of the version identifier in
    Section 4.5 of [RFC4408] and adds the concept of SPF record scopes.

In section 4.4, item 1:

    1. If any records of type SPF are in the set, then all records of
       type TXT are discarded.

Overall,

1) Do SenderID publishers need to drop the SPF type as well?

2) Do PRA/SUBMITTER compliant receivers need to also drop SPF type 
queries?

3) Do SMTP vendors need to begin dropping SUBMITTER as well?

Procedurally, does SPFBIS need to address or take over these multiple 
protocols integration concerns (including SMTP SUBMITTER receivers) or 
should it just remain silent and allow vendors make a guess at all 
this?  What is the SPF summary in this regard for the application 
integrator?

Should the IETF consider a new SenderID WG to discuss what are the 
repercussions the SPFBIS results have on it?

--
HLS

[1] http://tools.ietf.org/html/rfc4405
[2] http://tools.ietf.org/html/rfc4406
[3] http://tools.ietf.org/html/rfc4407

---

From: S Moonesamy <[email-masked]>
Date: Thu, 22 Aug 2013 08:38:49 -0700

Hi Hector,
>[3] RFC4407  Purported Responsible Address (PRA)

I would say no as the above RFCs are not related to 
draft-ietf-spfbis-4408bis-19.  I'll mention the following text from RFC 6686:

   "The experiments comprising the series of RFCs defining the
    SUBMITTER SMTP extension (RFC4405), the Sender ID mechanism
    (RFC4406), the Purported Responsible Address algorithm (RFC4407),
     and SPF (RFC4408), should be considered concluded.

That is the official position of the IETF.  I can state that the text 
reflects the consensus of the SPFBIS WG as I verified whether there 
was working group agreement before requesting the publication of RFC 
6686.  The following text is from RFC 6686:

   "This document is a product of the Internet Engineering Task Force
    (IETF).  It represents the consensus of the IETF community.  It has
    received public review and has been approved for publication by the
    Internet Engineering Steering Group (IESG)."

 From an IETF perspective that's the answer that will be given.

>2) Do PRA/SUBMITTER compliant receivers need to also drop SPF type queries?
>

Somebody can submit a draft which answers those questions and have it 
discussed in the IETF.  The SPFBIS WG Chairs have mentioned that once 
the work on draft-ietf-spfbis-4408bis is completed the SPFBIS WG will 
be ready to close ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10124.html 
).  I don't think that the SPFBIS WG will take on the draft.  The 
person submitting the draft can contact the Application Area 
Directors to find out where to discuss the draft.

>Procedurally, does SPFBIS need to address or take over these 
>multiple protocols integration concerns (including SMTP SUBMITTER 
>receivers) or should it just remain silent and allow vendors make a 
>guess at all this?  What is the SPF summary in this regard for the 
>application integrator?

Procedurally, the SPFBIS WG does not need to address that (see above 
comments).  SPFBIS will remain silent and allow vendors to make a 
guess.  The SPF summary is that it is out of scope for 
draft-ietf-spfbis-4408bis-19.

>repercussions the SPFBIS results have on it?

The above question is about a SenderID BoF.  I personally do not 
think that there is currently interest in having that BoF (see RFC 5434).

Regards,
S. Moonesamy