Subject: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-sender-01.txt

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Jul 2020 05:16:58 -0700

-------- Forwarded Message --------
Subject: New Version Notification for draft-crocker-dmarc-sender-01.txt
Date: Mon, 27 Jul 2020 05:16:07 -0700
From: [email-masked]
To: Dave Crocker <[email-masked]>

A new version of I-D, draft-crocker-dmarc-sender-01.txt
has been successfully submitted by Dave Crocker and posted to the
IETF repository.

Name:		draft-crocker-dmarc-sender
Revision:	01
Title:		DMARC Use of the RFC5322.Sender Header Field
Document date:	2020-07-27
Group:		Individual Submission
Pages:		8
URL: 
https://www.ietf.org/internet-drafts/draft-crocker-dmarc-sender-01.txt
Status:         https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/
Htmlized:       https://tools.ietf.org/html/draft-crocker-dmarc-sender-01
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-crocker-dmarc-sender
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-crocker-dmarc-sender-01

Abstract:
    Internet mail defines the RFC5322.From field to indicate the author
    of the message's content and the RFC5322.Sender field to indicate who
    initially handled the message.  The RFC5322.Sender field is optional,
    if it has the same information as the RFC5322.From field.  That is,
    when the RFC5322.Sender field is absent, the RFC5322.From field has
    conflated semantics, with both a handling identifier and a content
    creator identifier.  This was not a problem, until development of
    stringent protections on use of the RFC5322.From field.  It has
    prompted Mediators, such as mailing lists, to modify the RFC5322.From
    field, to circumvent mail rejection caused by those protections.

    This affects end-to-end behavior of email, between the author and the
    final recipients, because mail from the same author is not treated
    the same, depending on what path it followed.  In effect, the
    RFC5322.From field has become dominated by its role as a handling
    identifier.

    The current specification augments use of the RFC5322.From field, by
    enhancing DMARC to also use the RFC5322.Sender field.  This preserves
    the utility of RFC5322.From field while also preserving the utility
    of DMARC.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 27 Jul 2020 20:14:30 +0200

> To: Dave Crocker <[email-masked]>

In various places, the I-D talks about a /domain owner/, but it is not always 
so clear whose domain owner is meant, in case they differ.

For example, in *Domain Owner Actions*:

    snd:   When present, this tag signals that mail originated by the
       domain owner MAY have a RFC5322.Sender field, as well as a
       RFC5322.From field and that evaluation MAY be based on the domain
       name in the RFC5322.Sender field.

I understand that as a permission that a domain owner grants (to anyone?) to 
resend mail from its domain if it is correctly authenticated.

However, following instructions give the opposite impression.  In *Determine 
Handling Policy*:

        Sender:   Extract the RFC5322.Sender domain from the message.

           Query the DNS for a DMARC policy record.

           Perform remaining, numbered steps, if one is found and it
           contains an "snd" tag.

Let's say I have From: real.bank, and Sender: phisher.example.  The above text 
seems to imply the receiver is looking up _dmarc.phisher.example.  Correct?

Next step 4 apparently entails that aggregate reports are sent to both From: 
and Sender:.  That sounds solid, but not practical.  A MLM needs to apply From: 
rewriting until it sees that all (or most) receivers look for Sender:.  How?

A possible solution in my next message.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Jul 2020 12:02:38 -0700

On 7/27/2020 11:14 AM, Alessandro Vesely wrote:
> In various places, the I-D talks about a /domain owner/, but it is not 
> always so clear whose domain owner is meant, in case they differ.
>

This is a parameter for a record under a domain name.  Is it really not 
clear who is referred to by 'domain owner' here? What other 
interpretation is plausible?

However "originated by" is poor wording and should probably be something 
like "authorized by".

> I understand that as a permission that a domain owner grants (to 
> anyone?) to resend mail from its domain if it is correctly authenticated.
>
> However, following instructions give the opposite impression.  In 
> *Determine Handling Policy*:
>
> Let's say I have From: real.bank, and Sender: phisher.example. The 
> above text seems to imply the receiver is looking up 
> _dmarc.phisher.example.  Correct?

yes.

>
> Next step 4 apparently entails that aggregate reports are sent to both 
> From: and Sender:.  That sounds solid, but not practical.  A MLM needs 
> to apply From: rewriting until it sees that all (or most) receivers 
> look for Sender:.  How?

