I am not proposing a list. I said that the contents of the list are local policy. But the examples that I gave are examples that must be handled by anyone who attempts to implement DMARC. By failing to discuss them, we leave each new system administrator to discover the problems on his own. Senders in each of my listed categories violate DMARC, but I still need some of those messages.
No question that Sendgrid.net has been a terrible spam source, much of it criminal, although they seem to have improved this calendar year. However, I don't worry about impersonation of the From address, and therefore about DMARC, because they have powerful business incentives to identify their clients correctly. If they send a message from <aoluser>@ aol.com, I am willilng to believe that the address is correct. Whether the message is ma;icious or unwanted is an independent decision. For Sendgrid, I do a three-way split based on From address - known bad are discarded, known good are accepted, and unknown are quarantined. I have a couple of email service providers that only seem to send unwanted advertising. I would love to block them completely, but I cannot predict when a legitimate sender will make a poor choice of vendors. I have to monitor their traffic for wanted senders, even if I am yet to see a message that I actually want.. :Like Sendgrid, administrative quarantine is my solution. But i had to learn all this on my own, because there was no best practices document to guide me. Doug On Thu, Aug 11, 2022 at 12:26 PM Murray S. Kucherawy <[email protected]> wrote: > On Thu, Aug 11, 2022 at 4:50 AM Douglas Foster < > [email protected]> wrote: > >> You say we need to preach at domain owners to lower defenses on 100% of >> their mail because one or more unthinking evaluators may do something >> foolish with a small percentage of their mail. >> >> I say that we need to preach at evaluators to not make foolish unthinking >> decisions. >> > > The rollout of DKIM to the world taught me that the more thinking an > operator needs to do, the less likely this is to be deployed quickly or > correctly. > > >> I say that DMARC is oversold because "reject" is the wrong assertion, >> although we are stuck with it for historical reasons, All that "p=reject" >> can mean is that "I believe all of my in-house mail is dual authenticated >> at origin and all of my service provider mail is DKIM signed at origin." >> The domain owner cannot assert anything more than he knows, and this is >> all that he can know. >> > > I disagree. A domain owner can know, for instance, that it only sends > transactional messages that have no purpose to ever go to a mailing list. > Such an operator can safely set "p=reject" because the risk of the > collateral damage about which we're concerned here is close to zero. That > is equivalent to the domain owner knowing not only that there's dual > authentication, but also that authentication is highly likely to survive to > delivery. When users are introduced into such a system, that logic goes > out the window. DMARC is arguably not appropriate for those use cases, and > Barry is urging that we say so. > > >> A large number of message sources can be trusted as impersonation-free >> because of the source, either the Mail From address or the server >> identity. This includes email service providers ,like >> ConstantContact.com and SendGrid.net, mailing list providers like IETF.org, >> outbound filtering services like ProofPoint and Mimecast, and necessarily >> trusted organizations like the U.S. Government. Some of these will >> actually violate DMARC, but all of their mail can be trusted as >> representing the true author. The specifics of these trust decisions are a >> matter of local policy, but identifying the ones that an evaluator will >> trust is a necessary part of any DMARC implementation. (And providing the >> appropriate exception mechanisms is an implied requirement for software >> developers.) >> > > Who has that list? Who keeps it up to date? How do you know it's > complete, at least enough for all your users to be happy? Would you trust > someone else's list? > > I'm not sure I'd trust even the list you just gave me given the number of > spam messages I get via SendGrid, for example. > > -MSK >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
