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

Douglas Foster <dougfoster.emailstandards@gmail.com> Tue, 26 January 2021 14:13 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 EAEAE3A0A3D for <dmarc@ietfa.amsl.com>; Tue, 26 Jan 2021 06:13:13 -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 OL_PYad-Vs8S for <dmarc@ietfa.amsl.com>; Tue, 26 Jan 2021 06:13:12 -0800 (PST)
Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 10B4E3A0A38 for <dmarc@ietf.org>; Tue, 26 Jan 2021 06:13:11 -0800 (PST)
Received: by mail-ua1-x935.google.com with SMTP id v23so5635072uam.8 for <dmarc@ietf.org>; Tue, 26 Jan 2021 06:13:11 -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 :cc; bh=OXFE3/9dUnbXILj7S4kz9mIV5YbQn3kxk95Dsb8XTOY=; b=teEy5mIECXMQvPmgZ5kJ+Dh6tzn0krV0M0q6qsdbWjay0F0kN63arsG47tv4d09GOw aykAX0e1aKbrWg9i+RY4lwrOEsnt+40u8r9dq8+gI9AihhzAQ0c+hKFtg8m3P3+uGBNh 2CNyL+HfP6Su121Uv1muWUzD0rDDwea99NNAgjbB8gt9dvlHJe4pNv3mPDFgdrRuLwor BqUjGfEgiG8w3jx7XiqC6eRR2wOpfv8lDDv8qsYidNjoU9B93Ga9E60tubcf8PaVRDd+ 2DeKG7uyNy1tgMNx9k0CFuaZaV8PjJYEmKCo0W7DFJ4Ap1pbTIfxnBQPgmr2i5WAOzf4 buUQ==
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=OXFE3/9dUnbXILj7S4kz9mIV5YbQn3kxk95Dsb8XTOY=; b=biz0/2//aeP6mz7riR5gehKa6SCeHG0CVtgQIQmvRdJsEoasRJ5V28oAgvgycrtjfa wbxkIlg4c3HkuQg1PuX84KYQcYDvQ1ArgmnMY/BjCTTeA1XeM8VHaxHxT2IzVcMmdcVH knN57pEwLIOQ/FUytgA9JkrSnfTOO/ZpEu60hNuaYqYew9ffCJXFriMtdYqCxDFYVgRv e54X1zBqfgGNp6GHmeHeL5wXupDq/yM/cgEXEmvG3XIu/CRB1z2/O/qTZeEHeWjugUvn Ft5LoQh2UEiT4dyT5x6Tc3J3OUbeUzejZUl2nBjFL0cVhXW4IdyM1pcwA/5/rkaRIAsK SARg==
X-Gm-Message-State: AOAM53000QOMe7odOzjOio6N6MZPYC9F3D3mHkSoIb8LnQbXU3/mCy0y qpLb+m8E7NGmnbsVcq+6ib6ziYaOISQoFNBoq2A=
X-Google-Smtp-Source: ABdhPJyAOo0ZJNDQL9dLEjyCFBbBOURCXjkIbKug91/y7Waq5NHquUGF/vUNdodFj9UXmygWwleWawHdn2sK6iMoT9A=
X-Received: by 2002:ab0:3043:: with SMTP id x3mr4280105ual.88.1611670390795; Tue, 26 Jan 2021 06:13:10 -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> <CAH48ZfwvBj3abrAEz1uK2UNyMOBAM1q3pH8cOmazn8VBow3ACQ@mail.gmail.com> <adcede1d-a260-7b78-9439-63eb706989e2@tana.it>
In-Reply-To: <adcede1d-a260-7b78-9439-63eb706989e2@tana.it>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Tue, 26 Jan 2021 09:12:57 -0500
Message-ID: <CAH48ZfyOe2PkkAZ5yPqb3wP=WctnRMBLqt2bmyj_p7gd6nmRxQ@mail.gmail.com>
To: Alessandro Vesely <vesely@tana.it>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000023722205b9ce41e3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/iEdWa3N6Yu_lPJGA0KyZkp5REec>
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: Tue, 26 Jan 2021 14:13:14 -0000

At some point, an investigator will ask, "which of our systems sent these
messages?"

I know how to search my logs for messages to domain example.com.  I do not
know how to search my logs for messages to domains hosted by
hostingservice.tld.  That is why I would expect SMTP To domain to be useful.

An rua report is not supposed to be substitute for a forensic report,.  All
possible details are not supposed to be presented.  Source IP, SMTP
MailFrom domain, and SPF status should be sufficient to identify the
organization responsible for the last hop.  Why is additional mailflow data
necessary?

The best mail flow data would be to report the entire Received chain, but
it would cause too much disaggregation.

On Tue, Jan 26, 2021, 7:50 AM Alessandro Vesely <vesely@tana.it> wrote:

> On Tue 26/Jan/2021 13:02:46 +0100 Douglas Foster wrote:
> > DKIM Scopes
> > I have not heard a compelling argument to require information about
> > authentication tests that are unrelated to alignment testing.    For
> DKIM
> > specifically, I think one scope should be sufficient, on this hierarchy:
> >
> > - The best-aligned scope that verified, or
> > - the best-aligned scope that failed verification, or
> > - a no-signature result otherwise.
> >
> > Anything more complex imposes a gratuitous data collection burden on the
> > reporting domain and reduces aggregation significantly.   On the
> technical
> > side, it has already been noted that variable-length lists are
> particularly
> > problematic for calculating aggregates.
>
>
> Let me attach an HTML rendering of a report I received today, so we can
> talk
> about something real.
>
> Lines with IP 4.31.198.44 bear a ietf.org identifier.  I see no reason to
> remove it.  It is useful for understanding the mailflow, which is what
> DMARC
> reporting is designed to do.
>
>
> > Aggregation Controls
> >
> > We have discussed whether the target domain should be included in the
> > report.  I understand that doing so is not reasonable for the large
> hosting
> > services.   On the other hand, including the target domain would be a
> > trivial matter for smaller operations, and I think it would be valuable
> for
> > some research.    Similarly, DKIM scopes are known to be useful for most
> > investigations, but John has already observed that proliferation of DKIM
> > scopes can be used to force disaggregation down to the individual
> recipient
> > level.
>
>
> Even if this is a small example, learning the disaggregated, or even
> individual
> recipients does not help my understanding.  Authentication is obviously
> conditioned by how the Mediator treats my messages.
>
> I expect that Fastmail Pty Ltd carries out SPF and DKIM validation using
> the
> same algorithm, irrespective of the recipient.  That is what I, as a
> sender, am
> interested in.  Splitting the report in 66 lines wouldn't tell me anything
> more, it would just consume more eyeballs.  And is useless for people who
> sum
> up all reports and just look at the totals.  In any case, I cannot verify
> if
> the messages I didn't send directly are real.
>
> If a multi-domain host allows personalized validation algorithms for some
> domains, I'd expect they send separated aggregate reports, if any.
>
>
> Best
> Ale
> --
>
>