Re: [apps-discuss] Authentication-Results

Alessandro Vesely <vesely@tana.it> Sat, 23 March 2013 18:56 UTC

Return-Path: <vesely@tana.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B18921F87AF for <apps-discuss@ietfa.amsl.com>; Sat, 23 Mar 2013 11:56:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.419
X-Spam-Level:
X-Spam-Status: No, score=-4.419 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2b22qakgmapY for <apps-discuss@ietfa.amsl.com>; Sat, 23 Mar 2013 11:56:30 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2E04921F8BDD for <apps-discuss@ietf.org>; Sat, 23 Mar 2013 11:56:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1364064989; bh=AdgJuxqKj+cAtzUE7F8JGQz3o1nX3V1J4nWIo9vXXdA=; l=1670; h=Date:From:To:References:In-Reply-To; b=te8OXxY/WJtuD9XVgdJajT/HzZlqzV+ij2/doqoVF385021RNiJwc/lZBw5vYkIUO tBy4537hSnxz+ngx4RFBTVYZ+VrYlRNyALIxzwm0Q9zsTATkAwUaP9tUTbbhHPMwzw 8O2oDftbpmoBgxS9rSIYOj35B6uuCgHZBc4nWv0o=
Received: from [10.57.167.222] (93-32-180-247.ip34.fastwebnet.it [93.32.180.247]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Sat, 23 Mar 2013 19:56:29 +0100 id 00000000005DC039.00000000514DFADD.00000145
Message-ID: <514DFADD.1010906@tana.it>
Date: Sat, 23 Mar 2013 19:56:29 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <CAL0qLwZbH4HnR8fHEmtLOtE9OFPAfhnN8Oqu6Hmqqed2OMjHJw@mail.gmail.com>
In-Reply-To: <CAL0qLwZbH4HnR8fHEmtLOtE9OFPAfhnN8Oqu6Hmqqed2OMjHJw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Authentication-Results
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Mar 2013 18:56:31 -0000

 On Fri 22/Mar/2013 17:48:01 +0100 Murray S. Kucherawy wrote:
> 
> A Proposed Standard "bis" effort always benefits from describing extant
> implementations.  I know about the ones I've written, and about some
> very public uses of it (Gmail, Yahoo, for example).  If there's anyone
> in this audience that knows of others, I'd love to hear about it.

The following, copied from the source of your message, is added by
recent prereleases of Courier-MTA (the server itself, not my filter):

Authentication-Results: wmail.tana.it;
    dnswl=pass dns.zone=list.dnswl.org
    policy.ip=127.0.9.1
    policy.txt="ietf.org http://dnswl.org/s?s=1703"

It uses an extended method --I'd wait for your bis to change the
registry rules to expert review.

One further difference is that, rather than deleting existing A-R
fields, that MTA renames them.  The rationale is as follows:  Courier
does not implement DKIM natively; that is, the agent that renames
existing fields cannot relay on that authentication method in order to
establish whether a field is trusted.  OTOH, a DKIM verifier working
downstream can easily "unrename" a field, at least temporarily, so as to
avoid breaking signatures if the field is signed.

The spec (Sections 1.6 and 5) uses the term "remove".  I'm not clear if
that necessarily means to irrecoverably destroy the data.  IMHO, the
spec is more flexible in the opposite case.  For a related theme, see
https://sites.google.com/site/oauthgoog/mlistsdkim
(X-Original-Authentication-Results).

Finally, there are a couple of requests to use A-R in SpamAssassin, but
it is uncertain that they will be fulfilled before 5451bis is released.