The reality associated with that 'until' is what motivated moving this 
proposal from using Sender as an /alternative/ to From: to instead being 
/in addition to/.  The heuristic of "until it sees that all (or most) 
receivers look for Sender:" sounds nice, but is entirely indefinite.  
Worse, as you note, the 'how' doesn't have an answer.  So the spec does 
not suggest any meaningful endpoint.

d/

---

From: Joseph Brennan <[email-masked]>
Date: Mon, 27 Jul 2020 16:12:17 -0400

> > _dmarc.phisher.example.  Correct?

Avoiding it by redefining From: to serve the former purpose of Sender: and
creating a new Author: to serve the former purpose of From: seems to me to
start us down a long road of new header fields every couple of years. They
are just names.

Verifying that the message really is from phisher.example is a useful data
point. The receiving system can choose to mark it with a warning like "you
never had mail before from phisher.example".

Consider a DMARC DNS tag for the bank to ask the receiving system to verify
the From, while the end-user system would not use that tag. I think this is
the distinction that should be made, for mailing lists to work but
sensitive data to be more protected than end-user mail.

-- 
Joseph Brennan
Lead, Email and Systems Applications
Columbia University Information Technology

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Jul 2020 10:18:56 +0200

> start us down a long road of new header fields every couple of years. They

In the pre-DMARC era, we've been mainly using just From:.  Sender: is used by 
Outlook to display "on behalf of" catchphrase, presumably in an attempt to 
support the historic Sender-Id protocol.  Otherwise, Sender: never had 
traction.  DMARC did put an extra accent on From:, thereby projecting the 
community into a /new territory/, to use Dave's words.

Introducing Sender: and Author: can allow to tone down DMARC rules.  They were 
designed presuming that only a few domains, where email is not used for 
personal correspondence, would use the protocol.  For example, messages cannot 
have multiple authors, and cannot be forwarded with modifications.  Somewhat 
Procrustean for day to day messaging.

From: rewriting is an obnoxious hack.  Yet it's the only possibility for MLMs, 
currently.  By (re-)introducing those two header fields, we can bevel DMARC 
rules, paying attention not to pervert the overall shape.  Three identifiers 
allow better tuning than just one.  If we do a good job, it won't be necessary 
to redo it every couple of years...

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Tue, 28 Jul 2020 03:35:36 -0700

On 7/27/2020 1:12 PM, Joseph Brennan wrote:
> Avoiding it by redefining From: to serve the former purpose of Sender: 
> and creating a new Author: to serve the former purpose of From: seems 
> to me to start us down a long road of new header fields every couple 
> of years.
Oh?  This is cast essentially as a fear. Your basis for believing this 
is what?

As for the re-defining of From:, the premise of the Author: proposal is 
that DMARC has already effected that change.

> Verifying that the message really is from phisher.example is a useful 
> data point. The receiving system can choose to mark it with a warning 
> like "you never had mail before from phisher.example".

Mark  it how and for what use? How does that deal with the user-level 
problems caused by From:-field rewriting?

> Consider a DMARC DNS tag for the bank to ask the receiving system to 
> verify the From, while the end-user system would not use that tag. I 
> think this is the distinction that should be made, for mailing lists 
> to work but sensitive data to be more protected than end-user mail.

I don't understand what you are suggesting or how it would work usefully.

d/

---

From: "John Levine" <[email-masked]>
Date: 28 Jul 2020 13:41:34 -0400

In article <[email-masked]> you write:
>support the historic Sender-Id protocol. 

Sorry, no. That is completely wrong. The Sender field has been part of
e-mail since RFC 724 in 1977. The now-dead Sender-ID didn't come along
until the 2000s. Outlook's annoying "on behalf of" at least matches the
intention of the Sender field.

This might be a good time to read up on mail history rather than guessing.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 29 Jul 2020 10:45:41 +0200

> intention of the Sender field.

You're right.  Outlook was using "on behalf of" even before Marid.[*]  So 
perhaps Sender-ID derived from that usage, rather than the other way around.

Best
Ale
-- 

[*] https://bugzilla.mozilla.org/show_bug.cgi?id=221054