Comment by panny
8 days ago
>Update CAN-SPAM for one-click deletion of email addresses from databases.
Then how can I know not to send you another email if I don't have your email flagged in my database to do-not-send?
8 days ago
>Update CAN-SPAM for one-click deletion of email addresses from databases.
Then how can I know not to send you another email if I don't have your email flagged in my database to do-not-send?
You delete the rest of your spam database and replace it with `fn can_send_spam(_: Email) -> bool { false }`. You delete the "can we spam you" checkbox from your checkout page and replace it with "return false".
For legitimate newsletters and similar: you delete any and all forms that allow signing up to receive emails without affirmative consent from that email address that they want to receive mail, and you offer a one-click effective-immediately "unsubscribe" to retract that consent at any time. Then, you can tell if you can send someone mail based on whether they're in your database of people who have explicitly consented to send you mail, and you don't ever send email to anyone else other than one-time consent requests and order-confirmation-style transactional mail.
The only legitimate database of emails is "these people have explicitly confirmed to us that we can email them"; any other database is radioactive waste, delete it.
>The only legitimate database of emails is "these people have explicitly confirmed to us that we can email them"; any other database is radioactive waste, delete it.
That's not actually how HIPAA compliance works. You're required to keep 7 years of communications, and part of those communications is who you sent it to. Amazon SES sends complaint notifications and you're not allowed more than 1 complaint per 1000 emails or they shut you down too. People who are repulsively anti-spam have ruined email as a medium.
I'm merely pointing out the technical aspect of this bill is ridiculous and everyone sending transactional emails will fight you, killing any bill you might have.
> People who are repulsively anti-spam have ruined email as a medium.
That is a ridiculous attitude. Spam has ruined email; anti-spam is the attempt to keep it usable. Anti-spam wouldn't be needed in the first place if not for spammers.
> Amazon SES sends complaint notifications and you're not allowed more than 1 complaint per 1000 emails or they shut you down too.
Good, that sounds like a reasonable step.
Now if only there were existential-level fines for sending spam, too.
Yes, I am aware of people who use the "report spam" button because they can't be bothered to hit "unsubscribe". Which wouldn't be as much of a problem if 1) they felt like they'd subscribed in the first place, rather than being tricked by a default-to-spamming "do you not not not want us to not spam you" checkbox, 2) spammers didn't act like having an "unsubscribe" link was all they need to do to make it okay to send unsolicited commercial email, and 3) unsubscribing reliably worked.
> transactional emails
Transactional emails have never been the problem. People buying lists of emails and sending email marketing spam and trying to defend that as in any way a legitimate practice have always been the problem, along with phishing, scams, etc.
1 reply →
Wouldn't a hash work great for this purpose? I.e.
1. User requests for email alice@example.com to be removed from database
2. Company removes "alice@example.com" from 'emails' table
3. Company adds 00b7d3...eff98f to 'do_not_send' table
Later on, the company buys emails from some other third-party, and Alice's email is on that list. The company can hash all the email addresses they received, and remove the emails with hashes that appear in their 'do_not_send' table.
You'd have to normalize the emails (and salt the hashes), but seems doable?
No need to salt individual hashes, just one hard coded salt for all.
So in the end, they have a list of emails that match the hashes in their blacklist? What's the point?
Any entry that matches a hash needs to be deleted. The point is presumably to minimize the retention of PII.