Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?

On Wed, 24 May 2017, Dave Crocker wrote: Unless there is a very compelling need for multiple A-R header fields -- and I don't think I've seen that asserted -- then the simplest thing is to declare them illegal and any occurrence of them as invalidating the authentication mechanism(s).

Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?

On 5/24/2017 5:27 PM, John R Levine wrote: Seems reasonable, give or take a word or two to make it clear we're just talking about the ones for the current hop. There should only be the ones from the current hop if the admd is stripping previously existing ones prior to adding any new ones per

Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?

Seems reasonable, give or take a word or two to make it clear we're just talking about the ones for the current hop. There should only be the ones from the current hop if the admd is stripping previously existing ones prior to adding any new ones per the authres rfc. I meant not to use a-r

Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?

On Wed, May 24, 2017 at 4:42 PM, John R Levine wrote: > On Wed, 24 May 2017, Seth Blank wrote: > >> aft-ietf-dmarc-arc-protocol-03#section-5.1.3 : >> >> "The AAR should contain all Authentication-Results results from within its >> ADMD, regardless of how many

Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?

On Wed, 24 May 2017, Seth Blank wrote: aft-ietf-dmarc-arc-protocol-03#section-5.1.3 : "The AAR should contain all Authentication-Results results from within its ADMD, regardless of how many Authentication-Results headers are on the message." Seems reasonable, give or take a word or two to

Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?

On Wed, May 24, 2017 at 4:10 PM, Brandon Long wrote: > I think the default using the open* libs is to do so, so probably. OTOH, > how to do so seems fairly obvious, I'm not clear on why doing so needs to > be specified. Being sure the spec specifies that only one is allowed,

Re: [dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?

In article you write: >Looking at random messages on this list, I've seen anywhere from two to >five AR headers per message. Locally, with opendkim and opendmarc running, >there are three locally generated AR headers that get

Re: [dmarc-ietf] signing keys for arc-seal/arc-message-signature

Does the group have any further thoughts here? I'm happy to suggest language for Gene's suggestion if there are no further comments. On Tue, May 9, 2017 at 4:02 PM, Gene Shuman wrote: > I definitely can't imagine any sensible case in which the d= tags should > be different.

[dmarc-ietf] Does the concept of an ARC tempfail make any sense?

I couldn't find prior discussion about this, if I missed it somehow could someone cluestick me? We've been working with Murray on openarc, and there are some chain validation failure modes that closely resemble a dkim tempfail (for instance, DNS unresponsiveness when trying to query for a key).

[dmarc-ietf] Guidance around constructing an AAR when multiple AR headers are present?

Under both the current spec ( https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-5.1.3) and the proposed spec ( http://blackops.org/~msk/draft-kucherawy-dmarc-arc-base.txt section 5.2), an ARC Set [i] can have only a single AAR header. It is clear how to construct an AAR when