Subject: [dmarc-ietf] draft-crocker-dmarc-author-00

From: Dave Crocker <[email-masked]>
Date: Sun, 12 Jul 2020 20:10:51 -0700

FYI,

I've just submitted an initial draft to define an RFC5322.Author field:

      https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 13 Jul 2020 18:29:45 +0200

>       https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/

Dave,
since you also posted a second draft, I'd strike considerations about the 
Sender: from this one.  In particular, the 4th paragraph of the Introduction, 
"Because the current [...]", is distracting and unhelpful.

I'd explicitly mention DMARC, rather than use circumlocutions mentioning 
generic email protections which use the From: field.

Another use case of Author: is to indicate multiple authors.  Like From: and 
unlike Sender:, Author: supports a list of mailboxes.  Since, DMARC filters 
don't behave well with multi-address From:, using Author: can be a handy 
alternative for those joint messages.  In fact, the current spec says:

    o  Messages bearing a single RFC5322.From field containing multiple
       addresses (and, thus, multiple domain names to be evaluated) are
       typically rejected because the sorts of mail normally protected by
       DMARC do not use this format;

I submitted ticket 74[*] to address the latter point, which is inconsistent as 
either all or none of the mail belonging to a given domain is subject to DMARC 
filtering.  There is no way to define which sorts of mail is "normally 
protected".  The quoted rule deviously restricts the format of From:.

I'd support making that a WG I-D.  IMHO, it could be standard track and modify 
RFC 5322 if accepted.

Best
Ale
-- 

[*] https://trac.ietf.org/trac/dmarc/ticket/74

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Jul 2020 10:27:34 -0700

On 7/13/2020 9:29 AM, Alessandro Vesely wrote:
> since you also posted a second draft, I'd strike considerations about 
> the Sender: from this one.  In particular, the 4th paragraph of the 
> Introduction, "Because the current [...]", is distracting and unhelpful.

Unfortunately, misunderstanding of the relevant human factors is often 
introduced in discussions in this realm.  People are remarkably 
resistant to the behavioral facts on his, so, unfortunately, it needs 
repeating.

> I'd explicitly mention DMARC, rather than use circumlocutions 
> mentioning generic email protections which use the From: field.

I've learned to write specification for the long-term, notably trying to 
avoid ephemeral references that won't apply years later.  The proposal 
here stands on its own.  Motivated by DMARC issues, but I'd argue not 
dependent on it.

> Another use case of Author: is to indicate multiple authors. 

That's supported by the draft spec, since it copied From: syntax.

> I'd support making that a WG I-D. 

Thanks.

> IMHO, it could be standard track and modify RFC 5322 if accepted.

The mail header is extensible.  Addition of header fields does not 
require modifying the base specification.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 13 Jul 2020 20:29:53 +0200

On 13/07/2020 19:27, Dave Crocker wrote:
> introduced in discussions in this realm.  People are remarkably resistant to 
> the behavioral facts on his, so, unfortunately, it needs repeating.

It'd be enough to say Sender: is syntactically and semantically different.

>> I'd support making that a WG I-D. 

Thank you.

> The mail header is extensible.  Addition of header fields does not require 
> modifying the base specification.

Restricting From: to be single-address, or at least having all domain parts 
aligned to one another does require an updates= tag.  Of course, ticket 74 has 
to be addressed in dmarc-bis too, or one of its parts, since Alexey said we are 
likely to split up the current document into multiple drafts.  If the Author: 
I-D is going to be one of those parts, it's be convenient to recap usage of 
Originator Fields in the DMARC era in a single, short document.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Jul 2020 11:35:09 -0700

On 7/13/2020 11:29 AM, Alessandro Vesely wrote:
> Restricting From: to be single-address, or at least having all domain 
> parts aligned to one another does require an updates= tag.

ahh.  hadn't seen that was your point.  well, whenever there is an 
effort to do substantial revisions to mail format, this might be worth 
considering.

d/

---

From: Joseph Brennan <[email-masked]>
Date: Mon, 13 Jul 2020 15:08:00 -0400

We already have a field for author, called From. Why add another one?

"The only required header fields are the origination date field and
the originator address field(s)." By this, RFC 5322 refers to the From
field. I think client software developers would be inclined to ignore
creating the Author field, or else to create it and populate it with
the same value as the From field. Mailing list software might want to
create Author and copy the value of From into it, and then insert the
list address into the From, but then, they run into "In all cases, the
"From:" field SHOULD NOT contain any mailbox that does not belong to
the author(s) of the message." No better than where we are now, is it?

-- 
Joseph Brennan
Lead, Email and Systems Applications

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Jul 2020 17:23:33 -0700

> We already have a field for author, called From. Why add another one?

1. Note that the From: field typically serves two different semantic 
roles, author and 'handling agent' (ie, Sender:)

2. Pars 3 &6 of the Introduction lay the foundation for needing a new 
and separate header field.

Simple summary:

      These days, the original From: field is tending to get corrupted 
and we need some place to put author information that won't be.

d/

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Jul 2020 08:43:38 -0400

> and we need some place to put author information that won't be.

Then imo, it must be an immutable header object and a requirement to 
be hash bound.  This changes DKIM-BASE and the DKIM Policy protocol. 
Lacking this requirement, leaves open a variety of loop-holes.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Jul 2020 09:48:04 -0400

> I'd support making that a WG I-D.

I am having trouble with it, so ~1

> IMHO, it could be standard track and modify RFC 5322 if accepted.

It will modify all specs related to DKIM where there is an Author 
(5322.From) design requirement.

I don't see how a new "5322.Author" header changes anything especially 
if NOT defined with the following characteristics:

- MUST NOT be modified
- MUST be hash to signature.

Dave, indicated it is expected to be hashed bound to the signature. 
That makes a SHOULD but not a MUST.

I don't see how we can trust a DKIM-signature that has no immutable 
identity requirement to it.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Jul 2020 08:33:56 -0700

> (5322.From) design requirement.

It does not need to affect DKIM at all.

d/