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

[Alessandro Vesely <[e-mail]>]

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 gov.uk, 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 
> google.com 	61,363,605 
> Yahoo! Inc. 	18,876,201 
> Mail.Ru 	699,554 
> sercoglobal.com 227,587 
> AMAZON-SES 	178,262


That is at odds with the order reported by dmarcian:

NetEase (163.com, 126.com, yeah.net)
Google *
Yahoo!
Microsoft
AOL
cisco Systems
DHL
Comcast *
Tencent (qq.com)
Mail.ru
... https://dmarc.org/stats/dmarc-reporting/
(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 
> google.com 		23,745 
> Yahoo! Inc. 		1,060 
> emailsrvr.com 		64 
> dev.johnlewis.co.uk 	37 
> bridgend.gov.uk 	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...  Mail.ru reports seem to be missing from non-existing domains.  My experience differs slightly.  Yesterday I sent a few messages to mail.ru.  Five of them from a nonext domain (IP 5.170.8.66), 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?


Best
Ale
-- 

--- 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: tana.it; DKIM: relaxed; SPF: relaxed; policy published: none none 100

Relaying IP	message count	reason and disposition	From header (opt. envelope)	SPF	DKIM
http://www.tana.it/lookup.php?host=5.170.8.66" rel="nofollow">5.170.8.66	1		nonext.tana.it	me
http://www.tana.it/lookup.php?host=5.170.8.66" rel="nofollow">5.170.8.66	1		nonext.tana.it	tana.it
http://www.tana.it/lookup.php?host=82.195.75.100" rel="nofollow">82.195.75.100	7		tana.it	lists.debian.org	tana.it
http://www.tana.it/lookup.php?host=62.94.243.226" rel="nofollow">62.94.243.226	1		tana.it	tana.it	tana.it

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

This is an aggregate report from Mail.Ru.

--- End Message ---