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

Douglas Foster <> Tue, 26 January 2021 12:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA3DA3A0BB2 for <>; Tue, 26 Jan 2021 04:03:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.197
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id px6rHKiR-CGO for <>; Tue, 26 Jan 2021 04:02:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C84603A0BB1 for <>; Tue, 26 Jan 2021 04:02:58 -0800 (PST)
Received: by with SMTP id o186so8871151vso.1 for <>; Tue, 26 Jan 2021 04:02:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=/QzyVfBgFnoo7Wk3jFukeuwocZKl39S7yXuPpAIlLAc=; b=tMkvm1cUO+MKISwf7z/zdEPu4DhJPCT4cBFecE7/K1j6lxHiDfIZYb7XRuqMtuIY8e z+A4a93+NFXBaHNYeY4lOEGG9LTfRVEQbQHCH/zd7wvCSMBZ0FhJYjObBPZ22tP6NXXI HQ9JTGzipNIsDrYkOtD02HF0xVWEZ/SKPAwBzfc2jkoMca8NQ1Lhsg8JKp3807UqHW9B MA3vTaJ3aDlFGrGR23u0PLyFf1p16haiHQgPyPtnbCb0R8V01kYgkb7cCTWDimU68/8s jdvp6CPN4XLVlwbecHvnYxuEC/kQUcOUfMrkHp+83UyXe+Lirt/+MpJoteKRzMxtLB7R txng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=/QzyVfBgFnoo7Wk3jFukeuwocZKl39S7yXuPpAIlLAc=; b=p398GcQ/k7P9Ishd7EkKy+VIyIBJajCp7Z3e4l9kTq67QHrxaWvM9KwaxR4Kesgf1O zuN4O6FqWqLK1rCeh267soZKJOVqzIpziOFWWGULTiVJZCeeCVshrQGgoBc5HaPwe0Gl E0+/F44rc3ausHh1M/6GcT21gw+zVBWsEpI1n/Ocojs/GkvX/DDyS37YrleUoph8+RrK Raomrk7r6KUgdmqAeDs312YrJ0OlZ9xWtAqzJWaW4zDQsTXvE4wfPiVTp3/JB19spuQ2 YxSzWSI5SsP1OFzMfcTlsBu7f0VRCBzL8SOLik9i8c7+cFqq24Mb9N4PNaedU8o5AQkr JgIQ==
X-Gm-Message-State: AOAM532vFSh1ETA0KlVTHceBGjkoSPQ2HsQ0C/W/Xqf9Mf79N55Aeei7 DF+vQWDRUUI7RlPTGhVaoggcrjqAjqETm7L4n6ZA7xb/hOs=
X-Google-Smtp-Source: ABdhPJz94Twt+py9Ye7rOZzfjQILCW6xPkv0nAUdUai2Eu4cRH63rs41IZSs+tk2pchcC7UKMjQIp7PLzHESGwG2mfM=
X-Received: by 2002:a67:24c5:: with SMTP id k188mr3984821vsk.16.1611662577419; Tue, 26 Jan 2021 04:02:57 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Tue, 26 Jan 2021 07:02:46 -0500
Message-ID: <>
Content-Type: multipart/alternative; boundary="0000000000006cc87105b9cc6ff6"
Archived-At: <>
Subject: Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Jan 2021 12:03:01 -0000

This topic becomes much more than "which signature".   It is really about
"what is needed to identify and correct alignment problems".

Based on the authentication discussion, we have several inter-related
- I started with a concern about putting excessive data collection
requirements on the reporting domain.

- Increased data collection causes data disaggregation.   This becomes a
technical problem as report sizes increase.   Disaggregation also allows
individual message characteristics to be revealed, which becomes a
potential privacy concern.

- In theory, very few attributes should be necessary to triage an alignment
problem:  Source IP, SMTP domain, From Domain, and DKIM scope.  In
practice, investigating root cause is difficult and as a result report
recipients crave maximum data.

My current perspective, still open to being convinced

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.

I would also suggest dropping the requirement to include all authentication
test results.   Only SPF and aligned DKIM are relevant, and anything more
causes disaggregation.

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

I wonder if the solution to both of these is to use variable aggregation.
  When the number of target domains is small, reporting the source domain
is probably not an issue for either the report sender or the report
receiver.    So we could make the field optional, where some organizations
report an actual target domain and others report a placeholder, with the
level of aggregation chosen by the needs of the reporting organization and
by overall constraints on report size (probably based on number of result
rows).  The same could apply to DKIM:   If disaggregation by DKIM scope
provides a report that is too large, the scope can be replaced with a
placeholder to increase aggregation and reduce report size.


On Mon, Jan 25, 2021 at 1:38 PM Alessandro Vesely <> 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
> --