Michael Schmitt wrote, in part: >Microsoft Exchange has started quarantining too many messages from
>this listserv as "phishing". It is several per day; one day there was 16. My understanding of DMARC is incomplete, but here are some observations. First, one of your examples had a header.from value of COX.NET; the other was LISTSERV.UA.EDU. Those are, like, different, and that field identifies the DMARC policy domain. Now, why one was COX.NET is a mystery to me. If you have the original note, it would be interesting to see the complete headers. My first hypothesis was that because the domains were different, the one note failed because it was subject to different policy: when the COX.NET note came in, your mail system fetched the Cox DMARC policy and failed the note based on that, while it passed based on the UA.EDU (OK, LISTSERV.UA.EDU) policy. However, neither of those domains seems to have any DMARC published! Moving on, I see compauth=fail on the failed note. That field is the "composite authentication" result, and is presumably why it really failed. From https://www.itpromentor.com/anti-spoof-atp/: "Composite authentication" or CompAuth for short, is essentially a confidence score or rating, which is applied to incoming messages. It takes into account the presence of explicit authentication records such as SPF, DKIM and DMARC, however, if no such records exist (or if not all of them exist), Microsoft will also apply some other intelligence, such as sender reputation, sender/recipient history, behavioral analysis, and other advanced techniques which add or subtract from the confidence in whether a message has been spoofed or not. Therefore, it is a "composite" of both explicit and implicit authentication, which determines whether a message is marked as spoofed, ultimately. The way I think about DMARC (and compauth, as part of DMARC) is that it's kinda sniffing the note: "Hey, does the alleged sending domain have SPF info? DKIM? Do the headers all match?" - it's sort of like Bayesian spam filtering, only based on a combination of headers and external information. So it's like you judge your daughter's boyfriend based not on what he says (Bayesian content filtering) but on how he looks AND what others say about him. When you ask around and nobody's heard of him, you have no information-but that's a sort of information in and of itself. OK, I've tortured that metaphor enough! I'm surmising that listserv.ua.edu does not have a bad reputation, but cox.net does (or at least, a worse one). Which makes sense: while ua.edu has students, and we know what THEY'RE like, they're unlikely to be spoofing/sending from listserv.ua.edu. But Cox has lots of customers, some of whom are going to be spammers. Any ISP has an intermittent reputation problem in terms of spam. And ISPs are going to find it hard to turn on DKIM, since they has no control over the sending clients (which must put the DKIM signature in the outgoing notes). You also wrote: >On the other hand, messages I send to the server have mixture of pass >and fail, and they aren't getting quarantined. "to the server"-to the list? To some other server? Not clear. https://dmarc.org/overview/ is the canonical reference; https://datatracker.ietf.org/doc/html/rfc7489 is the primary RFC; and https://www.valimail.com/blog/understanding-email-authentication-headers/ seems pretty good, too. I think the real key here is understanding where that COX.NET note came from, since that's the problem child. Headers from other failures would be interesting, too. Are others seeing this problem? I'm not, but my mailboxes are hosted at Cox. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
