On Wed, Jul 12, 2023 at 6:47 AM Scott Kitterman <skl...@kitterman.com> wrote:
> It's not news that there's a risk for SPF associated with shared IP > addresses. > That's why it's in RFC 7208 (11.4) and was in RFC 4408 similarly before. > +1 > > I understand your view and agree on the problem. I also sympathize with > the > need to technically address conditions as they exist in operations. I'm > not > convinced that we should bake the solutions into protocol, however. > > As I've said before, I think this is primarily and economics/incentives > problem, not a technical problem. If you increase the incentives for > third > party providers to support DKIM in place of SPF, I don't think you've > actually > solved anything. > The reality is that many ESPs have asked "how does DMARC fit into my business model?". My response has always been that it is not up to the community to figure out your business model. > As fas as I've seen, the low cost (for a third party to sign using their > customer's domain name) approach is for the third party provider to > publish > DKIM key records based on their own private keys and then tell their > customer > to put a CNAME in their DNS that points to it. In the case of a shared > server, the third party provider then needs to keep track of which > customer is > authorized to sign for which d= domain, but they can use their own keys/ > infrastructure for doing so. > That is one approach. We used to delegate subdomains and contractually require key rotation, etc. We did that after 2007 (due to Storm Worm), well before DMARC was published. There were ESPs that balked at signing with our keys and they were not considered as potential vendors. There were others that worked with us and also provided dedicated IPs that were shared among our various brands (for SPF). Many folks lag behind because they perceive the "cost" of security as higher than the cost(s) associated with the consequences of poor practices. A slightly more complicated approach would be for the domain to provide private signing keys to the 3rd party. > > The internal management function of keeping track of which customers can > use > which signing domains is essentially the same as the internal management > function of keeping track of which customers can use which Mail From > addresses > with SPF. > > My speculation (and it is that), is that the most cost sensitive third > party > providers currently use SPF only and are less likely to keep effective > control > of which customer can send from which identity precisely because it's less > expensive. If you change the deployment incentives so that DKIM is now > more > necessary for some of their customers, they'll no doubt deploy it, but > without > better internal controls, you'll end up with the same problems with these > providers expressed through a different technology. > In some ways, receivers/mailbox providers enable the bad practices by accepting problematic email because that requires less work in dealing with the ISP Relations people from those mailers. As a sidenote, one need only look at the ratio of deliverability people to compliance people at some of these organizations to understand priorities. A harder line would force those mailers to reevaluate their practices and offerings. This is an operations/implementation problem and not so much a protocol/standards problem. Just saying. Michael Hammer
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
