Re: [dmarc-ietf] Reporting rewrites

[Alessandro Vesely <[e-mail]>]

  On Wed 04/Aug/2021 19:40:31 +0200 Todd Herr wrote:

> On Wed, Aug 4, 2021 at 5:32 AM Alessandro Vesely <[e-mail]> 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: <[e-mail]>
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 <[e-mail]>

During the night, the final destination's server sent an aggregate report to [e-mail].  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>