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

Alessandro Vesely <vesely@tana.it> Sat, 26 October 2019 10:58 UTC

Return-Path: <vesely@tana.it>
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 53CE912006E for <dmarc@ietfa.amsl.com>; Sat, 26 Oct 2019 03:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 jOfy5ZbG3kPz for <dmarc@ietfa.amsl.com>; Sat, 26 Oct 2019 03:58:07 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B97412002F for <dmarc@ietf.org>; Sat, 26 Oct 2019 03:58:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1572087482; bh=Sjph5qTBoA+CiHJRvi4EoK7nVRonUskG4vsdUXLNPjU=; l=2062; h=To:References:From:Date:In-Reply-To; b=DJwFeN/HwE/ZWTPXXEZkPH0gpahI2xHib9aO575bPERv8qiVWjCLnINdZwXq8iqM3 +wte0zI71UpRO+JKw4GS6ii1O2MPPrFjzh6pkK8/TdyIYnME9zvmMyc9fsblf4/Rc8 hummv3bsAExc+XAF/95zJJLu59ZIcNyf1uYJe3X02crCNXinWIfuNGxK51QUl
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA id 00000000005DC085.000000005DB426BA.00002606; Sat, 26 Oct 2019 12:58:02 +0200
To: John Levine <johnl@taugh.com>, dmarc@ietf.org
References: <20191025201344.BB28AD68CE6@ary.qy>
From: Alessandro Vesely <vesely@tana.it>
Openpgp: preference=signencrypt
Message-ID: <677fd9cc-f7ce-8904-2e27-644f9f442e29@tana.it>
Date: Sat, 26 Oct 2019 12:58:02 +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: <20191025201344.BB28AD68CE6@ary.qy>
Content-Type: text/plain; charset=us-ascii
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/UizqjCMQLt967LnDXym2wotGiDY>
Subject: Re: [dmarc-ietf] Two new fields in aggregate reports
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: Sat, 26 Oct 2019 10:58:09 -0000

On Fri 25/Oct/2019 22:13:44 +0200 John Levine wrote:
> In article <682972a4-38e4-f5b2-3180-c5a03a3a08b4@tana.it>; you write:
>>Looking at aggregate reports, you cannot tell whether an authentication failure
>>is a sacrosanct signaling of your domain being abused rather than a legitimate
>>user going through external forwarders.
> 
> Sure you can, you look at the IP address and see who it is.  In my reports I
> see bursts of authentication failures from hosts that are obviously mailing
> list servers, and lots of failures in China which are random spambots.


Right, to add a country lookup during XSLT transform is a nice hint.  IP
reputation sites are not quite as handy.


>>In theory, reports can be something more than a debugging aid.  It has the
>>potential to assemble a community where bad actors are identified and dismissed.
> 
> No, that's not what they're for and they don't have the necessary
> info.  There are systems that compile data for IP reputation but
> that's not what DMARC is.  The point of DMARC is to try to tell "is
> this message really from X", not "is this message spam."


There are spammers who abuse other domains, and not all of them are phishers.

While hard policies don't seem to be a goal for seldom-abused domains, failed
p=none hardly map to some kind of score.  So, yes, it looks like some necessary
info is missing.  But why would more info hurt?

The biggest obstacle is admins' reluctance to divulge internal data about their
mailflows.  Perhaps we should instead look for something that mail site admins
are eager to communicate to their peers.  I, for one, see many more DMARC
target domains than sources (73 to 13 this morning, most of the latter from my
yesterday's posts to this list).  I guess such ratios are rather common,
possibly worse for large sites.  Correct?

Curiously, in general, people and organizations seem to have a lot to say,
while they are often reluctant to listen.  How come DMARC, as a channel,
induces the opposite behavior?


Just thinking aloud
Ale
--