Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)

Douglas Foster <dougfoster.emailstandards@gmail.com> Mon, 25 January 2021 18:52 UTC

Return-Path: <dougfoster.emailstandards@gmail.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 CE8763A174C for <dmarc@ietfa.amsl.com>; Mon, 25 Jan 2021 10:52:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 AyjjmhCGKrVm for <dmarc@ietfa.amsl.com>; Mon, 25 Jan 2021 10:52:15 -0800 (PST)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 4F1993A174B for <dmarc@ietf.org>; Mon, 25 Jan 2021 10:52:15 -0800 (PST)
Received: by mail-ej1-x62b.google.com with SMTP id gx5so19541345ejb.7 for <dmarc@ietf.org>; Mon, 25 Jan 2021 10:52:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=UKH9DvbG01VMYzb56TY/fpTUhI4lFjcH6Sv1jpqxww0=; b=NXmPUE0UboBexZYpxUcjmfJe9KUrxpZ96k+6p6n+KsrWbmMsFKjDsK5l7OOurFdniB IWOthO7We6gPk0rNvbb2lXXUqIqvd9mv3t2jcBDvz04A5xyYkyoye6de4ogydjUyBi2q pNfOT/j4SzzfPVovky1rPMGLwWFXEh/f2xWnLB2+tG5i+RxASsacF0DW7Zt/+XGA1EwJ KXdCR6c7FtjbNBM62ohMBtK1HvLb7tyZolaToqprYptuIr6XIGb/M84TcdRvb4i2fpQT umx4R8FusD4fTJPvY0wP83rlvCtB1riTQmnQ5acDlbsZrsmr33dHPDptSXLiYRbxucVZ oBVg==
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; bh=UKH9DvbG01VMYzb56TY/fpTUhI4lFjcH6Sv1jpqxww0=; b=qGPKHWUCRTuCZNqKJbnx9t/9DZij3sC1Mqi4CV2iG+ot2cCUt6qCPeEnWFsLRaeMHC dn7yv11Ca8+93IfLwrLI9nj66tZ7YOGIHGZouFnXVbZikAROjDBttQVpEinZPexCxqMk BSOdEWehcRvxwbit+GZOtP6zD0LVrRoqVOIvZlarPGfvVKBjUU8N68KhqJLiJ0rxdMS+ 1I1rVcrG5Lcwbl4Y/p9WykoBX9Q8opVnO2iZyVAa8tpXbGI2lJl14GBApL4K8nuztWWt ssuAr/eguXiNesdYJZBVzKxMPjDZ9rLohKMutrbZFURIzw6i0dTEljqnLVIqkbbQIEBG JGPg==
X-Gm-Message-State: AOAM532MeJC05NDvKF8JepDEGCIKtcCyGDbod64xxR7+b/ccI5OWXYBb z8T3fk8I24YsT80bTQQQCA6W8/7pUSVOjwGX1YfPakeA
X-Google-Smtp-Source: ABdhPJxSv39gI+rWE2Cr1WxLFEu3rU5UI04KpW6RYYdGRIfxLVMih59KGDjaTUSDF2saGWYM+PSsr8rVoboQRKOmkRM=
X-Received: by 2002:a17:906:ff43:: with SMTP id zo3mr1204382ejb.542.1611600733642; Mon, 25 Jan 2021 10:52:13 -0800 (PST)
MIME-Version: 1.0
References: <MN2PR11MB4351BD7203D41DB25771D3B3F7BD9@MN2PR11MB4351.namprd11.prod.outlook.com> <CAH48Zfwat5MmXrvfEp-G=0pTZe2fwwDOJ6s6M1FSWs6M50yk0w@mail.gmail.com> <MN2PR11MB43513C20B5A598496FFBA4AAF7BD9@MN2PR11MB4351.namprd11.prod.outlook.com> <7231cfb1-1553-fd11-e356-57b960c5bfdc@tana.it>
In-Reply-To: <7231cfb1-1553-fd11-e356-57b960c5bfdc@tana.it>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Mon, 25 Jan 2021 13:51:59 -0500
Message-ID: <CAH48ZfyCNmYMqe_5NP84DtLAm1P8r5HPwVS_JBsBc3SXZfWOtg@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003fa40b05b9be099f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/e88KGdDc66quKJm-XnsE-BYTh18>
Subject: Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)
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: Mon, 25 Jan 2021 18:52:17 -0000

Can we go slightly off topic to review why the report does not include the
destination domain?

That data element seems a lot more relevant than a tertiary signature.

I can see that domain identification and disaggregation could significantly
increase the size of reports from Gsuite and Office365, assuming that they
currently aggregate all domains.   This could be problematic for both them
and for the recipient.

On Mon, Jan 25, 2021, 1:38 PM Alessandro Vesely <vesely@tana.it> wrote:

> On Mon 25/Jan/2021 18:59:16 +0100 Brotman, Alex wrote:
> >
> > I’m not suggesting that we add anything that would report “Signature
> > validation not attempted”, that sounds horrible.  Will the original
> source
> > potentially care that the message was signed in three other places as the
> > message bounced around?
>
> It can be useful to understand the mail flow.  For example, a signature by
> a
> Mediator can reveal a mailing list, even if the receiver didn't evaluate
> it.
>
>
> > Should we put the onus on the reporting entity to do the filter out the
> > non-aligned (what if none aligned) signatures, or just realize it’s some
> > automated job and including all logged/validated signatures is the better
> > way?
>
> The order in which signatures appear in a report can be significant too.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>