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

From: Seth Blank <[email-masked]>
Date: Wed, 24 May 2017 11:29:15 -0700

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 there are 0 or 1
Authentication-Result headers from the current ADMD.

Per spec it is ambiguous how to construct the AAR when there are multiple
AR headers.

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 passed to openarc. It
looks like seeing multiple AR headers is going to be a common occurrence
for ARC implementations to handle.

When there are multiple headers, the current openarc implementation just
uses the first AR header it sees and ignores the rest. Dkimpy leaves it to
the user to pass in the appropriate AR header as a parameter.

If the goal of the AAR is to provide a copy of ADMD authentication results
so that the originating dmarc disposition of a message can be determined
and trace information can be provided to the final receiver, then it seems
like:
1) there needs to be a discussion on how to handle multiple AR headers
2) this guidance is needed in spec

Is this a problem the group thinks needs discussion?

-- 

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols
[email-masked]
+1-415-894-2724 <415-894-2724>

---

From: "John Levine" <[email-masked]>
Date: 24 May 2017 19:26:17 -0000

>for ARC implementations to handle.

When I take a look, I only see one, from ietfa.amsl.com.  If I were
having the list mailed to me, I'd expect to see two, that one plus the
one my system adds.  It is rather peculiar to have multiple headers
with the same service identifier, since section 5 of RFC 7601 says
that you normally delete exsting A-R headers with the same
authserv-id before you add a new one.

On my system, the SMTP daemon calls the spf2, opendkim, and opendmarc
libraries, and then puts all the results in a single A-R header.  For
example, when I look at mail from a list I forward to a gmail account,
I see one A-R header from mx.google.com, one from my system, and maybe
one from the original system.  I think that's more typical.

>Is this a problem the group thinks needs discussion?

Only if there are a lot of MTAs that don't report their results in one
header.

R's,
John

---

From: Brandon Long <[email-masked]>
Date: Wed, 24 May 2017 16:10:19 -0700

> authserv-id before you add a new one.

Section 1.6 specifies that you would delete them on entrance to the ADMD,
and 2.1 seems to specify that multiple are allowed, and example B.4 shows
an example where multiple are used.

> Only if there are a lot of MTAs that don't report their results in one

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

Brandon

---

From: Seth Blank <[email-masked]>
Date: Wed, 24 May 2017 16:34:04 -0700

> be specified.  Being sure the spec specifies that only one is allowed,

