On July 21, 2023 6:53:03 PM UTC, "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? >
I think it is a mistake to consider technologies such as SPF, DKIM, and DMARC as anti-spam. They are a component of spam mitigation, but authentication of an identifier isn't a solution for spam. Meng Wong (for those of you that weren't around, he's the one that synthesized SPF out of previous proposals and was the early leader of the SPF project) used to say that SPF is not anti-spam in the same way that flour is not food. I think that extends to DKIM and DMARC as well. The challenge with the argument that this is brand protection, so the brand owner should decide is that it's primarily the receiver that needs to invest in integrating these technologies into their systems and accept the inevitable support burden that comes with them. The brand owner wants something from the receiver, so it needs to be simple and reliable enough to be worthwhile. SPF includes a policy mechanism so that receivers can reject mail that is not authorized by SPF. Outside of small sites with a lot of control over their mail stream, it's almost never used . It was tried and for large providers with a heterogeneous user base it wasn't cost effective to support due to the number of false positives and the associated tech support costs. DMARC seems to be heading the same way due to domains using p=reject that (at least in my opinion) shouldn't. Since there are no internet police, deployment of these technologies is a matter of incentives. We do protocol design, not economics, so it's a tough problem in the IETF context, but we need to keep it in mind. Getting the incentives right is probably the most important, but least tractable part of this. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
