Subject: [dmarc-ietf] Section 5.2.1, header.ds considered confusing

From: "John R. Levine" <[email-masked]>
Date: 2 Jan 2018 14:38:28 -0500

I don't see the point of the header.ds field.  We already have header.d, 
so why not just add header.s?

If there are two DKIM validations, the A-R header will look like this, no 
confusion I can see:

Authentication-Results: example.com; ...
   dkim=pass header.d=foo.com header.s=abc; header.b="A9hX4wGQ";
   dkim=none header.d=bar.com header.s=def; header.b="4icXsmdd"; ...

Bonus question: so what would this mean?

Authentication-Results: example.com; ...
   dkim=pass header.d=foo.com header.ds=bar.com,abc; header.b="A9hX4wGQ"; ...

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 2 Jan 2018 20:45:26 +0000

> so why not just add header.s?

Yes, quite so. Please see my note from earlier this morning. header.s is
already defined for 7601, we just need to indicate that it needs to be
added into the A-R and AAR rather than leaving it to chance.

--Kurt

---

From: Seth Blank <[email-masked]>
Date: Tue, 2 Jan 2018 13:44:43 -0800

> added into the A-R and AAR rather than leaving it to chance.

header.s is NOT defined: https://www.iana.org/assignments/email-auth/email-
auth.xhtml

That's why I explicitly mentioned in the earlier thread about IANA
registrations (https://mailarchive.ietf.org/arch/msg/dmarc/72GKJ1mMd6Pc5_
DWYGgnLE-Uzxw) that we'd need to add it after 7602bis.

To John's point, this is why I've been pushing hard for 7601bis, adding
header.s to DKIM is far cleaner than trying to do header.ds in arc
directly. This is why I asked question #2 in this thread:
https://mailarchive.ietf.org/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_pesrd9z0

Seth

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 2 Jan 2018 23:23:12 +0000

On Tue, Jan 2, 2018 at 9:44 PM, Seth Blank <[email-masked]> wrote:

> header.s is NOT defined: https://www.iana.org/
> assignments/email-auth/email-auth.xhtml
>
> registrations (https://mailarchive.ietf.org/arch/msg/dmarc/72GKJ1mMd6Pc5_D
> WYGgnLE-Uzxw) that we'd need to add it after 7601bis.
>

I'm just not getting (from reading the text of 7601 several times today)
how including an extra ptype makes a "normative redefinition" of 7601.
RFC7001 clearly says that additional ptypes are expected over time. If
anything, we're considering a "normative redefinition" of 6008 which talks
about listing info for more than one DKIM header, but I think the term is a
misnomer.

It appears to me that the "7601 replaces all former definitions" work was
just incompletely implemented by IANA. We can certainly patch over those
gaps as we care about the data for ARC within our spec, but it seems like
having an IANA errata for 7601 would be a cleaner and more apropos vehicle.

--Kurt

---

From: "John Levine" <[email-masked]>
Date: 2 Jan 2018 20:03:59 -0500

>header.s is NOT defined: https://www.iana.org/assignments/email-auth/email-

Quite right, need to put it in the IANA considerations of something.

FWIW, I added header.s to my SMTP daemon this afternoon.  It took
about 10 minuutes.  I'm a pretty good programmer, but I'm not *that*
good.

R's,
John