The trouble with text-only email

This is even harder for mail client's that have to rely on a third-party rendering engine for HTML mail, since they don't necessarily have the hooks into the renderer to tell it not to load remote content.

While my surname is pretty uncommon, this account's username is just our first names strung together, so it is not unlikely that someone else has a very similar email address. In fact, it is surprising how much crap I get that is destined to others who, presumably, used the wrong domain. O_o

This address has only ever been given by me to the electric, gas and phone companies; yet, through the years, it has also been included in several mailing lists, including a parents list at a public school 400 km from here and a marketing list at Diners Club, whose messages are clearly destined to current owners of a Diners credit card.

Given this story, and the abundance of NameNumber@gmail.com addresses, I am not surprised that 1) companies want to know if you read their messages; 2) enough people get subscribed to mailing lists by mistake, and report it as spam, to throw a wrench in the filters' classification algorithms.

NOPE. That is not standard.

My email domain is owned by my brother, and he has configured his provider to silently dump unrecognised users.

When I managed a domain ages ago, I configured that to dump all unrecognised users into a single account, used pretty much to just "scan and dump" (when spam volumes were low enough :-)

Cheers,
Wol

Hence I switched to YDNS. I suggest others do also.

What the sender wants in such cases is for the mail client to pull down all those resources dynamically, thus getting the message under any payload size restrictions and also giving them the ability of seeing when you read the mail, plus what you clicked on since the images will also be hyperlinked. This lets them hypothesize/fantasize about all sorts of "insights" they might get your habits without actually having to ask you anything, although you can be sure that these organisations also like to pester you to fill out stupid questionnaires.

As for losing faith in the Web/HTML community, it wouldn't surprise me if this apparent tracking requirement weren't also part of some similar "insight"-mining process where someone at a higher management level in Mozilla is agonizing about "what our users want" while continuing to ignore all feedback that doesn't reinforce their existing notions on the topic.

Sending email that people don't like results in getting labelled "spam". A fraction (but not an insignificant one) of email users mark any email they didn't expect "spam". Even the fact that they've _specifically asked to receive this email_ is something they pay no heed to in adding this label, if on Monday they think to themselves "Oh, I love puppies, I want to read all about puppies" yes, yes please, sign me up to the Puppy Lover mailing list, that doesn't prevent them on Tuesday receiving an email "Dear Puppy Lover, thanks for signing up to read about puppies" and thinking "Ugh, not this" and pressing the Spam button.

If you're big, the receiving side will put up with this anyway, they'll have to accept that yes, 1% (or whatever) of all Puppy Lover emails are labelled spam and (possibly while rolling their eyes) tell customers they're working hard to eliminate spam and thanks for clicking that "Spam" button religiously.

[ This happens for other categories too. The usual thing to do with reports of "phishing" is to thank the customer for being on their guard and re-assure them you take phishing seriously. It's not important whether the email they forwarded is actually a phishing scam, or an advert your agency sent to them, or just a routine email about say, confirmation of delivery of an order they just literally made, just tell them thanks for being such a clever customer who definitely isn't an idiot that doesn't know what "phishing" is. ]

But if you're a bit smaller, what happens is you get blocked as "too spammy" where that turns out to mean "Users are incompetent but we can't be bothered to do anything about that, so instead we're throwing your email in the garbage, too bad".

I know about this because although my employer owns a huge commercial "email marketing" company which falls into that "big" category I run a service for them which mostly doesn't use that company to send email, it sends only actionable alerts to customers who've usually either paid for the privilege of getting these alerts or signed up as part of some sort of premium package (e.g. they have a Platinum payment card and this service was one of the "freebies"), and nevertheless a non-trivial fraction of the alerts are marked as "Spam" by the recipient. Using the commercial "marketing" company (ie people who actually send spam for a living) gets the mail through.

Personally I would suggest we ask the same sites that offer them this "Spam" button to collect and publish lists of these people's email addresses so we can avoid "harassing" them altogether by refusing to let them sign up for anything ever again. It's not really important to me whether they learn anything from the experience, we're all better off regardless.

Most implementations temporarily reject receipt before DATA, but there's nothing inherent in this approach. (See https://tools.ietf.org/html/rfc6647#section-2.5) You might want to process the message so you can apply whitelisting rules, including DKIM exemptions. Too many people disable greylisting because of the delay. If you can hasten delivery of desirable e-mail, fewer companies will disable greylisting.

Maybe it's not common because of weird bugs in Exchange that break redelivery if you reject on EOM. But IME the reason it's not more common is because the server-side frameworks weren't performant enough to handle many late rejections. In particular, it's difficult to design (and keep other engineers from breaking!) a filtering engine that supports inline, streaming processing with the equivalent of "redirect to /dev/null and reject with 451" short-circuiting. Most engines seem to quickly degenerate to slurping in the entire message body into a string in someone's favorite scripting language, which will never scale if you're not rejecting most messages upfront.

I feel like someone at the top completely misunderstands Mozilla's mission.

I don't read it as saying plain text mail is flagged as spam!

Nothing is saying you can't greylist by sending 4xx on the DATA command (after seeing the content and deeming it dubious).

Yes, if only we had a 'pull' system as good as email..

I experimented with using rss2email to read lwn comments in my mail reader a while back.
One problem was that all threading was lost. I thought I should get grumpy at the grumpy editor, but on looking into the details, I discovered that rss had no way to export "in-reply-to" or "references". So I had to keep my gumpyness to myself.

Maybe we could use anonymous-POP as a pull system which supports everything the email supports.
i.e. I connect to the pop server at lwn.net, login as guest/guest, use UIDL to list the uids of the 100 most recent comments, and collect the ones that I haven't seen....

I'm not sure I like that idea much. It means that, if you miss a single email (or read it too late), your mailing list subscription can be lost.

So unfortunately it makes sense to just block a large address subset.

(I saw something similar with IPv4 and /24s; even to this day my IDS logs show that more than one IP in a subnet is typically used at once..)