Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-03.txt

[Scott Kitterman <[e-mail]>]

On Monday, May 20, 2013 09:31:45 AM Murray S. Kucherawy wrote:
> On Mon, May 20, 2013 at 9:30 AM, <[e-mail]> wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > 
> >  This draft is a work item of the Applications Area Working Group Working
> > 
> > Group of the IETF.
> > 
> >         Title           : Message Header Field for Indicating Message
> > 
> > Authentication Status
> > 
> >         Author(s)       : Murray S. Kucherawy
> >         Filename        : draft-ietf-appsawg-rfc5451bis-03.txt
> >         Pages           : 42
> >         Date            : 2013-05-20
> 
> This incorporates the last of the WGLC feedback, including reverting the
> ABNF change that introduced a backward compatibility issue.

Thanks.  That does resolve the concern.

It does looke like you, however, added a note about adding the ABNF change you 
just removed on page 41:

 o ABNF: separate the authserv-id from the spec version with a "/"

These two editorial comments against -02 still appear to apply:

Comments:

>    At the time of publication of this document, Author Domain Signing
>    Practices ([ADSP]), SMTP Service Extension for Authentication
>    ([AUTH]), DomainKeys Identified Mail Signatures ([DKIM])>, Sender
>    Policy Framework ([SPF]), and Vouch-By-Reference ([VBR]) are
>    published DNS domain-level email authentication methods in common
>    use.  DomainKeys ([DOMAINKEYS]) and Sender ID ([SENDERID] are also
>    referenced here, though they respectively have "Historic" and
>    "Experimental" status, and are no longer common.

I've also seen iprev in the wild and it's supported by the python authres 
module I helped develop.  We've also implemented DMARC based on the latest 
draft.  Iprev is in 5451, so I think it should be mentioned.

>    Although SPF defined a header field called "Received-SPF" and
>    DomainKeys defined one called "DomainKey-Status" for this purpose,
>    those header fields are specific to the conveyance of their
>    respective results only and thus are insufficient to satisfy the
>    requirements enumerated below.  In addition, many SPF implementations
>    have adopted the header field specified below, and DomainKeys has
>    been obsoleted by DKIM.

I think this overstates things with respect to SPF.  Most implementations have 
not adopted authres and even in the cases where they have, it's an option, not 
the default.

Scott K