[ietf-dkim] Authentication-Results

Colleagues, (with apologies for the cross-posting if you get more than one copy of this) As you may have seen already, I'm working on a revision to RFC5451. A Proposed Standard "bis" effort always benefits from describing extant implementations. I know about the ones I've written, and about som

[ietf-dkim] Authentication-Results: Header

I think DKIM should prepare itself for presenting "structured" result information to MUA and MFA (Mail Filtering Agents) software. I didn't read all the various statements about the Authentication-Results: header, but there wasn't a clear structured layout of how results can be written for MUA/MFA

[ietf-dkim] Authentication-Results discussion

A discussion about Authentication-Results is being held on the [EMAIL PROTECTED] list. The archives are at . Tony Hansen [EMAIL PROTECTED] ___ NOTE WELL: This list operates according to htt

[ietf-dkim] Authentication-Results: discussion

I took as an action item in Prague to remind this list where the discussion about the Authentication-Results: header is going on. This is me, self-censuring for not doing so sooner. Dave Crocker has donated a list which you can subscribe to and browse archives at: http://mipassoc.or

[ietf-dkim] Authentication-Results: changes

--- Begin Message --- On Monday in the APPAREA meeting, I mentioned some upcoming work regarding the Authentication-Results: header field. I've split the two changes I'm seeking to make into separate drafts because one is fairly trivial and only requires an IANA registration action to complete

Re: [ietf-dkim] Authentication-Results

Our "extant" product supports AUTH-RES for DKIM and ADSP. Without a thorough review again and confirmation, I feel, unfortunately, probably not 100% according your specification. At the time it was implemented, over a few years ago, I had found it inadequate to cover all bases. I do recall it

Re: [ietf-dkim] Authentication-Results: Header

On August 17, 2005 at 00:25, "Hector Santos" wrote: > Based on what I see in one of Michael Thomas's signed DKIM messages, it > looks like the fields are: > > Authentication-Results: signer domain; > header.from=address; > ` dkim=PASS|FAIL

Re: [ietf-dkim] Authentication-Results: Header

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We need something like a Authentication-Results: header. However, there have been complaints about draft-kucherawy-sender-auth-header-02.txt needing lots of work. Once we get past the threat analysis, we'll have to decide exactly what's going to be in

Re: [ietf-dkim] Authentication-Results: Header

I raised the idea of having status codes so results can be more granular, allowing for better decision making processes downstream. Sounds good. What has not be discussed is what about multiple signatures. Are there multiple result fields? Multiple AR's are not needed to document multiple si

[ietf-dkim] Authentication-Results: header draft

I just sent this off to ietf-822 and MAAWG's "techincal" list. Once more mentioning it here as well. Hoping to hand it off to our IETF AD soon. -- Forwarded message -- Date: Thu, 8 Nov 2007 14:32:30 -0800 (PST) From: Murray S. Kucherawy <[EMAIL PROTECTED]> To: [EMAIL PROTECTED]

[ietf-dkim] Authentication-Results: header users

I'm preparing to start the march of turning draft-kucherawy-sender-auth-header (the Authentication-Results: header definition) into a published RFC. Among other things that they'll be interested in seeing is some representative list of companies that are either adding the header (i.e. MTAs, ve

Re: [ietf-dkim] Authentication-Results: header users

Murray S. Kucherawy wrote: > Has anyone else implemented code that adds it or reads it, > or both, whom I could cite in my note to the IESG that this > spec is in use today? Gmail adds it, I cannot say what piece of software, example: Received: from bs.[...] (ns.[...] [...]) by mx.google

Re: [ietf-dkim] Authentication-Results Header Field Appeal

Greetings. This note offers comments on the appeal, draft-otis-auth-header-appeal-00, which has been lodged against standardization of draft-kucherawy-sender-auth-header-20. This appeal lacks merit on basic points. As a technical criticism, the appeal is confused and lacks substance. The conc