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

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

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

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

Name:		draft-crocker-dmarc-author
Revision:	01
Title:		Author Header Field
Document date:	2020-07-27
Group:		Individual Submission
Pages:		6
URL: 
https://www.ietf.org/internet-drafts/draft-crocker-dmarc-author-01.txt
Status:         https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/
Htmlized:       https://tools.ietf.org/html/draft-crocker-dmarc-author-01
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-crocker-dmarc-author
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-crocker-dmarc-author-01

Abstract:
    Internet mail defines the From: field to indicate the author of the
    message's content and the Sender: field to indicate who initially
    handled the message.  The Sender: field is optional, if it has the
    same information as the From: field.  That is, when the Sender: field
    is absent, the From: field has conflated semantics, as both a
    handling identifier and a content creator identifier.  This was not a
    problem, until development of stringent protections on use of the
    From: field.  It has prompted Mediators, such as mailing lists, to
    modify the 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 From:
    field has become dominated by its role as a handling identifier.  The
    current specification augments the current use of the From: field, by
    specifying the Author: field, which identifies the original author of
    the message and is not subject to modification by Mediators.

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:15:55 +0200

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

The I-D says:

                 Generally, the handling of the Author: header field
    needs to receive scrutiny and care comparable to that given to the
    From: header field.

If receivers lookup the Author: domain too, they can evaluate authentication 
and alignment also with respect to that domain.  The evaluation may take into 
account snd tags, and/or dkim-transforms, or whatever other MLM solution we'll 
invent.  That is to be done in case From: and Sender: domains coincide.  The 
result of evaluating the Author: domain may or may not affect the destiny of 
the message, but it should be part of the aggregate report.  That way, when a 
MLM receives records saying that Author: domains authenticate all right, it can 
stop rewriting From:.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Jul 2020 11:51:54 -0700

On 7/27/2020 11:15 AM, Alessandro Vesely wrote:
> If receivers lookup the Author: domain too, they can evaluate 
> authentication and alignment also with respect to that domain.

Since there is no authentication or alignment associated with the Author 
field, I don't know how they can be evaluated.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Jul 2020 09:26:45 +0200

On Mon 27/Jul/2020 20:51:54 +0200 Dave Crocker wrote:
>> and alignment also with respect to that domain.
> 
> 
> Since there is no authentication or alignment associated with the Author field, 
> I don't know how they can be evaluated.

Receivers can evaluate the Author: domain just like they would do if it were 
the From: domain.  As a new field, Author: doesn't wear a reliable-id trophy, 
hence receivers may refrain to apply policy dispositions.  However, the result 
of the evaluation, conveyed through aggregate report, can tell MLMs if 
rewriting From: was necessary.

That's the only kind of strategy I see for limiting From: rewriting horizon.

Best
Ale
--

---

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

On 7/28/2020 12:26 AM, Alessandro Vesely wrote:
>> Since there is no authentication or alignment associated with the 
>> Author field, I don't know how they can be evaluated.
> 
> 
> Receivers can evaluate the Author: domain just like they would do if it 
> were the From: domain.  

So you want to define DMARC as applying to both the From: field and the 
Author: field?  That will defeat the benefit intended for the Author: field.

>As a new field, Author: doesn't wear a 
> reliable-id trophy, hence receivers may refrain to apply policy 
> dispositions.  However, the result of the evaluation, conveyed through 
> aggregate report, can tell MLMs if rewriting From: was necessary.

How, exactly?

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Jul 2020 13:00:31 +0200

On Tue 28/Jul/2020 12:37:32 +0200 Dave Crocker wrote:
>> the From: domain. 
> So you want to define DMARC as applying to both the From: field and the Author: 
> field?  That will defeat the benefit intended for the Author: field.

Yes.  In case of conflict, evaluation of Author: has to be omitted.  For 
example, Author: fields containing multiple mailboxes are not considered.

(OT-BTW, DMARC spec will have to consider From: fields with multiple mailboxes, 
since they're allowed by RFC 5322.  Should Sender:, in such cases, have a 
domain aligned with one of those?)

>> As a new field, Author: doesn't wear a reliable-id trophy, hence receivers 
>> may refrain to apply policy dispositions.  However, the result of the 
>> evaluation, conveyed through aggregate report, can tell MLMs if rewriting 
>> From: was necessary.
> 
> How, exactly?

Author: and Sender: domains can be included in aggregate reports along with the 
From: one.  The policy_evaluated can also include more items, specifying which 
evaluations pass or fail.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Tue, 28 Jul 2020 04:09:29 -0700

On 7/28/2020 4:00 AM, Alessandro Vesely wrote:
>>> Receivers can evaluate the Author: domain just like they would do if 
>>> it were the From: domain. 
>>
>> So you want to define DMARC as applying to both the From: field and 
>> the Author: field?  That will defeat the benefit intended for the 
>> Author: field.
> 

1. I don't understand the details you have in mind that would make this 
useful.

2. Again, this seems to defeat the purpose of having the Author field.

> (OT-BTW, DMARC spec will have to consider From: fields with multiple 
> mailboxes, since they're allowed by RFC 5322.  Should Sender:, in such 
> cases, have a domain aligned with one of those?)

My understanding is that DMARC does not work for From: fields with 
multiple domain names.  In that regard, that's another change to the 
From: field that DMARC imposes.

>>> As a new field, Author: doesn't wear a reliable-id trophy, hence 
>>> receivers may refrain to apply policy dispositions.  However, the 
>>> result of the evaluation, conveyed through aggregate report, can tell 
>>> MLMs if rewriting From: was necessary.
>>
>> How, exactly?
> 
> 
> Author: and Sender: domains can be included in aggregate reports along 
> with the From: one.  The policy_evaluated can also include more items, 
> specifying which evaluations pass or fail.

It will probably help for you to supply detailed specification of the 
changes to DMARC's reporting, so people can assess its likely costs and 
benefits more concretely.

d/

---

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

On Tue 28/Jul/2020 13:09:29 +0200 Dave Crocker wrote:
> 1. I don't understand the details you have in mind that would make this useful.

It is an optional evaluation.  It's easy to do, if you already verified DKIM 
and SPF.  It is not terribly useful, admittedly, except that having two or 
three "pass" makes for a stronger authentication than just the From:.  The 
chief reason for evaluating it is to give feedback to the MLM.

> 2. Again, this seems to defeat the purpose of having the Author field.

Why?

>> mailboxes, since they're allowed by RFC 5322.  Should Sender:, in such cases, 
>> have a domain aligned with one of those?)
> 
> My understanding is that DMARC does not work for From: fields with multiple 
> domain names.  In that regard, that's another change to the From: field that 
> DMARC imposes.

I don't think such restriction is acceptable for a Standard Track document 
which should be applicable to all mail.  According to RFC 5322, in such cases 
the Sender: shall be used to disambiguate.  Then we need to distinguish between 
two differing semantics for Sender:, mediator or agent.

>> Author: and Sender: domains can be included in aggregate reports along with 
>> the From: one.  The policy_evaluated can also include more items, specifying 
>> which evaluations pass or fail.
> 
> It will probably help for you to supply detailed specification of the changes 
> to DMARC's reporting, so people can assess its likely costs and benefits more 
> concretely.

How about this example:

       <policy_evaluated>
         <from>
           <dkim>pass</dkim>
           <spf>fail</spf>
         </from>
         <author>
           <dkim>fail</dkim>
           <spf>fail</spf>
         </author>
         <sender>
           <dkim>pass</dkim>
           <spf>pass</spf>
         </sender>
         <disposition>none</disposition>
         <reason>
           <type>mailing_list</type>
           <comment>Mailinglist via SPF on ietf.org (IETF mailinglist)</comment>
         </reason>
       </policy_evaluated>

?

AFAICS, an <author><dkim>pass implies one of three reasons:

* MLM added no footer,
* text/plain message signed with l=, or
* DKIM transformation successfully applied.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Tue, 28 Jul 2020 10:08:25 -0700

On 7/28/2020 7:20 AM, Alessandro Vesely wrote:
>>>>> Receivers can evaluate the Author: domain just like they would do 
>>>>> if it were the From: domain. 
>>>>
>>> Yes.  In case of conflict, evaluation of Author: has to be omitted.  
>>> For example, Author: fields containing multiple mailboxes are not 
>>> considered.
>>
> It is an optional evaluation.  It's easy to do, if you already verified 
> DKIM and SPF.  It is not terribly useful, admittedly, except that having 
> two or three "pass" makes for a stronger authentication than just the 
> From:.  The chief reason for evaluating it is to give feedback to the MLM.

There is no specification for doing this.  It means that there is no 
basis for the creator of the Author field to expect such an 
interpretation and no basis for a receiver to apply it an expect it to 
be valid.

An interoperability standard require a shared definition of action and 
meaning.  The sharing is among the actors participating in that standard.

For one side to choose a behavior or an interpretation that is not 
documented and shared by the other participants is to pretend that a 
heuristic is more than that.

>> 2. Again, this seems to defeat the purpose of having the Author field.

The field is intended to be free of the problematic treatment the From: 
field is now getting.  You appear to want to encumber it, so that it 
experiences those same problems.

>>>>> result of the evaluation, conveyed through aggregate report, can 
>>>>> tell MLMs if rewriting From: was necessary.
>>>>
>>>> How, exactly?
>>>
>>> Author: and Sender: domains can be included in aggregate reports 
>>> along with the From: one.  The policy_evaluated can also include more 
>>> items, specifying which evaluations pass or fail.

Yes, one could modify DMARC to have its reporting include additional 
information.

d/

---

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

On Tue 28/Jul/2020 19:08:25 +0200 Dave Crocker wrote:
> There is no specification for doing this.  It means that there is no basis for 
> the creator of the Author field to expect such an interpretation and no basis 
> for a receiver to apply it and expect it to be valid.

It'd be enough to state that the "scrutiny and care comparable to that given to 
the From: header field" include evaluating the domain —if unique— against 
validated identifiers.

> For one side to choose a behavior or an interpretation that is not documented 
> and shared by the other participants is to pretend that a heuristic is more 
> than that.

If the aggregate report format (see below) includes provisions for transmitting 
the result of those evaluations, the circle is closed.

> The field is intended to be free of the problematic treatment the From: field 
> is now getting.  You appear to want to encumber it, so that it experiences 
> those same problems.

One of the DMARC specs might suggest what dispositions make sense according to 
the evaluations and the various DMARC records found.  A "fail" result on the 
Author: domain should not compromise delivery (unless the domain is the same as 
the one in From:.)

I understand that asking to perform an evaluation for the sole purpose of 
transmitting the result may sound presumptuous.  However, it's not gonna be the 
only change affecting DMARC software, and it is an easy one to code and a 
lightweight one to run, and, if the Author: domain is significant, its results 
can be interesting for the receiver as well as for the sender.

>>>>>> receivers may refrain to apply policy dispositions.  However, the result 
>>>> the From: one.  The policy_evaluated can also include more items, 
> Yes, one could modify DMARC to have its reporting include additional information.

Best
Ale
--