Subject: [dmarc-ietf] selectors in AAR.

From: Brandon Long <[email-masked]>
Date: Fri, 23 Jun 2017 15:17:44 -0700

On Wed, May 31, 2017 at 10:07 PM, Murray S. Kucherawy <[email-masked]>
wrote:

>
>
> On Thu, May 4, 2017 at 4:19 PM, Peter Goldstein <[email-masked]>
> wrote:
>
>> So as a consumer of these reports I'd definitely like to see a structured
>> value with as much information as possible.
>>
>
[snip]

>
>>    - DKIM Selectors - Unfortunately we probably can't get the DKIM
>>    signature selectors (because they aren't generally recorded in the
>>    Authentication-Results, and so won't be available to downstream hops), but
>>    if we can get them, that would be very helpful.
>>
>>
> They could be added to A-R, in theory, but they're not really
> user-consumable which is why they were originally omitted.
>

Thinking some more on this while thinking about the format of the DMARC
report, I think we should consider it.

The AuthRes header was meant to help pass information to the end user (or
their mail client) from their own mail system.

The AAR header is meant to pass information from each hop to all of the
following hops, and meant mostly (at this point) to inform the DMARC
handling of the message.

And part of the point of DMARC is informing admins/domain owners on how
their mail is being evaluated to help them get to stricter levels.

It's pretty obvious that for the domains of larger organizations, one can
end up with many sources of email.  We've taken a pretty strong stance
internally at Google that we don't give out DKIM keys, the mail has to
relay through us to be signed, but given the blank stares we seem to get
from ESPs when we say that, I don't think that's the standard at all.

So, different selectors are a really good indicator, possibly more so than
IPs, of where mail comes from.  But neither IPs nor selectors are included
in the AuthRes or AAR headers.

Now, the selector is still there if the DKIM signature wasn't removed.
Though, it's often removed when messages are deliberately rewritten
(mailing lists), because there still exists receivers which reject mail
based on broken signatures.

IPs are preserved in Received headers, but extracting them and knowing ADMD
boundaries and such becomes kind of complicated, compared to the much
simpler usage of including them as a propspec for SPF.

My point is, AAR is computer consumable authenticated forwarded
information.  This information may not inform the DMARC result directly,
but being able to pass it to the aggregate report seems pretty useful.

Brandon

---

From: Gene Shuman <[email-masked]>
Date: Mon, 26 Jun 2017 14:26:11 -0700

I definitely support this idea, as having the selectors available is
extremely useful to us as part of service authentication.  And putting them
into the AR headers seems to be the appropriate solution.

I guess the next question is how we would actually go about sending this
information.  Something like header.s?

=Gene

On Fri, Jun 23, 2017 at 3:17 PM, Brandon Long <[email-masked]> wrote:

> On Wed, May 31, 2017 at 10:07 PM, Murray S. Kucherawy <[email-masked]
> > wrote:
>
>>
>>
>>> So as a consumer of these reports I'd definitely like to see a
>>> structured value with as much information as possible.
>>>
>>
> [snip]
>
>>
> IPs are preserved in Received headers, but extracting them and knowing
> ADMD boundaries and such becomes kind of complicated, compared to the much
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>