Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

Alessandro Vesely <> Tue, 16 July 2019 14:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E24B12061C for <>; Tue, 16 Jul 2019 07:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Status: No, score=-4.299 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 Um7-RE-geRqb for <>; Tue, 16 Jul 2019 07:53:24 -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 79FD712064D for <>; Tue, 16 Jul 2019 07:53:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=delta; t=1563288787; bh=ZBabvkqn06BrLanNkZe6KDhDNtPrCJpuX0CVHMP+nH4=; l=10946; h=To:References:From:Date:In-Reply-To; b=BWe7oiLuHtdeQF2cAACiA9wc4W03uU0SeBusjtj5OvlmowZJYKUn2rFuzn24NQim6 lMV3VSrCN6iAA619detmDQQOATGYDbxd2QYO57KT/ZMHTTZ/HrsNE4niny6om/uDFa VYGVDvSk+Llv8bzKHD5ikuub0ffWBwkBwnDBKsswaP2Jv9QdgZ5Et1TGPskf+
Authentication-Results:; auth=pass (details omitted)
Received: from [] ([]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by with ESMTPSA id 00000000005DC07B.000000005D2DE4D2.00005C18; Tue, 16 Jul 2019 16:53:06 +0200
References: <20190713043409.A5EB64A61C0@ary.local> <3017917.gKNyNSpcLf@l5580> <LO2P123MB22851389EC8F8098BD80211CC9CF0@LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM>
From: Alessandro Vesely <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Tue, 16 Jul 2019 16:53:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_north-23576-1563288786-0001-2"
In-Reply-To: <LO2P123MB22851389EC8F8098BD80211CC9CF0@LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM>
Content-Language: en-US
Archived-At: <>
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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, 16 Jul 2019 14:53:27 -0000

On Mon 15/Jul/2019 09:08:04 +0200 Ian Levy wrote:

> Sorry for not contributing more to this thread - please don't take it as any indication of lack of interest. For UK NCSC specifically, I think we'd prefer NXDOMAIN rather than NODATA, given it's more constrained and this is an experiment. My view would be that if we've published a name under, even with no valid (in the eyes of the receiver) associated records, then *someone* is responsible for it and we can go find and educate them. They may even believe they have a valid reason for doing so that may outweigh any email authentication concerns. But there's a conversation to be had. If there's no published name, then there's no-one responsible, so it should default to the top-level policy. 

I agree that np should default to p.  The original wording for sp is also simpler than''If absent, the policy specified by the "sp" (if present) and then the "p" tag, if not, MUST be applied for non-existent subdomains.''  (BTW, mind that "sp" instead of "np" in the new tag's definition.)

> [...] 
> Here's the volume of reports received on our normal DMARC processing chain in January 2019 (noting Microsoft are one of the bigger providers in the UK and *still* don't generate any reports): 
> Reporter 	Total Reports 
> 	61,363,605 
> Yahoo! Inc. 	18,876,201 
> Mail.Ru 	699,554 
> 227,587 
> AMAZON-SES 	178,262

That is at odds with the order reported by dmarcian:

NetEase (,,
Google *
cisco Systems
Comcast *
Tencent (
(That used to be on dmarcian, but couldn't find it any more)

> And here's the volume for the same month for the synthetic DMARC reports : 
> Reporter 		Total Reports 
> 		23,745 
> Yahoo! Inc. 		1,060 
> 		64 
> 	37 
> 	30
> Just from that, it's pretty clear that the synthesized DMARC records are not universally processed, which gives weight to completing this work and starting to try things out. Given the level of inconsistency we see in receiver behaviour, I think it'd be easier to start with NXDOMAIN and see what that actually achieves. 
> I may well be missing something subtle, so please correct me if I've got this wrong. 

Hmm... reports seem to be missing from non-existing domains.  My experience differs slightly.  Yesterday I sent a few messages to  Five of them from a nonext domain (IP, all of which were rejected, two of which were reported in the aggregate report attached.  However risible these numbers may sound when compared to yours, it is clear that not all messages are reported.

It is possible that some cases of non-existent domain are treated as a short-cut, skipping message registration and DMARC verification altogether, even if the reject always came after DATA...  Just mumbling.  Considering that most DMARC packages work as mail filters, I'd expect messages filtered out before will never make their way to aggregate reports.  Is that a DMARC violation?


--- Begin Message ---
Feedback from Mail.Ru

Feedback from Mail.Ru

Id: 68064799912189070641563148800; begin: 2019-07-15T00:00:00Z; end: 2019-07-16T00:00:00Z
Domain:; DKIM: relaxed; SPF: relaxed; policy published: none none 100

Relaying IP message count reason and disposition From header
(opt. envelope)
SPF DKIM" rel="nofollow">" rel="nofollow">" rel="nofollow">" rel="nofollow">

quarantine, reject.
spf: pass, fail, softfail, temperror or permerror.
dkim: pass, fail, policy.

This is an aggregate report from Mail.Ru.
--- End Message ---