On Tue 28/Jul/2020 13:09:29 +0200 Dave Crocker wrote:
On 7/28/2020 4:00 AM, Alessandro Vesely wrote:
On Tue 28/Jul/2020 12:37:32 +0200 Dave Crocker wrote:
On 7/28/2020 12:26 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.
Yes. In case of conflict, evaluation of Author: has to be omitted. For
example, Author: fields containing multiple mailboxes are not considered.
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?
(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.
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.
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.
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
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
