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 --- Title: Feedback from Mail.RuFeedback 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 5.170.8.66 1 nonext.tana.it me 5.170.8.66 1 nonext.tana.it tana.it 82.195.75.100 7 tana.it lists.debian.org tana.it 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.
mail.ru!tana.it!1563148800!1563235200.xml.gz
Description: application/gzip
--- End Message ---
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
