Subject: [apps-discuss] Authentication-Results

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 22 Mar 2013 09:48:01 -0700

<participant>

Colleagues,

As you've seen already, I'm working on a revision to RFC5451.  Thanks to
Alessandro Vesely and Dave Cridland for their reviews and comments; I'll
have a revision out shortly that addresses these.

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.

Finally, are there any objections to processing this through APPSAWG?  I
can't shepherd it as I'm editing, so either Salvatore will, or we'll find a
volunteer to do so.

Thanks,
-MSK

</participant>

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 23 Mar 2013 19:56:29 +0100

On Fri 22/Mar/2013 17:48:01 +0100 Murray S. Kucherawy wrote:
> 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.