On Wed 04/Aug/2021 19:40:31 +0200 Todd Herr wrote:
On Wed, Aug 4, 2021 at 5:32 AM Alessandro Vesely <[email protected]> wrote:
On Tue 03/Aug/2021 22:42:07 +0200 Todd Herr wrote:
[...]
I can then examine the differences in the reports, suss out
which intermediaries aren't rewriting the From: header, and
decide if I care enough about the volume I'm sending to those
intermediaries to have it affect my decision to move to a
stronger assessment policy.>>
Examining the difference in the reports sounds hard, especially if the
mail flows and remote operators' settings changed since p=none. As a
matter of fact, p=none lets a domain learn more about its mail flows,
since aggregate reports contain DKIM and SPF identifiers of mediators.
This is only true if the From: header is not munged. If it's munged to use
the domain of the intermediary, the originator will not see data about the
hop from the intermediary to the reporting destination in its aggregate
reports.
If the final receiver sent such data to the originator, then the originator
would see it.
Is that good to know? Certainly, many operators prefer not to see any
failure in the reports thy receive. Hence p=quarantine; pct=0. Is
that /all/ operators, or are there any who would like to know about
indirect mail flows anyway?
IOW: should we support an option to get aggregate reports even if a
mediator munged From:?
I submit that the option is already there...
Where?
Imagine the following path for a mail message:
originator --------> From: munging intermediary -------------> final
destination
The "From: munging intermediary" has the ability to do DMARC validation on
messages received from the originator and to generate reports to the
originator by sending them to the address(es) specified in the rua tag of
the originator's sending domain DMARC record.
The "final destination", at the same time, has the ability to do DMARC
validation on messages received from the intermediary and to generate
reports to the intermediary, presuming that that intermediary publishes a
DMARC record for its munged sending domain.
I have the following on the top of the header of the message I'm replying to:
Return-Path: <[email protected]>
Authentication-Results: wmail.tana.it;
spf=pass smtp.mailfrom=ietf.org;
dkim=pass reason="Original-From: transformed" header.d=valimail.com;
dkim=pass (whitelisted) header.d=ietf.org
header.b=TFOorAie;
dkim=fail (signature verification failed, whitelisted) header.d=ietf.org
header.b=mri3idDL
From: Todd Herr <[email protected]>
During the night, the final destination's server sent an aggregate report to
[email protected]. Coincidentally, that's the same recipient who collects
valimail.com's reports. To be clear, the subject was /Report domain:
dmarc.ietf.org Submitter: tana.it/. I paste the relevant record after the
tagline. Undoing MLM transformation is just one way to unmunge. Another
possibility is ARC. There might be more...
Whatever the technique, the final destination can try to unmunge, and that
operation can succeed or fail. The originator may be interested in the result.
For MLM transformation, how the originator signs messages is key for unmunging
success, so having feedback would have a practical use. Dunno about ARC, but
maybe feedback is useful there too. So it might seem a good idea to send
reports to the originator as well. If, instead, the originator prefers not to
clutter aggregate reports with indirect mail flows results, then the final
destination had better not to send it. That decision could be made based on a
header field, on a DMARC record tag, or both.
Best
Ale
--
<record>
<row>
<source_ip>4.31.198.44</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
<reason>
<type>mailing_list</type>
</reason>
</policy_evaluated>
</row>
<identifiers>
<header_from>dmarc.ietf.org</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>valimail.com</domain>
<selector>google2048</selector>
<result>pass</result>
<human_result>through MLM
transformation</human_result>
</dkim>
<dkim>
<domain>ietf.org</domain>
<selector>ietf1</selector>
<result>pass</result>
</dkim>
<dkim>
<domain>ietf.org</domain>
<selector>ietf1</selector>
<result>fail</result>
</dkim>
<spf>
<domain>ietf.org</domain>
<result>pass</result>
<scope>mfrom</scope>
</spf>
</auth_results>
</record>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
