Michael,
As someone who did work for an ESP, your bit about the conflict between short term cash flow that a short term customer with some money to spend for a few months and the optimizing for customer lifetime value. That war, or shall I say tension, was always there. I’d imagine the little ESP I worked for was not unusual. That tension must play out many places as the roles and wildly different incentives bake tension right into the cake. On Jul 12, 2023, at 6:33 AM, Dotzero <dotz...@gmail.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
|