Yes, the open* libs create multiple AR headers, there are even various open
source tools (like https://github.com/RunasSudo/combineAR) to combine them.

While addressing multiple AR handling in openarc (which was immediately
necessary when running it alongside opendkim and opendmarc), how to do so
was not explicit in the spec, hence the question.

Agreed that we're only talking about a single AAR per hop. Also agreed the
solution appears as straightforward as just combining all AR results from
your ADMD into a single one and then turning that into the AAR. But I'm
uncertain if that's the method the group thinks is appropriate and if
there's been any earlier conversation around this.

Regardless, there are already implementations that do this in different
ways, so I'd argue clarity in the spec is a good thing. Especially since
just grabbing an existing AR header might prove lossy in a way that makes
original message disposition impossible to determine for a final receiver.

If we're in agreement, I would suggest adding the following sentence to the
first paragraph of https://tools.ietf.org/html/dr
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."

I think between that and the third paragraph of the section, the above
"obvious" solution becomes the only possible solution allowed per spec.

Thoughts?

-- 

Bringing Trust to Email

---

From: "John R Levine" <[email-masked]>
Date: 24 May 2017 19:42:16 -0400

> ADMD, regardless of how many Authentication-Results headers are on the

Seems reasonable, give or take a word or two to make it clear we're just 
talking about the ones for the current hop.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Brandon Long <[email-masked]>
Date: Wed, 24 May 2017 17:06:52 -0700

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

We can make that fact explicit here as well, though.

Brandon

---

From: "John R Levine" <[email-masked]>
Date: 24 May 2017 20:27:09 -0400

> previously existing ones prior to adding any new ones per the authres rfc.

I meant not to use a-r with different admds.  Should be obvious, but you 
never know.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 May 2017 17:34:38 -0700

> I meant not to use a-r with different admds.  Should be obvious, but you 

I'd expect a spec to declare that there must be only one A-R header 
field, and that it is applied within the current, integrated mail 
processing environment.  (I'd say within the current ADMD, but I think 
there are valid scenarios where that characterization doesn't quite fit, 
although the language can probably be contorted to make that 
more-limited language sufficient.)

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

Really.  The goal here needs to be to make this a simple as possible. 
It's the only way to get large scale support that interoperates well.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John R Levine" <[email-masked]>
Date: 24 May 2017 21:37:58 -0400

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 

There's two things going on here.  One is the A-R headers added as an 
incoming message is recieved, the other is the ARC-Authentication-Results 
added by ARC.  Personally, I agree with you that there's no reason to 
allow duplicates of either (it took me about a day to write the mailfront 
plugin that checks SPF, DKIM, and DMARC and adds one A-R header, and I'm 
not that good a programmer), but the horse seems to have left the barn for 
A-R and a lot of sloppy code adds multiple headers for the same message 
hop.

On the other hand ARC-Authentication-Results is new, and we can certainly 
say there's only one of those.

> Really.  The goal here needs to be to make this a simple as possible. It's 
> the only way to get large scale support that interoperates well.

Agreed.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 28 May 2017 03:28:40 +0000

On May 24, 2017 8:34:38 PM EDT, Dave Crocker <[email-masked]> wrote:
>>> previously existing ones prior to adding any new ones per the
>authres 
>>> rfc.
>> 

Nothing other than potentially ARC requires multiple AR header fields for different authentication types to be combined.  These different verification operations (e.g. SPF, DKIM, and DMARC) are generally performed be different processes that add their own AR field.

Requiring a single AR field will not make the system any less complicated, it only changes where you put the complexity.

It probably makes sense to stick the sender with the complexity of dealing with multiple AR fields and combining then, but let's not pretend there's an overall simplification here.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 28 May 2017 15:27:35 +0000

In article <[email-masked]>,
>Nothing other than potentially ARC requires multiple AR header fields for different authentication types to be combined.  These different
>verification operations (e.g. SPF, DKIM, and DMARC) are generally performed be different processes that add their own AR field.

Since DMARC needs the results of SPF and DKIM, how does that work?
Does DMARC look at the A-R that the other two created or is there a
side channel?  It occurs to me that a DMARC process has everything
needed to make a header that combines all three.

>It probably makes sense to stick the sender with the complexity of dealing with multiple AR fields and combining then, but let's not pretend there's an overall simplification here.

In ARC, definitely.  My setup already does a combined header, since I
wrote one plugin that calls all three libraries.  On my setup
(mailfront) it was a lot easier than doing it separately.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 28 May 2017 15:53:57 +0000

On May 28, 2017 11:27:35 AM EDT, John Levine <[email-masked]> wrote:
>>Nothing other than potentially ARC requires multiple AR header fields
>for different authentication types to be combined.  These different
>>verification operations (e.g. SPF, DKIM, and DMARC) are generally
>performed be different processes that add their own AR field.
>
snip

At least for OpenDMARC, if it's not doing it's own SPF check (which seems odd to me because it's done after DATA, but it works), it will look at multiple AR fields for both SPF and DKIM results.  

Scott K

---

From: Seth Blank <[email-masked]>
Date: Tue, 30 May 2017 10:21:14 -0700

On Tue, May 30, 2017 at 9:39 AM, Scott Kitterman <[email-masked]>
wrote:
> On Tuesday, May 30, 2017 09:34:49 AM Seth Blank wrote:
> > Resolved items:
> > - Handling of multiple incoming AR headers (resolved, but language not
yet
> > in spec)
>
> If this is resolved in favor of not handling multiple AR header fields
(which
> IIRC is the plan), then something needs to specify the combination is
> required.  I think that something needs to be a DMARC document, not ARC,
> because this is a requirement that's being imposed on all DMARC AR header
> field providers regardless of if they care about or participate
explicitly in
> DMARC.

I believe the consensus in this thread was about adding the following
sentence to the first paragraph of https://tools.ietf.org/html/draft-ietf-
dmarc-arc-protocol-03#section-5.1.3 , with added clarification that we're
only talking about the current AAR[n]:

I don't think this needs a separate document, as I think it is very ARC
specific because it's only about construction of the AAR header and making
sure the proper information gets into it (since multiple AR headers are a
reality in the wild, we just need a sentence on how to deal with them).

Or am I totally misunderstanding your point?

Seth

On Sun, May 28, 2017 at 8:53 AM, Scott Kitterman <[email-masked]>
wrote:

> At least for OpenDMARC, if it's not doing it's own SPF check (which seems
> odd to me because it's done after DATA, but it works), it will look at
> multiple AR fields for both SPF and DKIM results.
>
> Scott K
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

-- 

Bringing Trust to Email

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 30 May 2017 13:33:26 -0400

On Tuesday, May 30, 2017 10:21:14 AM Seth Blank wrote:
> > > yet in spec)
> > explicitly in DMARC.
> sentence to the first paragraph of https://tools.ietf.org/html/draft-ietf-> dmarc-arc-protocol-03#section-5.1.3 , with added clarification that we're

It at least, probably more likely, I'm misunderstanding.

At some point in the process, an AAR and ARC signature get created. Later, 
someone else has to validate them.

My point was that when you are on the signing end of this, you have to grovel 
through all the relevant AR header fields since there's nothing telling 
another doing new authentication the should combine them into the same field.  
Seeing sequence of AR fields for SPF, DKIM, and DMARC is quite normal.

I thought that what was being said was that the AAR contstruction process 
could assume a single AR field and that's not correct.  Now that I see it 
explained again, I see I was thinking one step too far back in the process.

So, I think it was my misunderstanding, although if you're doing to use the 
results of the AAR in the verification process and assume it's all in a single 
AAR header field, then I think that should be a MUST, not a SHOULD.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 May 2017 16:01:25 -0700

> AAR header field, then I think that should be a MUST, not a SHOULD.

I'm leaning toward MUST using Seth's language.  It seems to me SHOULD
leaves an interoperability hole, plus you'd have to come up with some
sityations where not doing so makes sense that are stronger than "I didn't
want to."

-MSK