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

Scott Kitterman <> Fri, 17 May 2013 22:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68D1F21F9666 for <>; Fri, 17 May 2013 15:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MyKIH6RbedCf for <>; Fri, 17 May 2013 15:22:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 322C321F95E9 for <>; Fri, 17 May 2013 15:22:53 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 1810820E40FE; Fri, 17 May 2013 18:22:52 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=2007-00; t=1368829372; bh=W8qRPJyTlGBczOAr+x8HJPkNljcSh+5ljdzLasrZwfI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=buwzhMjrNCprYlQE33yKrgrwQNe0NXldBFLVKlMHffwKihGQjPquaKwMWwZp8lb9D 7hmTS2RR6y91NrRaPs+DcL3coAgklzJ5trU82lc4xs1TMlQCX9mMmfIQqy5VQA1N+j nicCmxuZ7tpE1l2Hg/qwwRfLdX2FlOIkAMfigFug=
Received: from scott-latitude-e6320.localnet ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id F1C8720E40F6; Fri, 17 May 2013 18:22:51 -0400 (EDT)
From: Scott Kitterman <>
Date: Fri, 17 May 2013 18:22:47 -0400
Message-ID: <1675160.H9MT8MA6B2@scott-latitude-e6320>
User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; )
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-02.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 May 2013 22:22:58 -0000

On Sunday, May 12, 2013 09:53:42 PM 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-02.txt
> 	Pages           : 42
> 	Date            : 2013-05-12


>    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.

In the ABNF:

I believe the change from:

authres-header = "Authentication-Results:" [CFWS] authserv-id
	[ CFWS version ]


authres-header = "Authentication-Results:" [CFWS] authserv-id	
	[ [CFWS] "/" [CFWS] authres-version ]

is an incompatible change and if you really want to make it, you should bump 
the version number.  I checked and with authres, your example is mis-parsed.

	Authentication-Results:; none

In this example, the authserv-id is "", but authres, using the RFC 
5451 ABNF parses this and determines the authserv-id is ""

If you want to make this change, I think it needs to be version 2 because an 
existing version 1 parser can't parse the header field anymore.  Actually, I'm 
not sure that helps since a version 1 parser would fail to determine the 
message version.  I think you need to specif a minimum of one space between 
the authserv-id and the "/" for backward compatibility.

The first two are editorial.  The last one is significant.  It's possible we 
implemented it wrong in authres, but that's how it looks for the moment.  
Let's discuss.

Scott K