I love the idea of the Gmail unsubscribe button, but unfortunately I can't bring myself to use it.
The issue is that there are good-faith and bad-faith unsubscribe links. Clicking the unsubscribe button can thus either have a good outcome (less junk mail) or a bad outcome I ardently want to avoid (letting a spammer know my address is active).
I'm sure Google knows this and does some verification and detection to try to prevent that bad outcome, but as an end user, I don't have much visibility into how well that works. It's a hard problem, but Google is smart, so it's possible they've solved it, but I don't really know whether they actually have.
So in practice, I always read over the email in question carefully to try to judge for myself whether it's safe to click the unsubscribe link at the bottom. It's annoying, but the effort seems worth it.
AFAIK, Gmail doesn’t show it for all senders (2009):
> This only works for some senders right now. We’re actively encouraging senders to support auto-unsubscribe — we think 100% should. We won’t provide the unsubscribe option on messages from spammers: we can’t trust that they’ll actually unsubscribe you, and they might even send you more spam. So you’ll only see the unsubscribe option for senders that we’re pretty sure are not spammers and will actually honor your unsubscribe request.
PSA that there was a sort of "email 2.0" spec called "Internet Mail 2000" (which gives you an idea of how long ago this was, heh) by djb, that would have partly eliminated all this crap. The idea is that you can pay the cost of read receipts (which are kind of a superset of what you are concerned about) to structurally disadvantage spamming so much (by forcing it to tether itself to DNS) that it ceases to be a viable marketing model; spam that is big enough to generate revenue is also either big enough to be caught or spread out enough among new domain registrations that the cost easily swallows the revenue. The struggle is that nobody likes read receipts, so one is stuck trying to define some sort of "halfway between" system to try and invalidate the read receipts, "sometimes you have to store the message until the person wants to read it, but sometimes Gmail will download it before the person reads it, so this signal is unreliable for whether it was actually read."
Isn't that similar to the idea behind hashcash [1]? I don't know -- was hashcash used anywhere? Or were the ideas there leveraged in stuff like DKIM/SPF?
Hashcash is a different idea with the same goal of making certain email behaviors financially infeasible by tying emails to a more limited resource. The limited resource in IM2000 is -- well, that's complicated, I would say internet domains but someone else might say something like network availability. But in Hashcash it is clearly processor cycles.
Hashcash is "used anywhere" in the sense that it's the idea behind bitcoin. There's a duality here where the very introduction of limited scalable resources which makes a cryptocurrency possible, also can be used in a different way to make spam impossible.
In that duality it is actually kind of interesting to think about IM2000. One would imagine a cryptocurrency based on something like "proof of network bandwidth shared" or something, which would be really hard to theoretically formalize. But if you could get a secure definition then that fundamental idea becomes rather explosive. Like I imagine a sort of viral peer-to-peer filesharing network kind of like BitTorrent which would end up as a sort of alternative to the World Wide Web; whereas there are huge clusters of bitcoin miners right now trying to chug out more proofs-of-work, in that situation you would have large numbers of proxy hosts trying to mirror more and more files online.
Right now it would be possible to do some really nasty things to bitcoin by designing software which stores arbitrary files in the spare bits in the ledger. If that software becomes really widespread then inevitably someone uses it to upload MP3s or, worse, illegal pornography and those things get ossified into the Bitcoin ledger and you cannot remove public access to that content without taking down the entire blockchain; probably what happens in practice is that the sharing software itself gets demonized as "only pirates/perverts use that sharing software." But one is immediately confronted with concerns about "hey if I download the blockchain am I technically performing an illegal action" to which the legal answer is probably "yes" at that point. The law doesn't usually care about whether you need sophisticated software to decode that crap.
If you had a cryptocurrency that was based on "I hosted and transmitted data, but I don't know what that data was" then I think you would have a sort of robustness to the network, maybe, where the offending data is not in the ledger. With that said, probably it gets a similar stigma as "only pirates/perverts use that, all the rest of us use the web."
I mean in his defense, DJB has some serious chops that others have lacked, including writing what was at one point the most popular DNS server for anyone who cared about security as well as the first MTA which cared about security while transmitting email, and now two of the more popular stream ciphers, one of which underlies the current fastest secure hash function.
IM2000 probably would have succeeded if it had gotten the attention from him to go past a random idea into a well-specified protocol with a canonical implementation. Standards work is hard!
>or a bad outcome I ardently want to avoid (letting a spammer know my address is active).
Honest question- why does this really matter? Or at least matter to any degree where you would rather have more junk mail than potentially stop spam/undesired emails.
If a spammer sends out 1000 emails and gets 100 bouncebacks.. then they keep on sending to the other 900. You are one of those 900 and you click unsubscribe.. sure, they can detect that your email is active. But are they really going to stop sending to otherwise? It's not like people are constantly changing email addresses these days.. if I were a spammer and I had a valid list, I would basically assume that's a valid email if I don't get a bounceback.
So I just don't get how detecting that someone attempted to unusbscribe is that much of a 'tell'.
A number of years ago there was even a story about someone going undercover at a spamming operation and one key takeaway was that - at least at that place - the boss was very clear internally about actually removing people who tried to unsubscribe.
I cannot vouch for the story but it looked as legit as the average HN story back then so it might be true (or not).
I can believe that- otherwise why would you try to continue to scam/spam someone over email who is clearly trying to unsubscribe.. meaning they realize it's spam/scam.
The goal is to find people who don't know any better..
Last I worked on email delivery, every major email provider but Gmail runs a program for automatically letting emailers know when the spam button is pressed. Gmail is fairly unique in that they require the user to consent to it.
Not to mention the unsubscribe doesn’t make it clear if it’s removing from this list only or it’s indicating to the upstream server the email address forbids contact. I would presume the former, but I would strongly prefer to be able to choose at unsubscribe time, or failing that assume I forbid contact.
The issue is that there are good-faith and bad-faith unsubscribe links. Clicking the unsubscribe button can thus either have a good outcome (less junk mail) or a bad outcome I ardently want to avoid (letting a spammer know my address is active).
I'm sure Google knows this and does some verification and detection to try to prevent that bad outcome, but as an end user, I don't have much visibility into how well that works. It's a hard problem, but Google is smart, so it's possible they've solved it, but I don't really know whether they actually have.
So in practice, I always read over the email in question carefully to try to judge for myself whether it's safe to click the unsubscribe link at the bottom. It's annoying, but the effort seems worth it.