Or a timeout (distributed systems 101). Just time-out accounts and send a good-bye email that has a one-click reanimation link.
"an acceptable compromise has been found, and the text-only option will remain. But, once a year, those subscribers will get a message asking them to click on a link to confirm their continued interest in remaining on the list. That should allow Mozilla to prune its inactive readers"
So that's exactly what Mozilla actually ended up doing.
If the email account is dead, sender (Mozilla in this case) will get an error reply such as "550 No such account", etc. When that happens, obviously, Mozilla should stop sending to that account.
If I legitimately want emails from you (Mozilla seems likely) and you stop sending them, I'm going to be irritated. But if you stop because your phone home 1x1.gif doesn't load, that doesn't mean I wasn't reading them.
Mozilla is probably in a bit weirder position because their value-prop isn't in curating articles and videos the user is interested in. They don't require the users to login to use Firefox, and thus can't know if text-only users are using their emails unless they process unique ids on links inside the email (and that's the last step of the usual funnel, which means the segment definition is going to have to be really long (probably a year)).
https://www.example.com/foo/bar?blah_id=123456&utm...
I am using mutt to read emails and vim to write them, I'd be very surprised if copy/paste has any effect for you.
Is this maybe some gmail thing? I can't think of mechanism that makes copy/paste trigger this.
I suspect the phrasing was used since the discussion is about text-only email and, this being Hacker News, someone might have nit-picked that they view plaintext emails in a mail user agent program which does not scan for strings matching the format of a URL and offer a direct way to click on them or otherwise trigger automated opening of them in a Web user-agent program, and so the person who wrote "copy/paste" had to avoid saying "click on the link".
BTW the OP said "dead", not "inactive but still open"
All they need to do is internally maintain a list of dormant accounts (as defined by not connecting to read email in some period of time); send a series of warnings to those accounts; stop accepting email for those accounts; at some point, delete the accounts and let mail bounce. Document the policy and the timeline.
What am I leaving out? Oh, forwarding accounts. Let the user mark them as forwarding accounts and change the "dead" heuristic to spot when all mail sent by the account's rules is bouncing.
I suppose that might cut the statistical boasting a bit (12 billion active users!) but at this point nobody has any sympathy for marketing departments anyway.
There’s a category of bulk mail that isn’t spam, but isn’t read. The providers punish those mailers who overload on those unread messages.
It's apparently impossible to protect a sender against this by other means than detecting real user interaction. Alternatively, blacklist providers doing this could be ignored...
http://docs.briteverify.com/spamtraps/
Now, keep in mind the source of that information sells mailing list cleaning solutions, and it may be "email marketer" superstition, I don't know.
Maybe they should limit this measure only to receivers which have a known reputation of downgrading senders of unopened mail.
That said, gmail does offer to follow the unsubscribe link for you when you mark an email as junk.
What a sad state of affairs for the Internet in general.
One Mozilla employee, trying to solve a specific technical problem but not necessarily having thought through all the implications of the proposed solution, suggested the "privacyunwise" option on a public mailing list that Mozilla uses for discussing decisions like this. It's a public list because that's how Mozilla prefers to operate.
In the 24 hours that follow, there are 5 responses asking for a clearer description of the problem being solved and why this specific "unwise" option is considered the best solution. Three of those responses are from Mozilla employees. Following this, the author of the original proposal says that clearly more work is needed in terms of solving the particular problem they are facing.
A few days later, there were three more mails objecting to the proposal; two from employees, one from a non-employee.
A few days after that, the original proposal author came back with what you call the "privacywise" option.
So:
1) The "privacyunwise" option was not _chosen_. It was _proposed_, on a list specifically designed to evaluate the sanity of such proposals. This list happens to be public, which is why you know that the option was considered at all before being discarded as not compatible with Mozilla's principles.
2) The "uproar" was largely, but not entirely, by Mozilla staff.
The "Bad Mozilla" conclusion can only be based on a misunderstanding of what happened here...
Disclaimer: I work for Mozilla, I saw this thread; I did not reply to it because other people got there first and I would just be repeating what they said, but had they not replied I most certainly would have.
[1] https://groups.google.com/forum/#!msg/mozilla.governance/WWK... and following thread.
So my guess is that this particular kind of subscriber tracking is not used all that much (on technical mailing lists).
If that's true - it's a problem with the companies we've collectively chosen to outsource email reputation to - not with people who want to receive plain text email.
It becomes a problem when you pump lots of email into a good sized provider, and your open rates are poor. Google knows more about what mail you read than you do.
That way, it's on the user to remain active. If they don't click the link?
So sad but sayonara.