Yes, a message can be malicious or unwanted, with or without correct identification. But the two ARE correlated, not independent. Correct identity allows correct attribution of sender reputation. Successful impersonation allows an attacker to obtain more favorable treatment from both the evaluator and the recipient. Finally, there is a subset of spammers who are unauthenticated because they are hasty and sloppy.
Overall, this means that the probability of unwanted mail is higher when the message cannot be authenticated. (But I do not recommend filtering on probabilities.). Malicious email comes from malicious people. When a malicious email is detected, the question should always be, "what identifiers can be used to identify and block messages from this malicious actor?" If you have an hour to spend on locking down your defenses, investugating unauthenticated email is likely to be high payback Doug On Fri, Jul 21, 2023, 2:53 PM Jan Dušátko <[email protected]> wrote: > > > Dne 21. 7. 2023 v 16:34 Murray S. Kucherawy napsal(a): > > On Wed, Jul 19, 2023 at 6:31 PM Douglas Foster < > > [email protected]> wrote: > > > >> I don't take DMARC as a certain result to be used in isolation, but > >> clearly a quorum evaluators do, and hence the mailing list problem that > has > >> caused such consternation. > >> > >> If we want to diminish their numbers, we have to communicate very > >> differently than RFC 7489. > >> > >> My problem with your favorite line is that the domain owner's preference > >> is of no interest to my filtering decision, but the DMARC result is. > >> > > Since even before SPF, people have been looking for a silver bullet to > stop > > spam and phishing. I'm not surprised to hear that there are products out > > there that promise or implement such, despite the specifications not > > actually saying this is a good idea, or even (in DKIM's case, I believe) > > being rather explicit that it isn't. > > > > I don't think anyone is disputing that the DMARC result by itself is not > a > > clear answer about what one should do upon receiving a message. The only > > time you really know something is when DMARC passes, but even that isn't > a > > strong signal about the content of the message. All other answers are > > muddy, and should be treated that way. If DMARCbis needs to make this > more > > explicit, I don't see a problem with doing so. > > > > I think a DMARC-aware product that's reject-on-fail by default has made a > > questionable choice, and not making that configurable is doubly so. > > > > However, I don't think an evaluator should be looking at the "p=" value > and > > then trying to infer anything about the sending domain solely from that. > > This, to me, is crystal ball territory. We should omit it from our > > calculus. > > > > -MSK, participating > > > Although SPF, DKIM, DMARC, and ARC are all intended to protect against > SPAM, it is not possible, as a matter of principle, to protect against > such kind of communications. They will only allow, to a certain extent, > protection against fake emails. But SPAM is junk mail, which includes > official, albeit unsolicited, communications from organizations that > meet the requirements of the technology. It is unethical, but > technically acceptable. > Moreover, the assessment of junk mail is highly subjective, for the > reason I prefer the term accepted censorship. Because censorship is an > intervention that, as a rule, cannot be influenced by the user. For the > reason given, it is not possible to protect against SPAM in its > entirety. These technologies only allow protection against fake mail. > This leads me to the next step, which you may not agree with. If this > technology serves to protect against mail being counterfeited, it can be > argued, with a degree of simplification, that it provides some form of > brand protection. And the methods of brand protection, including the > hardness of the methods used, should be decided by the owner. And the > enforcement of those rules should be ensured by the administrator. Am I > thinking correctly? > > Regards > > Jan > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
