Hi Pete, On Tue 11/Sep/2018 20:37:45 +0200 Pete Holzmann via dmarc-discuss wrote: > [...] > > 1) Fully compliant. We (or authorized agent) sent it, and all is well > > 2) We sent it but there are one or more compliance issues which may result in > blocking at the recipient end (if we are using strict/reject policies) > > 3) We didn't send it; it was claimed to be from us and somehow still got > through > (e.g. noncompliant forwarding) except for the recipient DMARC check. > > 4) We didn't send it; it was successfully blocked as intended. > > WHAT's THE ISSUE? > > Cases 1 and 4 are obvious and "easy." > > *ISSUE: **/As far as I can tell, reporting systems seem to conflate #2 and > #3./* > > They seem to be unable to disambiguate: > > * We sent it via a forwarder that's noncompliant > * We did NOT send it but it was claimed to be us, and a compliant forwarder > was > spamming.
Define "we". Of course, you need a technical definition, not one that takes into account the maliciousness/ spamminess of senders' purposes. > Both cases show up as "gray areas" in the reporting systems I've tried. > > *WHY I CARE* > > As more and more systems are set up with these standards, I expect there will > be > a LOT more type 3 cases... spam that is sent via SPF/DKIM compliant systems. > > From a sysadmin and even management perspective, it seems vital to > understand > the extent of invalid traffic in our name that is not being fully blocked. Yes, that's what email authentication is all about. You have to tune your systems and educate your users so as to make it work well. > *QUESTION: *Is there a reason why receiving systems can't check SPF on the > originating email source, and attempt at least minimal verification: > - Is ANY email authorized from this source (not just my primary domain > case; > many domains prohibit all subdomain email!) > - Are any IP's in the email headers considered valid sources? Some email filters do check Received: header fields to make conjectures about SPF validity at origin. It is an ill-conditioned practice which the specs strongly advise to avoid: https://tools.ietf.org/html/rfc7208#section-2.5 For convenience, I quote the reasons the above link manifests: o It might be difficult to accurately extract the required information from potentially deceptive headers. o Legitimate email might fail the authorization check because the sender's policy has since changed. Best Ale -- _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
