Re: [dmarc-ietf] Two new fields in aggregate reports

Alessandro Vesely <> Fri, 25 October 2019 08:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DECF120273 for <>; Fri, 25 Oct 2019 01:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1152-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vES0oeOS8b8i for <>; Fri, 25 Oct 2019 01:40:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 921CA12026E for <>; Fri, 25 Oct 2019 01:40:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=delta; t=1571992813; bh=j3EGWBBnzFqfDG9up4v20M7w7D/4TicpzFLc2XOMXpg=; l=2987; h=To:Cc:References:From:Date:In-Reply-To; b=A1RKODViyqPxkD26kIs/KmbR89wmsmYtfNIIcUvai30/lH5JHhsoan6nwGZ+e4g1U ewfBFwzMN+D3Zb4qN27Pc7U9sIQ9ddWKNJSsxbB21Dvsy0lbPA0xSmx6BDbOhgNnlL q8K+TVrCF0PRC1sKspCwpeqeEHQw9i9lG51vRMM1mb8unFBm3kzPMVdsVN0HB
Authentication-Results:; auth=pass (details omitted)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by with ESMTPA id 00000000005DC056.000000005DB2B4ED.00004204; Fri, 25 Oct 2019 10:40:13 +0200
To: Brandon Long <>
Cc: "" <>
References: <> <>
From: Alessandro Vesely <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Fri, 25 Oct 2019 10:40:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [dmarc-ietf] Two new fields in aggregate reports
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: Fri, 25 Oct 2019 08:40:20 -0000

On Fri 25/Oct/2019 02:53:32 +0200 Brandon Long wrote:
> On Thu, Oct 24, 2019 at 10:55 AM Alessandro Vesely wrote:
>> In order to ease the understanding of aggregate reports, I propose two 
>> additional per-record fields:>>
>> *score*:  The average score of the messages in the row; let's say an 
>> SA-like number (< 0 good, > 10 bad, values in between may be worth human 
>> inspection).>>
> This assumes that your spam system is able to make a spamminess score that 
> approximates a continuum, I'm not sure that's true.

The spam score is a rather common concept.  Of course, an MTA which does not
implement any such thing would omit this field.

> Also, it's a lot of spamminess feedback, not sure if that can be abused or
> not.

Correct.  However, it is an average, so a spammer would have a hard time trying
to work out the detail of how the receiver's score is computed.  Again, a
reporter may compute the std deviation along with the average and omit this
field if all messages have equal score.

OTOH, this is indeed a valuable feedback.  Mail sites could build their own
reputation system based on that.  A community IP database.  Revolutionary,
isn't it?

> Also, as rejected at smtp time, especially for DMARC, we're unlikely to have
> run a full spam assessment on the message.

Perhaps we could add a second count.  Or break the record into two rows.

>> *list*:  An enumerated type, for example "none", "black", "white",
>> "both", indicating if the source IP is listed in some public or private
>> DNSxL that the reporting MTA uses.>>
> At first I was wondering if you were going to have the values of the
> list-id header.

Ah, that way we'd get rid of all those "on behalf of"... :-)

> That said, though I've never used any DMARC aggregator services, I would 
> think that one of the values they're likely to provide is IP address
> identification, useful so you can hunt down what things aren't sending DMARC
> compliant email yet (ie, looks like you're sending mail from ESP A and ESP
> B, fix those)...


> they can just as easily use the various public IP reputation sources.

Yes, could do, but it's more difficult.  Here the reporting MTA already has the
datum, and can include it for free.

This datum would be vouched by the reporting MTA.  It can be internal, like a
fail2ban database.  How about also reporting the source, if external?

> Anyways, I doubt we'd expose anything internally...

I always wonder why Google doesn't publish their internal IP database.

> also, this is kind of the opposite of the spamminess score, in that it
> expects that things are black & white, and we virtually never classify
> things as such.

The aim is to be able to look at an aggregate report and understand it.  For
example, if people can tell an IP is blackish, they'd just smile and be happy
for a good failure case.  What field would you suggest instead?