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

Alessandro Vesely <vesely@tana.it> Tue, 26 January 2021 17:01 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 120A33A0B05 for <dmarc@ietfa.amsl.com>; Tue, 26 Jan 2021 09:01:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.221
X-Spam-Level:
X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 OhHmJqfnGaR8 for <dmarc@ietfa.amsl.com>; Tue, 26 Jan 2021 09:01:18 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA883A0D04 for <dmarc@ietf.org>; Tue, 26 Jan 2021 09:01:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1611680471; bh=L0adpvIS0QNhf4f2uJQ93d3OieLS4heLoj+Ch9vbER4=; l=1376; h=To:References:From:Date:In-Reply-To; b=Ad7gnuhW6MIDqVfbZw2JLPusTtes48B+6qthTNSfj1p5nM81CmLphXQl5rwW+rdNW cuEWqnmUlehh/QLhTdz3c8ivGu5DOAYEWxCuiseyc7hMmOg6SYgtSPJdxtnOfG0my4 NFO8t+3K2cGo8oFbJH/3uxGPyVr05i5pp5Lu78CngBR37503gcd7U/ZPBsNlQ
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC07E.0000000060104AD6.00006638; Tue, 26 Jan 2021 18:01:10 +0100
To: dmarc@ietf.org
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> <CAH48ZfyOe2PkkAZ5yPqb3wP=WctnRMBLqt2bmyj_p7gd6nmRxQ@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <5d1a5c1f-99a5-37ac-4177-a995c71c4e42@tana.it>
Date: Tue, 26 Jan 2021 18:01:10 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <CAH48ZfyOe2PkkAZ5yPqb3wP=WctnRMBLqt2bmyj_p7gd6nmRxQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Y780zwr-3rx1vDZAbgbqwNmH1cc>
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 17:01:20 -0000

On Tue 26/Jan/2021 15:12:57 +0100 Douglas Foster wrote:
> At some point, an investigator will ask, "which of our systems sent these 
> messages?"


Possibly none.  In that case this is either an abuse or a forward.  Or maybe 
the report generator lies.


> 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.

A smart relay can put together in the same message several RCPT commands with 
different domains having the same MX.


> 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?


In case of forwarding, the last hop is likely not to be aligned.  Previously in 
this thread you said reporting aligned identifiers only would suffice.  Aligned 
and last hop don't necessarily match.


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


If every receiver generated aggregate reports, senders would get the whole 
chain, in different reports.


Best
Ale
--