Synchro

Get a grip. So you would consider twitter and Facebook notifications you have explicitly requested as spam? I also run a social network with 20k users that is equally accessible over web and email, and we have had peaks up to about 4 million messages/month containing nothing but conversations between users, and we run into all these bulk sending issues all the time. Please explain, oh wise one, how is emailing people messages they have explicitly asked for spam?

This is exactly what the list-unsubscribe-post header from RFC8058 provides: https://www.rfc-editor.org/rfc/rfc8058. The unsubscribe button that gmail, Apple Mail and others displays is driven by that; it's not a gmail feature.

Weirdly, if google thinks you're a dodgy sender they won't display the button, which seems counterproductive to me.

Even gmail's own marketing messages (that I never asked for!) end up in my spam folder. If google can't even reliably send emails to themselves I don't know how they expect anyone else to succeed.

One of the key problems is that both gmail and Yahoo UIs actively encourage users to report messages as spam rather than unsubscribing. Yahoo is particularly bad at this; it's common for me to receive spam reports from yahoo on an entirely double-opt-in social site I run. My reaction there is to remove the reporter from all lists because the amount of damage a single spam report can do is immense; a single spam report can block delivery for weeks at a time to the 10k others that legitimately requested messages. Hotmail/outlook/live is much the same in encouraging spam reporting over unsubscribe, however, their penalties are not as excessive as Yahoo's.

None of that seems new. What would be new is if both gmail and Yahoo provided any means of allowing legit bulk senders to actually send properly.

The one-click unsubscribe is from 2017's RFC8058. Everyone that's sending in volume is already doing all the usual stuff - DKIM, SPF, DMARC, matching reverse IPs, etc.

The privacy-first email marketing service I wrote (https://info.smartmessages.net) implements account-wide unsubscribe by default (unsubscribing you from one list unsubscribes you from all). It requires double opt-in, and asks for explicit consent before doing any tracking whatsoever (so no Google Analytics, no cookies, no trackers), which of course is what the (at least EU and UK) law requires. You're not going to see shitty exploiters like MailChimp doing anything like this; abusing your data is just too lucrative.

It's still ridiculously hard to deliver messages at any volume, and there is zero recourse when you are penalised incorrectly. Gmail's spam filtering is just dire - if I send myself an email from gmail, it goes into spam. A large proportion of the spam I receive is sent from gmail.

Google's postmaster tools are a joke. It's entirely normal for them to give you a "bad" spam rating when you have 0 spam reports, 0 auth failures, strict DKIM and DMARC, and every single message has double-opt-in audit trails. This useless feedback makes it very difficult for senders to actually comply with their ever stricter, but ever more opaque requirements.

Proving that subscribers actually want to receive messages from you its difficult. So back in 2017 I wrote an outline proposal https://github.com/Smartmessages/subscriptionproofrfc to create a standard, possibly built on top of DKIM keys, to provide provable subscriptions. This would pretty much solve the entire thing for legit senders, but of course the industry is not really interested in cooperation or complying with any law that might reduce the number of people they send to by even the tiniest amount.

/cynicalrant

That doesn't help - user input is already validated by default in PHPMailer - the problem is that a valid email address can also be an attack string in a shell context, and bugs in PHP make it hard to work around safely.

This is incorrect. Input sanitisation is not the problem here - PHPMailer sanitises and validates email addresses well enough. The problem is that a valid, sanitised email address can also be an attack in an inappropriate shell context. Much as an SQL injection attack string may be harmless in a shell context but lethal in SQL. Also the vuln does not apply to CLI sendmail, only when sending via the PHP mail() function, and it's at least partly due to bugs in PHP itself.

It all sounds very interesting, however, the tone of the web site comes across like some crappy download accelerator. When you follow the "nerdy details" link you don't get anything meaningful, just bland assurances and pretty animations, i.e. entirely non-nerdy. Nowhere do I see basic technical info like "It's a new IP transport protocol used in place of TCP", or "It's compatible with existing networks because...", or "It's (better than|different to) (HTTP/2.0|QUIC|SPDY) because...".

The discussion here, while short, has been much more informative than the site itself. I don't see any good reason to dumb-down the site like that - you're selling a protocol layer, so you're not going to have any non-nerdy customers!

Why are resumable downloads done in that layer? I have no trouble with downloads resuming across network switches when handled by higher-level protocols like chunked HTTP or even FTP.

Similarly, why would you even think about bundling multiple resources in one transfer at that level? Surely that's a higher level thing (like HTTP/2.0), and thus independent of transport? There appears to be a lot of layer-leakage going on - not that it's necessarily bad, but the reasons for it need to be clearer.