Re: [dmarc-ietf] Endless Loops with DKIM reports

"Douglas E. Foster" <fosterd@bayviewphysicians.com> Fri, 07 June 2019 23:03 UTC

Return-Path: <btv1==061bcd72c02==fosterd@bayviewphysicians.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 E1A19120161 for <dmarc@ietfa.amsl.com>; Fri, 7 Jun 2019 16:03:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=bayviewphysicians.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 lho--RZYfRlN for <dmarc@ietfa.amsl.com>; Fri, 7 Jun 2019 16:03:30 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE04112002E for <dmarc@ietf.org>; Fri, 7 Jun 2019 16:03:29 -0700 (PDT)
X-ASG-Debug-ID: 1559948608-11fa3116c8398a00001-K2EkT1
Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id g4yjSCckCDSCssA1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Fri, 07 Jun 2019 19:03:28 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-ASG-Whitelist: Client
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=7DI8lWgd++bjabQ+IWFbppyQMCPwDKcNT/BchJ9Jds0=; b=efIkIMlX++PW0qYYNI7gx4wjCW4M4zJAsrHnxzoBC+PE6MVM/oitaijy4N2utMfmj oM52LRHzgFz56YwcAXPS+cT8hLd+G8ho6QyquW9w1dQKya94sMFdYnAP9QeW0C0zp i1PCJLxhVu/GAXfC6RQWa5hhZyzTnUOaF/fY6fZAQ=
Received: by webmail.bayviewphysicians.com via HTTP; Fri, 7 Jun 2019 19:03:19 -0400
From: "Douglas E. Foster" <fosterd@bayviewphysicians.com>
To: John R Levine <johnl@taugh.com>, dmarc@ietf.org, dcrocker@bbiw.net
Date: Fri, 07 Jun 2019 19:03:19 -0400
X-ASG-Orig-Subj: Re: [dmarc-ietf] Endless Loops with DKIM reports
Reply-To: fosterd@bayviewphysicians.com
Message-ID: <1f3e445b735945369d93ce594c8fae65@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="d5143100ad0d4d6f9ad9e4109933956b"
X-Originating-IP: [192.168.1.239]
In-Reply-To: <b7f40e8d-ddf1-8fb4-79a6-71158e0eeb91@dcrocker.net>
References: <20190605200619.2ED512014FE9B7@ary.local> <787538c5-9032-8f4d-e3f2-7e3eeb357503@dcrocker.net> <alpine.OSX.2.21.9999.1906061003130.2459@ary.local> <b7f40e8d-ddf1-8fb4-79a6-71158e0eeb91@dcrocker.net>
X-Exim-Id: 1f3e445b735945369d93ce594c8fae65
X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1559948608
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 5950
X-Barracuda-BRTS-Status: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/HKnKqNI9gX1jxGGt5XVtgK5JE-M>
Subject: Re: [dmarc-ietf] Endless Loops with DKIM 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: Fri, 07 Jun 2019 23:06:34 -0000

Suggestions for eliminating loops:
  
 Best (sender controlled)
 The report-sending account should be from a non-reportable domain or 
subdomain.   Authority to report on behalf of another domain/sub-domain can 
be established with a DKIM signature of the reporting domain.   Of course, 
if the report-sending domain is a subdomain of a reportable domain, the 
sub-domain needs its own DMARC policy to disable inheritance and to disable 
reporting.
  
 The report-sending account could be placed in a domain/sub-domain which is 
send-only (SPF policy but no MX records).   This prevents out-of-office 
messages, NDRs, or spam from being sent to the report-sending account. 
  
 A null sender would be one way of producing this result, but it may be 
difficult to implement in some configurations.   Additionally, messages 
from the null sender are more likely to be rejected by BATV filtering.
  
 Alternate (sender controlled)
  If the report-sending account is in a domain/sub-domain that collects 
feedback, messages sent to the report-sending account must be excluded from 
feedback data collection.
  

  
 Backup (recipient controlled)
 Option 1:  The recipient account should be in a domain/subdomain that does 
not collect DMARC feedback.
 Option 2:  If the recipient account domain does collect feedback data, the 
recipient account must be excluded from feedback data collection.
  
 Since the sender cannot know whether the recipient domain collects DMARC 
feedback, he should not rely on the sender being able to prevent looping.
  
 I think these methods will eliminate the need for rate limiting.
  
 Doug Foster
  
  

----------------------------------------
 From: "Dave Crocker" <dhc@dcrocker.net>
Sent: Thursday, June 6, 2019 4:28 AM
To: "John R Levine" <johnl@taugh.com>, dmarc@ietf.org
Subject: Re: [dmarc-ietf] Endless Loops with DKIM reports   
On 6/6/2019 10:08 AM, John R Levine wrote:
> If people follow the spec there will be fewer loops, but it won't reduce
> the number to zero.

Forgive me, but I believe there is currently no spec to follow. Yet. I
took this thread as raising the issue that there needs to be an effort
that specifies how to avoid dmarc report loops.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc