Re: [dmarc-ietf] Reporting rewrites
Todd Herr <todd.herr@valimail.com> Thu, 05 August 2021 11:35 UTC
Return-Path: <todd.herr@valimail.com>
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 550013A0C9F for <dmarc@ietfa.amsl.com>; Thu, 5 Aug 2021 04:35:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com
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 P_AILJGA0cRE for <dmarc@ietfa.amsl.com>; Thu, 5 Aug 2021 04:35:17 -0700 (PDT)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15EF33A0BF5 for <dmarc@ietf.org>; Thu, 5 Aug 2021 04:35:17 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id t3so4571567qkg.11 for <dmarc@ietf.org>; Thu, 05 Aug 2021 04:35:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Smb/MyWWed3g6/1WRDxO5QBuHBAJOGk7e0UDQ66n3dA=; b=YNq6uk0njTz3iqsMa9DQiL5TigC0T97cNhgH1maGW713n92TM+lqjSk5NCes7NeGbi fabyKhO4BfNC5nvcN1UrgFyVCy/1wDgbmxYiaU8mW7pi5A8urQ2Cxgh0Fd5ChbUSJY5/ yUwmkIL6ovkQ1HVpTims+xbSHJkzaHlXFhmB4xHk6uwVcupjWldKqcYAzysihAj7+e7K /cnCPjOK0PlXf42LF7HAb+32DjlE62hB7IthzHdQfohWpCPp+O5FoQqbVxsP97t3XhZu VRHrsCLFQOO7NWHKcRlTX9e3XErfvJ1LbF8Rb0VgLa06IUU4NNMJ/AB0N8YY/cmHRl1L 5foA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Smb/MyWWed3g6/1WRDxO5QBuHBAJOGk7e0UDQ66n3dA=; b=CDb+3U3UdRPEuGR8sCrNQTmC1mJC0QhAlTrwF+MIa8v9rlWvmjZU4vtEXmO0OADDxY Yc5AJHemYdTfW4MniJgNJx8veH77jVV2VNBt+rmWNWxtyudP1JP7SB/yG85Vbsy7J3LL vwpTxuHJgVyf6TeTO5knfIHmpCu5F8915rN9MAS7tPGefHiWqnKHl5hm2Ehi4mZLQ+Jk raXPViWFVps93QFTqWxBslejQj65dxym5t29e/zw+TmnTOIjJ/g2jRAEG7npBFUwJQuC D6rsL8HmG8jgCFZpjzKetPfc5Ln6rFJHMHzD4Cak3RQ6fUwEAk70WAYDsDfnwtV4B2pL jqNw==
X-Gm-Message-State: AOAM5306DkORCZVCIs/DRGZyTmOeBfm4otcVViLeq/OJobTthMXbonDk cPbhKhNDXtacmR/uc1lzWAuTzzt0EFFn0ksE0A9QutbeKWZm7w==
X-Google-Smtp-Source: ABdhPJxrJlOAVWXp0yWB+R2hRDtGGVVEQzRxa839Ih9vlOQ1W2KdyS3QpKrCvqp5ISrlWXMYN3NG5Pkvkzafg6fCAxA=
X-Received: by 2002:a05:620a:171e:: with SMTP id az30mr4449332qkb.325.1628163314896; Thu, 05 Aug 2021 04:35:14 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <cc1ecbc5-eca6-0cf0-3ec8-0485798b0e0e@tana.it>
From: Todd Herr <todd.herr@valimail.com>
Date: Thu, 05 Aug 2021 07:34:59 -0400
Message-ID: <CAHej_8nt_F4RcdxF5h=uFQeU3tDw2sbO9ONGGn132TNN0U12TA@mail.gmail.com>
To: Alessandro Vesely <vesely@tana.it>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000005658705c8ce5040"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/QQ-k33e8p9kDRdlYkIugFWgJDuA>
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 11:35:23 -0000
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. 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. 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. 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. -- *Todd Herr* | Technical Director, Standards and Ecosystem *e:* todd.herr@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
- [dmarc-ietf] Some Proposed Language for a New pct… Todd Herr
- Re: [dmarc-ietf] Some Proposed Language for a New… Douglas Foster
- Re: [dmarc-ietf] Some Proposed Language for a New… Alessandro Vesely
- Re: [dmarc-ietf] Some Proposed Language for a New… Дилян Палаузов
- Re: [dmarc-ietf] Some Proposed Language for a New… Murray S. Kucherawy
- Re: [dmarc-ietf] not enhanced status codes Some P… John Levine
- Re: [dmarc-ietf] Some Proposed Language for a New… John Levine
- Re: [dmarc-ietf] Some Proposed Language for a New… Douglas Foster
- Re: [dmarc-ietf] not enhanced status codes Some P… Douglas Foster
- Re: [dmarc-ietf] Some Proposed Language for a New… Alessandro Vesely
- Re: [dmarc-ietf] Some Proposed Language for a New… Douglas Foster
- Re: [dmarc-ietf] Some Proposed Language for a New… Douglas Foster
- Re: [dmarc-ietf] Some Proposed Language for a New… Alessandro Vesely
- Re: [dmarc-ietf] Some Proposed Language for a New… Todd Herr
- Re: [dmarc-ietf] Some Proposed Language for a New… Dotzero
- Re: [dmarc-ietf] Some Proposed Language for a New… John Levine
- Re: [dmarc-ietf] Some Proposed Language for a New… Murray S. Kucherawy
- Re: [dmarc-ietf] Some Proposed Language for a New… Todd Herr
- Re: [dmarc-ietf] Some Proposed Language for a New… Barry Leiba
- Re: [dmarc-ietf] Some Proposed Language for a New… John R Levine
- Re: [dmarc-ietf] Some Proposed Language for a New… Todd Herr
- Re: [dmarc-ietf] Some Proposed Language for a New… Dave Crocker
- Re: [dmarc-ietf] Some Proposed Language for a New… Todd Herr
- Re: [dmarc-ietf] Some Proposed Language for a New… Dave Crocker
- Re: [dmarc-ietf] Some Proposed Language for a New… David I
- Re: [dmarc-ietf] Some Proposed Language for a New… Alessandro Vesely
- [dmarc-ietf] Reporting rewrites, was Some Propose… Alessandro Vesely
- Re: [dmarc-ietf] Reporting rewrites, was Some Pro… Todd Herr
- Re: [dmarc-ietf] Reporting rewrites Alessandro Vesely
- Re: [dmarc-ietf] Some Proposed Language for a New… Douglas Foster
- Re: [dmarc-ietf] Reporting rewrites Todd Herr
- Re: [dmarc-ietf] Reporting rewrites Alessandro Vesely
- Re: [dmarc-ietf] Some Proposed Language for a New… Murray S. Kucherawy
- Re: [dmarc-ietf] Some Proposed Language for a New… Douglas Foster