As we’ve learned very clearly over the last 20 years of commercialization of spam, that never works. The only tractable way to fight fraud and abuse is to impose cost.

The massive prevalence of physical junk mail would refute your argument that even a significant per message cost would dissuade abuse.

Scope and scale is important here, the amount of junk mail from business interests outside of my immediate region is not very high. If physical mail were free and you could send it from anywhere in the world, junk mail would be so much worse than it is. You couldn't run a lot of internet scams at the costs of physical mail and be profitable.

Probably not because even if the postage is free the paper, printing, envelopes, etc. are not.

How many pieces of physical junk mail do you get per day? Now how many spam emails do you get per day? Include the stuff that lands in your spam folder, because we're talking about cost to send junk mail here.

I'm willing to bet the latter is much, much higher. It certainly is for me.

I disagree. Email has SPF and DKIM an what have you exactly because client side filtering doesn't work right. Mail gets dropped beforr the clients even get a chance to run filters.

That's not to say that requiring remote attestation or blocking third party clients entirely is proportional, but Apple should (and does) play a role in spam prevention.

SPF and DKIM are ways of signing a message, but it's still typically up to the recipient or the recipient's mail server to decide what to do with that signature. And they're only checkable on the recipient's mail server because email isn't properly end-to-end encrypted, and exposes metadata.

SPF and DKIM can be checked client side no problem, assuming your mail server doesn't mangle the received-from headers. We just generally only use them as server-side filtering.

That's a brief statement which makes me think I'm missing something obvious, but it doesn't seem obvious to me. Would you please expand on that?

I think it's a bad idea to lock out unattested clients, and as long as third-party clients are accepted, spam will always be sendable. If you're not doing end-to-end encryption, you can catch it at send time by having the server reject the client for sending spam. If you're doing end-to-end encryption, the only options are the sender or the recipient, and attempting to block it at the sender would require prohibiting interoperability.

While I love the principle of accepting third-party clients, Apple clearly doesn't which make this argument fairly non-compelling for them.