Re: [dmarc-ietf] Reporting rewrites

Alessandro Vesely <vesely@tana.it> Thu, 05 August 2021 17:16 UTC

Return-Path: <vesely@tana.it>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAD23A1A63 for <dmarc@ietfa.amsl.com>; Thu, 5 Aug 2021 10:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhluSW3EPYZ8 for <dmarc@ietfa.amsl.com>; Thu, 5 Aug 2021 10:16:20 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3D733A195F for <dmarc@ietf.org>; Thu, 5 Aug 2021 10:16:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1628183773; bh=MxT5ZWYlOs+E0onBddQ8795UondEcRD+SA52CfCX6uI=; l=3916; h=To:References:From:Date:In-Reply-To; b=AQx2tVFCFMMbYnITTw4E3eXpZ7X8Aah96pBf9TlBXjUPAvXSDGSuqq2MXfNSRg7uQ PLGyQBoyulxlrYEvekNME/Swl62mVmFjWPiH45oiu9bSPVbVhDu87aoAVFUJPtYtLf tMN3KBaubzmlEKimZ+n8iGrym7VnbNpTRBUJ/nOY9CctKbYVeVA3WRIC0wT93
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [192.168.1.103] ([2.198.14.128]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC028.00000000610C1CDD.000075DC; Thu, 05 Aug 2021 19:16:12 +0200
To: Todd Herr <todd.herr@valimail.com>, IETF DMARC WG <dmarc@ietf.org>
References: <CAHej_8=LL_KWcVYnc2quYSGMnQF5bdoerDtTZZm1yGjxjCqW1Q@mail.gmail.com> <20210803021005.EE5CF257D352@ary.qy> <CAHej_8k0rZHY02_mAMfc19dUOVREbd_WdTr5whUuNHmggx+cdA@mail.gmail.com> <CALaySJKb32r36Eq89_bM_dv4NeMtPmkgzHJX=AW+QVM-skHoVQ@mail.gmail.com> <CAHej_8kFB+icKyhTNUhbAV39Fa5KJBAXDb+REQM_1CPaUnkXzg@mail.gmail.com> <5cb4c752-f634-a385-06b0-4d9af6a00c8d@gmail.com> <CAHej_8=OSqFGU-DGOXNYeNNWAACg8bjKTQq8YH_Ccqc8RGMs5g@mail.gmail.com> <275ffcd2-f84d-1cd2-b1da-4aa545a92691@tana.it> <CAHej_8=oLwLDFQCQTT+VSXdcCOC66kjO+mTgZ6JRKJuXMr-2rw@mail.gmail.com> <cc1ecbc5-eca6-0cf0-3ec8-0485798b0e0e@tana.it> <CAHej_8nt_F4RcdxF5h=uFQeU3tDw2sbO9ONGGn132TNN0U12TA@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <ff5ab6d5-0ef3-041b-4fd0-32caafc583d6@tana.it>
Date: Thu, 05 Aug 2021 19:16:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CAHej_8nt_F4RcdxF5h=uFQeU3tDw2sbO9ONGGn132TNN0U12TA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/vckHMBmhrGafOppIiz1VY-5enj0>
Subject: Re: [dmarc-ietf] Reporting rewrites
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Aug 2021 17:16:28 -0000

On Thu 05/Aug/2021 13:34:59 +0200 Todd Herr wrote:
> On Thu, Aug 5, 2021 at 3:02 AM Alessandro Vesely <vesely@tana.it> wrote:
>> On Wed 04/Aug/2021 19:40:31 +0200 Todd Herr wrote:
>>> On Wed, Aug 4, 2021 at 5:32 AM Alessandro Vesely <vesely@tana.it> 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.
> 
> Why or how could the final receiver send a report to the originator, though?
> 
> DMARC record lookup is based on the From: domain.


MLM transformations are not meant to conceal it.


> If the From: domain is munged so that it's now one that belongs to the
> intermediary, there's no way to know what the originating domain was,
> because there's no standard for munging.
> 
> Perhaps at a future date, if draft-vesely-dmarc-mlm-transform or similar
> becomes a widely adopted and implemented standard, then receivers might be
> able to easily send reports to originators.


Since munging is not a standard, I don't think unmunging could be. 
However, as we're granting citizenship to the former by describing 
pct=0, we could as well admit that the latter is possible.  Is it a 
desirable feature to restore the original From:?

Some say ARC will help overcoming From: rewrites.  How?  Certainly not 
because MLMs will stop rewriting all of a sudden.  If all what is 
wanted is to restore From:, it seems more likely that either the 
originator or the MLM will set up the header so as to allow doing so.

Now, it has been said, and perhaps will make its way to the spec, that 
p=quarantine; pct=0 will remove from reports the information about 
indirect mail flows.  Since we know that such information can be sent 
nevertheless, to ask how to deal with such cases is a legitimate question.


> Remember though that MLMs are only one special case of
> intermediary; auto-forwards, such as alumni.foo.edu or even
> joe@mailboxProvider1.com that just forwards everything to 
> jsmith@mailboxProvider2.com are other cases that can cause
> authentication failures and to the best of my knowledge there is no
> standard for header munging for those cases, and frankly those
> hosts operating as intermediaries in those flows may be less
> inclined to change their systems than some MLMs have been.

Forwarding without rewriting From: is a different problem.  It usually 
works, except for some cases that can be cured by strengthening 
signing practices.  Auto-conversions seem to have been eliminated 
already.  Further refinements to preserve DKIM signatures may be needed.


> The IETF and you are perhaps outliers in regards to the amount of
> effort expended to accommodate DMARC, and I applaud both of your
> efforts, but I think we're a long way away from anything 
> approaching universal receivers reporting to every hop that handles
> a given message.

Actually, reporting at every hop where just the recipient changes is 
the normal practice.


Best
Ale
--