Email doesn't suck – it's email clients that need improving(wired.com)
wired.com
Email doesn't suck – it's email clients that need improving
https://www.wired.com/story/email-clients-are-bad-so-use-vivaldi-mail/
365 comments
I am happy to deal with the spam problem (through appropriate use of spamassassin content scoring, and RBLs and spamassassin DKIM/SPF scoring) on my own smtpd in exchange for the great advantage of having a truly decentralized communication method that isn't controlled by any one company.
My email works as long as I keep my domain name renewed and my personal postfix+dovecot server online and running properly.
Nearly every other possible asynchronous, text based two way communications system that people say is a "possible replacement for email" requires centralizing communications through something run by some specific company.
Email's great advantage is that it's a truly level playing field. Yes that also allows spammers to send outgoing shit smtp traffic, but I can deal with that.
If you are greatly troubled by spam and it's an actual ongoing problem in your inboxes I would say that your inbound smtp content filtering and spam scoring is not set up properly.
My email works as long as I keep my domain name renewed and my personal postfix+dovecot server online and running properly.
Nearly every other possible asynchronous, text based two way communications system that people say is a "possible replacement for email" requires centralizing communications through something run by some specific company.
Email's great advantage is that it's a truly level playing field. Yes that also allows spammers to send outgoing shit smtp traffic, but I can deal with that.
If you are greatly troubled by spam and it's an actual ongoing problem in your inboxes I would say that your inbound smtp content filtering and spam scoring is not set up properly.
> Email's great advantage is that it's a truly level playing field. Yes that also allows spammers to send outgoing shit smtp traffic, but I can deal with that.
Agree so much.
I really don't get the spam complaint anymore. Commercial providers like gmail do get a lot of spam (I have a gmail account as well, it gets more spam than ham) but it doesn't need to be that way.
I run all my own email infrastructure and spam is a non-issue. My primary email has been around very publicly since the mid-90s and is surely on every spam list ever but between a strict postfix configuration and a bayesian spam filter, spam is not a thing anymore.
I'm trying to think the last time I got a spam email in my inbox and can't remember. It's so rare.
Agree so much.
I really don't get the spam complaint anymore. Commercial providers like gmail do get a lot of spam (I have a gmail account as well, it gets more spam than ham) but it doesn't need to be that way.
I run all my own email infrastructure and spam is a non-issue. My primary email has been around very publicly since the mid-90s and is surely on every spam list ever but between a strict postfix configuration and a bayesian spam filter, spam is not a thing anymore.
I'm trying to think the last time I got a spam email in my inbox and can't remember. It's so rare.
[deleted]
While I mostly agree, I'm not sure it's possible to set up spam scoring properly. Either spam gets through, or some non-spam doesn't.
There's legitimate email that consistently gets marked as potential spam, and I don't know how to tell my mailreader to always trust that source. The tax service regularly mails me that there's a new message for me in my message box at the tax service site where I need to log in, which is a terrible way to communicate. Their paper mail does contain everything I need to know, but their email cannot because email is so insecure.
Something like email, but with authentication and encryption built in from the start, would be a really nice improvement.
There's legitimate email that consistently gets marked as potential spam, and I don't know how to tell my mailreader to always trust that source. The tax service regularly mails me that there's a new message for me in my message box at the tax service site where I need to log in, which is a terrible way to communicate. Their paper mail does contain everything I need to know, but their email cannot because email is so insecure.
Something like email, but with authentication and encryption built in from the start, would be a really nice improvement.
I’ve never understood why I can’t optionally log in to my bank/hospital/tax site and upload my pgp key so that all communications from them are encrypted?
Inability, lack of willingness, lost ability to claim the customer screwed up, pick one
If anything they'd do S/MIME, but they often can't even get DKIM right. Maybe in the future.
Spam is not Email's fault, but the mere result of its success/importance, which has only been possible due to its interoperability, which in turn facilitates spam.
It would be the same if we had all been using - say- XMPP for the last 20 years.
It would be the same if we had all been using - say- XMPP for the last 20 years.
Spam is totally email’s fault. They should have had disposable email addresses built into the protocol so they would be easy to support. Then when an address starts getting spam, run the spam filter more aggressively on emails to that address or block it entirely. Or they should have included PoW so it takes a little bit of CPU time to send an email (wouldn’t do anything about botnets, but not every spammer has a botnet handy.) I can’t think of any other ideas off the top of my head, but it’s absolutely true that there are ways that email could have been designed to be less of a problem
Ultimately e-mail is a relic of a time when there was some level of trust (however small) among Internet users.
It's always going to be a bit of an awkward fit to today's Internet where you can trust that any and every exposed service will face some attempt at abuse.
It's always going to be a bit of an awkward fit to today's Internet where you can trust that any and every exposed service will face some attempt at abuse.
DKIM, SPF, DMARC... old tech and it just got reactivated recently. Will take a time to spread.
On the other hand people might want to keep pseudonymous and throwaway mails. Nearly the exact same warnings apply here as they would have applied to those that chose Google as a mail provider and now complain about lacking support and account closure. A largely self-inflicted problem. Don't continue this naivete...
Spam is annoying, but not a threat. Phishing is to a large degree. That needs user training, people stopping to pay ransoms and sensible IT policies for corporations.
On the other hand people might want to keep pseudonymous and throwaway mails. Nearly the exact same warnings apply here as they would have applied to those that chose Google as a mail provider and now complain about lacking support and account closure. A largely self-inflicted problem. Don't continue this naivete...
Spam is annoying, but not a threat. Phishing is to a large degree. That needs user training, people stopping to pay ransoms and sensible IT policies for corporations.
I mean, with the networks and processing speed of computers back when email was standardized, sending the email itself would be proof of work, no?
Getting a PhD would have been the work required to get an email
address so yes! Then eternal 09/ happened.
Proof of Stake as an accepted delegator to a university/government SMTP validator node.
Less email as proof of work than having a known network address (this was when the hosts file was distributed manually, and bang paths were common) was proof of trust.
There were from a few dozens to a few hundreds of hosts on the entire network at this time. Most were educational institutions, meaning a campus sysadmin could run herd over users (if students) or refer to deans / departments (faculty). This from the 1970s through the early 1990s, at which point things began evolving rapidly.
Transacting email itself wasn't all that expensive, though for many sites it was batched via uucp or similar mechanisms.
There were from a few dozens to a few hundreds of hosts on the entire network at this time. Most were educational institutions, meaning a campus sysadmin could run herd over users (if students) or refer to deans / departments (faculty). This from the 1970s through the early 1990s, at which point things began evolving rapidly.
Transacting email itself wasn't all that expensive, though for many sites it was batched via uucp or similar mechanisms.
Isn’t it just how you handle mailboxes. Let [email protected] accept and receive email at any [email protected] address with ability to block any specific address getting spam.
If the friends and family address gets spam, offer a way to create and distribute a new address.
For business it is tricker as you want anyone to email you. Here regular antispam measure are probably best.
If the friends and family address gets spam, offer a way to create and distribute a new address.
For business it is tricker as you want anyone to email you. Here regular antispam measure are probably best.
I suppose I agree for the narrower claim that a protocol which allows anyone to message anyone is going to inevitably have spam.
That said I can count on my fingers and toes the number of spam messages (via hijacked accounts) that have reached my Facebook Messenger/Instagram inboxes and have received zero spam in several years on Snapchat.
Walled gardens have many downsides, but there are upsides as well.
That said I can count on my fingers and toes the number of spam messages (via hijacked accounts) that have reached my Facebook Messenger/Instagram inboxes and have received zero spam in several years on Snapchat.
Walled gardens have many downsides, but there are upsides as well.
You don't get spam on Snapchat? I think you might define it differently than I do. Since those walled gardens have a verification step before allowing sending messages, spam on those platforms consists of "friend requests" from unknown people. If one is foolish enough to accept one of those, the more traditional spam message soon follows.
So yes, most walled gardens' two-step approach makes the spam more civilized, but they don't eliminate it.
So yes, most walled gardens' two-step approach makes the spam more civilized, but they don't eliminate it.
Not a single one! I suppose I occasionally see friend requests from unknown users, but they don't actually convey a message or achieve any possible advertising goal.
That said, I only communicate with a couple dozen close friends on snapchat so perhaps a more active user will get spam.
That said, I only communicate with a couple dozen close friends on snapchat so perhaps a more active user will get spam.
Whether spam is or isn't email's fault, or a consequence of its architectural naivete, is arguable.
What's not arguable is that spam is email's problem.
What responses to my quite off-the-cuff though apparently resonating comment has (mostly) failed to recognise though is that spam is a problem not only for email users but across the spectrum for operators, administrators, senders, application designers, and a whole host of others. The fact, volume, and consequences of spam have a tremendous set of knock-on effects which are hard to express with any degree of coherence and sufficiency.
What's not arguable is that spam is email's problem.
What responses to my quite off-the-cuff though apparently resonating comment has (mostly) failed to recognise though is that spam is a problem not only for email users but across the spectrum for operators, administrators, senders, application designers, and a whole host of others. The fact, volume, and consequences of spam have a tremendous set of knock-on effects which are hard to express with any degree of coherence and sufficiency.
I get spam on Whatsapp, and FB Messenger. Not as much as email but I'm assuming because email is where the spammers are concentrating.
Which system gets it right and could email be fixed?
Which system gets it right and could email be fixed?
Really? I've never had spam on Whatsapp. I was just about to mention it as an example of a very successful service that didn't suffer from spam.
Most WA users I know get it, it's been a point of discussion in several group chats. But not enough you need spam filters, the need for which is the biggest problem with email because of false positives (I scan thru my junk mail folders weekly when I remember and find legitimate messages every time).
Interesting. It goes to show how varied people’s experience can be. I get zero spam on my seven year old Postfix server as long as I have greylisting enabled (my only anti-spam measure) while I get the occasional spam message on Whatsapp (that I only use for work purposes on my work phone since 2020).
I don’t use WhatsApp. I don’t have contacts on WhatsApp. I only registered a username to hold it. I only get spam on it.
Undesired solicitations are going to be a factor on any sufficiently widely-used communications network. There are ways to reduce the impact, but most come down to some measure of real costs (as with postal mail), gatekeepers (as with, say broadcast media --- there's plenty of solicitation but it's at least curated, and no, that doesn't mean I can stand it myself), or systems with strong effective authentication and reputation capabilities, which would include most social networks.
It's trivial to address spam on trivial systems --- those which are small, centralised, and tightly controlled. It's difficult to do so on nontrivial systems --- those which are large, decentralised, and loosely controlled.
Email is very much the latter. It also lacks costs (sending has exceedingly low marginal cost), and has very poor authentication / identity assertion, and reputational capabilities. All of this is baked into SMTP at pretty low levels, and the various bolt-on kludges to address this (SPF, DKIM, DMARC, and anything else that I'm not yet aware of) are at best only partially effective, and rather fragile and fiddly. Among the reasons large monopoly email services are so effective and useful is that they "see" the spam problem at a global level, across hundreds of millions to billions of accounts. My statistical background tells me that this is almost certainly overkill, and that even services with only a few hundreds or thousands of widely-shared known addresses (something easily accomplished by honeypots) would achieve much of their effectiveness.[1]
Another huge problem for email is that there's a lot of loose coupling between end-user clients and servers, especially for desktop-based (non-Web or mobile App) systems. Contrast with social media or webmail in which a person's flagging of an item as spam or abuse is instantly registered by the system, which has full awareness of where the item originated and what other activity has come from that account (or if sufficiently sophisticated, known clusters of accounts) recently. In the case of email, the end-user client, the receiving server, the sending or relaying server, and the original injection point(s) might well be three or four entirely independent systems, for which there's no through chain of identity and often asynchronous hand-offs meaning that flagging actions are noted only long after the message was initially accepted for delivery.
That flexibility was useful early in the history of SMTP's development. It's an Achilles heel now.
One possible reform would be for sender to spool mail until it's been accepted for delivery. This would complicate sending (especially at high volumes, not necessarily a Bad Thing), but would mean that the determination of whether or not a message was spam, or behavioural assessments (e.g., Sender A has requested delivery to 1,000 local addresses, many of which don't exist and/or are honeypots) might permit a presumption of spam before the actual acceptance of the message.
All of which would raise costs to spammers and make use of botnets for delivery far less reliable in that those sending hosts would be identified as spammers before many messages could actually be transacted, assuming that white-hat recipients share reputation data regarding sending sources.
Another practice generally is to have a varying level of service provided based on the level of familiarity, trust, and/or value associated with specific senders. Given weak authentication this is not especially robust, but it would again make simple-minded email blast spamming highly ineffective. This practice has been fairly widely adopted in some forms by corporate domains which require specific whitelisting of authorised senders as a general rule. Implementations last I was aware tended to be ad hoc and kludgey. It's an annoying but reasonably effective method.
________________________________
Notes:
1. The law of large numbers and spam's reliance on broadcast distribution largely account for this. A small number of individual spammers hitting effectively all known email addresses account for a huge proportion of spam. Knocking a single such operation offline can drop global spam. This is a 2008 story in which a single provider accounted for 75% of all spam: <http://voices.washingtonpost.com/securityfix/2008/11/major_s...> . Smaller systems (< 100m accounts, say) might tend to miss more sophisticated targeted attacks and lag in responding to these --- phishing, spear phishing, and APT attempts against specific accounts. I'm not sure if this is a trade-off or not, though I suspect any sufficiently highly-place PEP (politically exposed persons) would attract such attention, and that this risk is not especially scale-responsive. This is also somewhat tangential to spam in the sense of indiscriminate mass mailings, though both are serious concerns for email integrity.
It's trivial to address spam on trivial systems --- those which are small, centralised, and tightly controlled. It's difficult to do so on nontrivial systems --- those which are large, decentralised, and loosely controlled.
Email is very much the latter. It also lacks costs (sending has exceedingly low marginal cost), and has very poor authentication / identity assertion, and reputational capabilities. All of this is baked into SMTP at pretty low levels, and the various bolt-on kludges to address this (SPF, DKIM, DMARC, and anything else that I'm not yet aware of) are at best only partially effective, and rather fragile and fiddly. Among the reasons large monopoly email services are so effective and useful is that they "see" the spam problem at a global level, across hundreds of millions to billions of accounts. My statistical background tells me that this is almost certainly overkill, and that even services with only a few hundreds or thousands of widely-shared known addresses (something easily accomplished by honeypots) would achieve much of their effectiveness.[1]
Another huge problem for email is that there's a lot of loose coupling between end-user clients and servers, especially for desktop-based (non-Web or mobile App) systems. Contrast with social media or webmail in which a person's flagging of an item as spam or abuse is instantly registered by the system, which has full awareness of where the item originated and what other activity has come from that account (or if sufficiently sophisticated, known clusters of accounts) recently. In the case of email, the end-user client, the receiving server, the sending or relaying server, and the original injection point(s) might well be three or four entirely independent systems, for which there's no through chain of identity and often asynchronous hand-offs meaning that flagging actions are noted only long after the message was initially accepted for delivery.
That flexibility was useful early in the history of SMTP's development. It's an Achilles heel now.
One possible reform would be for sender to spool mail until it's been accepted for delivery. This would complicate sending (especially at high volumes, not necessarily a Bad Thing), but would mean that the determination of whether or not a message was spam, or behavioural assessments (e.g., Sender A has requested delivery to 1,000 local addresses, many of which don't exist and/or are honeypots) might permit a presumption of spam before the actual acceptance of the message.
All of which would raise costs to spammers and make use of botnets for delivery far less reliable in that those sending hosts would be identified as spammers before many messages could actually be transacted, assuming that white-hat recipients share reputation data regarding sending sources.
Another practice generally is to have a varying level of service provided based on the level of familiarity, trust, and/or value associated with specific senders. Given weak authentication this is not especially robust, but it would again make simple-minded email blast spamming highly ineffective. This practice has been fairly widely adopted in some forms by corporate domains which require specific whitelisting of authorised senders as a general rule. Implementations last I was aware tended to be ad hoc and kludgey. It's an annoying but reasonably effective method.
________________________________
Notes:
1. The law of large numbers and spam's reliance on broadcast distribution largely account for this. A small number of individual spammers hitting effectively all known email addresses account for a huge proportion of spam. Knocking a single such operation offline can drop global spam. This is a 2008 story in which a single provider accounted for 75% of all spam: <http://voices.washingtonpost.com/securityfix/2008/11/major_s...> . Smaller systems (< 100m accounts, say) might tend to miss more sophisticated targeted attacks and lag in responding to these --- phishing, spear phishing, and APT attempts against specific accounts. I'm not sure if this is a trade-off or not, though I suspect any sufficiently highly-place PEP (politically exposed persons) would attract such attention, and that this risk is not especially scale-responsive. This is also somewhat tangential to spam in the sense of indiscriminate mass mailings, though both are serious concerns for email integrity.
I more or less diagree with you, but the comment was lovely, and for some reason I find myself craving lobster thermidor.
This. I have been facing this issue recently more and more. Account creation emails aren't arriving to my custom domain recently. Some software companies seem to not send emails to custom domains. I use a well known commercial provider with DKIM and everything setup. Yet. I am beginning to use my custom domain only for human communication and all else gets directed into Gmail.
I have zero issues with mail not arriving on my custom .me domain, and I’ve been using it for email for close to 10 years.
Do you have an example of sites where account creation mails do not arrive?
Do you have an example of sites where account creation mails do not arrive?
That yours has existed for 10 years might be helping you, you established some trust/history before the big providers stopped caring about sink holing false positives.
I have never heard of age being important for receiving mail. Sending, yes, as an annoying anti-spam measure, but why would anyone care about it the other way?
Huh—I wonder if that has to do with your TLD? I’ve been using custom domains for a few years and I have more issues with my .xyz domain than I do with my .com for both sending and receiving. Both have all the authentication DNS records set up.
I run my own email server with a custom spam filter that I wrote and one of the things I've done is blacklist certain TLDs that are so spammy that just this one mitigation cuts my spam by >50%. XYZ is one of those super-spammy TLDs, sorry.
Here is the complete list:
'top','tv','biz','rocks','ru','science','bid','date','casa','buzz','xyz','click','online'
Here is the complete list:
'top','tv','biz','rocks','ru','science','bid','date','casa','buzz','xyz','click','online'
I hate you and SpamAssassin. I also completely understand and will probably do the same when self hosting. Sad state of affairs.
No apology needed :) That's why I use the .com for everything serious and I don't have issues sending or receiving with that one.
> Account creation emails aren't arriving to my custom domain recently.
What do you mean by custom domain? Anything not @gmail.com? How could that be, since every corporation everywhere has a custom domain. Must be something else going on.
What do you mean by custom domain? Anything not @gmail.com? How could that be, since every corporation everywhere has a custom domain. Must be something else going on.
> Some software companies seem to not send emails to custom domains.
As someone who operates a SaaS that does auto-block some account registrations based on email address, I feel like I should speak to this. We're actually fine with custom domains — and I imagine this is true for most SaaS companies. All our business customers use custom domains; and we're not about to blow holes in our funnel by making it harder to acquire new business customers. There's no logic in our codebase that especially favors the big email providers; no whitelist with gmail/outlook/etc. on it. (And we haven't found that any of the lifecycle-mail sending services we've tried have had trouble with custom domains, either.)
Instead, what we're mostly trying to stop is registrations using what you might call vanity or proxy domains — domains created by people who are only trying to obscure their real email address, but who aren't willing to invest the effort to make their domain into a "real" domain that has working email deliverability in both directions and maybe a web presence to go along with it.
Businesses almost always have such "real" domains; but people registering for illicit purposes (spamming, ban evasion, etc) almost never do, instead only bothering to set up e.g. an SMTP forwarding proxy that has no ability to originate mail. (Often they get such a service as a value add from their domain registrar; though there are independent services for this as well.)
To detect these, we check things like:
- Is your domain a known temporary email provider? (Immediate fail)
- Is your domain's MX record shared with one used by known temporary email providers? (Also an immediate fail; and zero false positives from this, surprisingly)
- Does your domain have SPF and DKIM records? (Good)
- Do your MX record hostname(s) resolve to the IP ranges of some skeezy VPS host, or to an IaaS's ephemeral-allocation IP ranges? (Bad)
- Does your NS record, or your MX record's NS record, point to a domain registrar that's well-known to be used for discovering + acquiring short nonsense domain names in bulk? (Bad)
- Does your domain have an apex A record? (Good) Is there a website there? (Good) Is that website a domain-parking page? (Very, very bad)
- How recently does your WHOIS record say that your domain was last transferred/acquired? Last 14 days? (Somewhat bad, but not as bad as the other things)
I would guess that if you're having problems, it's with one of these heuristics, or one in a similar vein.
If you jump through all the same hoops a business would jump through to make your custom domain "real", then any heuristics SaaS companies come up with to differentiate business domains from spam domains, should work out in your favor. (My own custom domain — which truly is just a vanity domain — passes all these tests easily; mostly by just doing the default stuff Google Workspace recommended I do when I set it up. Because that's all businesses are doing, too.)
As someone who operates a SaaS that does auto-block some account registrations based on email address, I feel like I should speak to this. We're actually fine with custom domains — and I imagine this is true for most SaaS companies. All our business customers use custom domains; and we're not about to blow holes in our funnel by making it harder to acquire new business customers. There's no logic in our codebase that especially favors the big email providers; no whitelist with gmail/outlook/etc. on it. (And we haven't found that any of the lifecycle-mail sending services we've tried have had trouble with custom domains, either.)
Instead, what we're mostly trying to stop is registrations using what you might call vanity or proxy domains — domains created by people who are only trying to obscure their real email address, but who aren't willing to invest the effort to make their domain into a "real" domain that has working email deliverability in both directions and maybe a web presence to go along with it.
Businesses almost always have such "real" domains; but people registering for illicit purposes (spamming, ban evasion, etc) almost never do, instead only bothering to set up e.g. an SMTP forwarding proxy that has no ability to originate mail. (Often they get such a service as a value add from their domain registrar; though there are independent services for this as well.)
To detect these, we check things like:
- Is your domain a known temporary email provider? (Immediate fail)
- Is your domain's MX record shared with one used by known temporary email providers? (Also an immediate fail; and zero false positives from this, surprisingly)
- Does your domain have SPF and DKIM records? (Good)
- Do your MX record hostname(s) resolve to the IP ranges of some skeezy VPS host, or to an IaaS's ephemeral-allocation IP ranges? (Bad)
- Does your NS record, or your MX record's NS record, point to a domain registrar that's well-known to be used for discovering + acquiring short nonsense domain names in bulk? (Bad)
- Does your domain have an apex A record? (Good) Is there a website there? (Good) Is that website a domain-parking page? (Very, very bad)
- How recently does your WHOIS record say that your domain was last transferred/acquired? Last 14 days? (Somewhat bad, but not as bad as the other things)
I would guess that if you're having problems, it's with one of these heuristics, or one in a similar vein.
If you jump through all the same hoops a business would jump through to make your custom domain "real", then any heuristics SaaS companies come up with to differentiate business domains from spam domains, should work out in your favor. (My own custom domain — which truly is just a vanity domain — passes all these tests easily; mostly by just doing the default stuff Google Workspace recommended I do when I set it up. Because that's all businesses are doing, too.)
Thank you for explaining how this works. Mine is a personal vanity domain with a non .com TLD. But I have the SPF and DKIM setup and I use a well known Google workspace alternative, which I have used for almost a decade now. So ideally I should have checked all the necessary boxes.
I hope, I have stumbled into a couple of services that have some poor email verification implementation and my domain has not been blacklisted by some email protection company or something serious like that.
I hope, I have stumbled into a couple of services that have some poor email verification implementation and my domain has not been blacklisted by some email protection company or something serious like that.
The second worst thing about email after spam, is all the solutions dedicated to fixing spam.
I've had to setup DKIM, update records and keep up with changes to it just to keep my custom domain.
I've had to setup DKIM, update records and keep up with changes to it just to keep my custom domain.
Consolidation of "trusted" mail providers (as if Google is trustworthy with its scanning of mails) is a real threat to federated mail. One can only hope that IT isn't stupid or greedy enough to sell it as that. To forbid the usage of Gmail should be sensible policy for any enterprise.
Spam is a problem, but honestly 15 year old slightly trained spam filter with a sensible config can filter all without any false positives.
Not that mail is not without its problems, but any modern alternative will suck much more. It will be a service attached to a corporation you will again make yourself dependent on. I feel for those whose Google accounts get locked, but to a large degree it is their own fault.
I don't know a lot of corps that block unknown mail servers. Have it sign outgoing mail with your known domains and your mail will not land in some sandbox or spam filter.
Spam is a problem, but honestly 15 year old slightly trained spam filter with a sensible config can filter all without any false positives.
Not that mail is not without its problems, but any modern alternative will suck much more. It will be a service attached to a corporation you will again make yourself dependent on. I feel for those whose Google accounts get locked, but to a large degree it is their own fault.
I don't know a lot of corps that block unknown mail servers. Have it sign outgoing mail with your known domains and your mail will not land in some sandbox or spam filter.
> 15 year old slightly trained spam filter with a sensible config can filter all without any false positives.
If it were that easy why do all the big players do it so badly? I'd rather get more spam in my inbox than miss the false positives (in fact most of what's in my spam folder is technically legitimate, but usually just broadcast emails from organizations I happen to have used my email address for at some point in the past). But I haven't found a way to sufficiently lower the threshold for spam detection for any email service I've used to avoid that problem.
If it were that easy why do all the big players do it so badly? I'd rather get more spam in my inbox than miss the false positives (in fact most of what's in my spam folder is technically legitimate, but usually just broadcast emails from organizations I happen to have used my email address for at some point in the past). But I haven't found a way to sufficiently lower the threshold for spam detection for any email service I've used to avoid that problem.
It isn't easy, big players are doing very well percentage wise.
> To forbid the usage of Gmail should be sensible policy for any enterprise.
Instead, more than 60% of mid-sized companies use Gmail.
https://emailanalytics.com/gmail-statistics/
Instead, more than 60% of mid-sized companies use Gmail.
https://emailanalytics.com/gmail-statistics/
By contrast I've also had email for decades, and suffer effectively zero spam. Perhaps one difference is that I use two emails. One I use exclusively for messaging friends/family and the other I use for everything else. And I don't use the former email on any mobile device either.
The email I use for registering on sites, or using on mobile, is absolutely bombarded with spam. The email I use privately receives near zero spam (that isn't trivially filtered) even though it's a simple and common two word combination at a major mail server. Notably, I'm not registering for dodgy sites or anything like that on the spammed email. It's all major and ostensibly reputable sites. For sites I don't trust or care to receive a message from, I use throw-aways.
I simply assume any site you register on is going to sell, leak, or accidentally expose your email (or any other information you offer them). Similarly for mobile devices. And that seems to be a consistently validated assumption.
The email I use for registering on sites, or using on mobile, is absolutely bombarded with spam. The email I use privately receives near zero spam (that isn't trivially filtered) even though it's a simple and common two word combination at a major mail server. Notably, I'm not registering for dodgy sites or anything like that on the spammed email. It's all major and ostensibly reputable sites. For sites I don't trust or care to receive a message from, I use throw-aways.
I simply assume any site you register on is going to sell, leak, or accidentally expose your email (or any other information you offer them). Similarly for mobile devices. And that seems to be a consistently validated assumption.
Somewhere in 1999 I started using unique email addresses for every single service or registration. For example, if I would register with Reddit today, then I would use [email protected].
This makes it really easy to filter out spam (and I also know who sold my address). It's also trivial to block unwanted 'subscriptions'.
I use Thunderbird and create an identity for every one of these mails that require a reply (most don't) and TB automatically uses the unique address when replying.
This makes it really easy to filter out spam (and I also know who sold my address). It's also trivial to block unwanted 'subscriptions'.
I use Thunderbird and create an identity for every one of these mails that require a reply (most don't) and TB automatically uses the unique address when replying.
The biggest problem of email is non verifiable routing due to header manipulation and lack of source authorization.
If these were in place then it would be able to send all spam back to sender, instead of putting it a spam folder due to filtering, your email client just would send it back to the origin address.
It also would help if each send would cost a token (of some monetary system) that would be returned on delivery at the legitimate destination. This would help against bulk sending.
Email is a system that will always cripple at some point if there aren't real world cost incentives in place.
People are the biggest problem with email, which is hard to solve with mere technical solutions.
If these were in place then it would be able to send all spam back to sender, instead of putting it a spam folder due to filtering, your email client just would send it back to the origin address.
It also would help if each send would cost a token (of some monetary system) that would be returned on delivery at the legitimate destination. This would help against bulk sending.
Email is a system that will always cripple at some point if there aren't real world cost incentives in place.
People are the biggest problem with email, which is hard to solve with mere technical solutions.
If you don't like spam, postal mail is not any better. Worse, really, because there are no automated filters for it. Four out of five trips to the mailbox result in nothing but junk mail.
You forgot about the mess that is SPF, DKIM, and DMARC.
FWIW, I also omitted what's perhaps the most telling sign: increasingly it is not possible to find an email address for an entity or know whether or not a found address is useful or monitored.
That is: organisations are increasingly abandoning email, at least for public-facing work.
Ironically, Google are perhaps most notorious for this (HN is one of numerous Google-email-contact alternatives for problem resolution).
More generally, the end state of any universal communications medium of unlimited reach and access ... is abandonment. Absent some viable mechanism for curtailing usage, the only viable options become either shutting off the system entirely, or at best, randomly sampling from amongst submissions.
Conversation, and communication, both scale poorly.
That is: organisations are increasingly abandoning email, at least for public-facing work.
Ironically, Google are perhaps most notorious for this (HN is one of numerous Google-email-contact alternatives for problem resolution).
More generally, the end state of any universal communications medium of unlimited reach and access ... is abandonment. Absent some viable mechanism for curtailing usage, the only viable options become either shutting off the system entirely, or at best, randomly sampling from amongst submissions.
Conversation, and communication, both scale poorly.
I feel most tech organisations are now using Slack, Discord or Teams. At this point my work gmail is more an auth tool than an email.
Spam, spam, spam, spam, spam, eggs, bacon, spam, and spam.
"but I don't like spam."
Spam is not this big of an issue - filters for it are easily available and work well, even if you host your own.
Your response is essentially "yes it is". Apparently we disagree.
Re: spam - I have given up on my inbox altogether. I found that if there is a really important message that needs my attention, it tends to make its way through other channels (slack, voicemail, people just walking over to me etc).
Rest of it, is apparently not important to make a difference to me in any way.
Rest of it, is apparently not important to make a difference to me in any way.
postal services are awesome but tend to be forgotten. We need to use them more for personal, relevant things. Ideally handwritten.
The contemplative nature of reading paper is a bliss.
The contemplative nature of reading paper is a bliss.
You were a trendsetter back then and are now, I guess.
Part of what makes it worse is that many of the pain points are such low hanging fruit.
Being stuck with Outlook due to corporate inertia, most days i run into simple silly things that have been inconvenient for years:
- non standard shortcuts (what modern windows app doesn't use Ctrl F for Find which you would think would let you search an open email for text except it does something else!
- fragmented unintuitive disttribution of functions over tabs
- remarkably unhelpful use of space in the inbox views, such that columns rarely show enough of what you need to see
- annoying assumptions (eg typing a user name into the inbox search defaults to using From: when i frequently need to search with it as To: when I've got folders of email where I'm a co-recipient and need to search who the mail was address to)
Being stuck with Outlook due to corporate inertia, most days i run into simple silly things that have been inconvenient for years:
- non standard shortcuts (what modern windows app doesn't use Ctrl F for Find which you would think would let you search an open email for text except it does something else!
- fragmented unintuitive disttribution of functions over tabs
- remarkably unhelpful use of space in the inbox views, such that columns rarely show enough of what you need to see
- annoying assumptions (eg typing a user name into the inbox search defaults to using From: when i frequently need to search with it as To: when I've got folders of email where I'm a co-recipient and need to search who the mail was address to)
> what modern windows app doesn't use Ctrl F for Find
For this, in Outlook, the explanation is (per Raymond Chen): Bill Gates
https://devblogs.microsoft.com/oldnewthing/20140715-00/?p=50...
For this, in Outlook, the explanation is (per Raymond Chen): Bill Gates
https://devblogs.microsoft.com/oldnewthing/20140715-00/?p=50...
Thank you for this bit of history! Looks the benevolent dictator wins again.
Not so benevolent at that time :)
Not so benevolent now:
https://pluralistic.net/2022/08/24/waivers-for-me-not-for-th...
Thanks for the informative read. I hadn’t read Cory Doctorow in years but I’ve bookmarked that site.
The Outlook web interface is substantially better than the desktop app at this point for UX
I had an issue logging into my work account on the actual outlook application recently so I tried the web version in the interim and it really is a lot better. I am not saying it is a world-beater but when they couldn't figure out my issue, I just let the ticket close.
I've been using OWA for a while as my primary work email and it's nice. I probably pin too much shit, but it's overall a good app. And since MS is web tech obsessed, OWA will replace Outlook at some point in the future. Project Monarch / One Outlook is still super half baked and predictably an awful RAM hog compared to the native app, but the writing is on the wall.
For this reason, I use OWA exclusively
Still waiting for them to replace the desktop app on macOS with an Electron app. The fact that no mobile/desktop client for Outlook doesn't have the like feature like Outlook Web is frustrating.
Check out the Outlook web interface, it's so much better. They got the navigation delay down to 3-4 seconds! Also they have this safety feature where the delete button doesn't work unless you first archive and un-archive the message. The actual content view gets closer to a third of the screen space too, which is almost enough to load someone's 5 paragraph email signature. Now that's Enterprise Ready!
> - remarkably unhelpful use of space in the inbox views,
I agree with you here. The one time we saw a progression with Google Inbox (which showed cards of events, photo-previews, etc.: https://cdn.vox-cdn.com/thumbor/vRLmb7RDrySSxylcMGIoV7dWTK8=...), it was quickly followed by a regression: they closed it, I suspect because the previews were costing them too much bandwidth. The day I see a well-made OSS replica of Google Inbox is the day I go back to doing my own email.
I agree with you here. The one time we saw a progression with Google Inbox (which showed cards of events, photo-previews, etc.: https://cdn.vox-cdn.com/thumbor/vRLmb7RDrySSxylcMGIoV7dWTK8=...), it was quickly followed by a regression: they closed it, I suspect because the previews were costing them too much bandwidth. The day I see a well-made OSS replica of Google Inbox is the day I go back to doing my own email.
/cdn.vox-cdn.com/uploads/chorus_asset/file/2380070/desktop.0.png){kind=link}
I will say that it sucks just as a much from the developer front. I had to build some email templates for a project a few weeks ago and I was shocked how wired it was compared to regular webdev.
Using a framework is almost a requirement if you don't want to spend all your time on little differences between email clients. The layout is really wired too, with the recommendation to use a ton of nested tables. Not to mention wired bugs like Apple Mail not rendering a background unless you have an image on the page.
The best solution I've found thus far is to use MJML React [1]. This sorta normalizes things and lets you write normal react code that gets transpiled into some abomination that Outlook can read. But it sucks that the only two options that are actually worth a damn seem to be MJML[2] and Foundation[3].
And even with those frameworks it's no silver bullet. I noticed an issue with one provider where they did not respect the `display` css property, making my mobile and desktop layouts both render on the page.
If someone works on these clients I would love to know why there is such difficulty in rendering email?
[1]: https://github.com/wix-incubator/mjml-react
[2]: https://mjml.io/
[3]: https://get.foundation/emails.html
Using a framework is almost a requirement if you don't want to spend all your time on little differences between email clients. The layout is really wired too, with the recommendation to use a ton of nested tables. Not to mention wired bugs like Apple Mail not rendering a background unless you have an image on the page.
The best solution I've found thus far is to use MJML React [1]. This sorta normalizes things and lets you write normal react code that gets transpiled into some abomination that Outlook can read. But it sucks that the only two options that are actually worth a damn seem to be MJML[2] and Foundation[3].
And even with those frameworks it's no silver bullet. I noticed an issue with one provider where they did not respect the `display` css property, making my mobile and desktop layouts both render on the page.
If someone works on these clients I would love to know why there is such difficulty in rendering email?
[1]: https://github.com/wix-incubator/mjml-react
[2]: https://mjml.io/
[3]: https://get.foundation/emails.html
“ i frequently need to search with it as To: when I've got folders of email where I'm a co-recipient and need to search who the mail was address to”
That seems like an odd use case that I have never needed to do. Not sure why there would be default support for that when you could just start your search with “to:”
That seems like an odd use case that I have never needed to do. Not sure why there would be default support for that when you could just start your search with “to:”
Im not sure I agree: sometimes it's easier to remember the names of your colleagues that were a part of a certain conversation. Especially if the sender is from outside your organisation, say a client, a journalist, a subcontractor.
It's incorrect to assume that a Windows application will open the Find interface via the keyboard shortcut Ctrl+F. In Microsoft Word that shortcut opens the Navigation interface, and Find is now Advanced Find, which can be opened simply and intuitively via Ctrl+H - Alt+D.
Frequent revalidation training in the leverage of Microsoft products is something that would have helped your person avoid looking unprofessional.
Frequent revalidation training in the leverage of Microsoft products is something that would have helped your person avoid looking unprofessional.
Email does suck, at least HTML email. And that's not just because HTML was and still is the wrong markup tool for email.
I'm reading most of my mail with mutt on the command line and that works quite well. Until … some email with a confirmation link for something shows up. Or with the wrong MIME structure.
Because these confirmation links more often than not are execessivly long, state-carrying links, which wrap around even in my 99 (or more) columns wide windows. Because lazy web designers don't use a short SHA key, which would relate to a database entry of the full data. No, they send their complete state.
Oh, and did I mention those MIME emails with the wrong structure? Where the first part is the text part telling me that my MUA cannot display their fine mail? It can (easily formatted with external helpers like w3m) but I have to select the 2nd or 3rd part of their "fine" mail first by hand.
I'm reading most of my mail with mutt on the command line and that works quite well. Until … some email with a confirmation link for something shows up. Or with the wrong MIME structure.
Because these confirmation links more often than not are execessivly long, state-carrying links, which wrap around even in my 99 (or more) columns wide windows. Because lazy web designers don't use a short SHA key, which would relate to a database entry of the full data. No, they send their complete state.
Oh, and did I mention those MIME emails with the wrong structure? Where the first part is the text part telling me that my MUA cannot display their fine mail? It can (easily formatted with external helpers like w3m) but I have to select the 2nd or 3rd part of their "fine" mail first by hand.
"No, they send their complete state."
Oh, so that is what is happening ?
When I see these extremely long URLs I know, of course, that someone is being clueless and sloppy and I know, of course, that whatever they are embedding could be hashed or compressed to 64 (or fewer) characters ...
But you are saying that what I am witnessing is the entire state of the transaction is being passed in the URL ?
I guess I thought that they were passing multiple third party tracking strings all in the same URL and that different parts of the string were actually for different consumers of that data ...
Oh, so that is what is happening ?
When I see these extremely long URLs I know, of course, that someone is being clueless and sloppy and I know, of course, that whatever they are embedding could be hashed or compressed to 64 (or fewer) characters ...
But you are saying that what I am witnessing is the entire state of the transaction is being passed in the URL ?
I guess I thought that they were passing multiple third party tracking strings all in the same URL and that different parts of the string were actually for different consumers of that data ...
It's not clueless or sloppy. They are most likely using https://en.wikipedia.org/wiki/JSON_Web_Token which is a well-defined standard and extremely common in the authentication world because it makes a ton of sense. It lets your authentication server be mostly stateless instead of storing tons of sessions unnecessarily.
Never heard JWT pronounced "jot", I've always sounded it out letter by letter. But nor have I ever considered encoding a JWT into a URL!
If wrapping long links causes them to break then does very much sound like an email CLIENT issue.
> Email does suck, at least HTML email. And that's not just because HTML was and still is the wrong markup tool for email.
I mean, citation needed. I’m ready to consider the idea but give me a reason!
95+% of computer users will not want to use a command line.
I mean, citation needed. I’m ready to consider the idea but give me a reason!
95+% of computer users will not want to use a command line.
Forsaking HTML doesn't imply embracing command line.
In my experience, most mails don't actually use any styling beyond the automatic blockquote for the endless quote chains that mail clients automatically add. So people are wasting storage and transfer for something they don't really use.
When I see a mail which could actually use some styling, it's usually something involving maths and HTML is not suitable for that case. People usually send LaTeX snippets in plain text in this case.
And while I'm at it, the endless quote chains are another thing which has no reason for existing. Each mail in a thread steadily grows in size, because mail clients "conveniently" always quote everything and put the text cursor above it so that the user doesn't stop for a moment to look at the size of what they're sending and consider the absurdity of the situation, when their client is perfectly capable of reconstructing the whole thread without copying all mails in each message. Quoting should be opt-in on a case-by-case basis. As they function in the wild today, the quotes are just useless garbage attached to everything.
In my experience, most mails don't actually use any styling beyond the automatic blockquote for the endless quote chains that mail clients automatically add. So people are wasting storage and transfer for something they don't really use.
When I see a mail which could actually use some styling, it's usually something involving maths and HTML is not suitable for that case. People usually send LaTeX snippets in plain text in this case.
And while I'm at it, the endless quote chains are another thing which has no reason for existing. Each mail in a thread steadily grows in size, because mail clients "conveniently" always quote everything and put the text cursor above it so that the user doesn't stop for a moment to look at the size of what they're sending and consider the absurdity of the situation, when their client is perfectly capable of reconstructing the whole thread without copying all mails in each message. Quoting should be opt-in on a case-by-case basis. As they function in the wild today, the quotes are just useless garbage attached to everything.
HTML vs plain text is a distraction; it's not the 1970's anymore and saving a byte or two here and there just isn't the computing world we're living in. Not when images, video, or audio files regularly get attached to email.
Quote chains are why it's both email and email clients that need to improve. Without consensus on what's "right", we're left with poor solutions with poor UX, and implemented in a fragmented way, because all clients need to agree. What's more, how do you loop someone into a conversation they weren't previously a part of, if you don't have the history of the thread in each mail? This is something Slack gets right, and because they control the client as well, they can unilaterally make changes that support their view of how message history works. The strength of email is in its decentralization but here, it becomes a shortcoming.
Quote chains are why it's both email and email clients that need to improve. Without consensus on what's "right", we're left with poor solutions with poor UX, and implemented in a fragmented way, because all clients need to agree. What's more, how do you loop someone into a conversation they weren't previously a part of, if you don't have the history of the thread in each mail? This is something Slack gets right, and because they control the client as well, they can unilaterally make changes that support their view of how message history works. The strength of email is in its decentralization but here, it becomes a shortcoming.
> HTML vs plain text is a distraction; it's not the 1970's anymore and saving a byte or two here and there just isn't the computing world we're living in. Not when images, video, or audio files regularly get attached to email.
It's not about HTML vs plain text. It's about HTML vs a way to style text which is actually useful to the users. HTML is so bad for this purpose, in practice 99% of HTML mails don't use any tags in their proper content and mails which could use some styling to make them more readable are using plain text, because HTML is of no help to them. My remark about overhead was actually about the quotes, whose sizes grow linearly as threads get longer (and the threads grow quadratically instead of linearly), not about HTML. You don't pay for tags you do not use (almost). The only rich HTML mails (as opposed to plain text HTML mails) I get are marketing mails, which want to track me and "stand out from the crowd", neither of which I have an interest in, and HR mails.
> What's more, how do you loop someone into a conversation they weren't previously a part of, if you don't have the history of the thread in each mail? This is something Slack gets right
Slack doesn't get it right. When you join a conversation, you always see the whole history. But in practice people conduct conversations according to the assumption of who is taking part in them at a given moment. They can't predict the future and that someone will add another person to the conversation, and now this person will see everything they wrote. There is no way to add them to the conversation with a context of "the last n messages" e.g. In an ideal mail client you would select which messages from the thread you want to share with the newly-added conversation participant.
It's not about HTML vs plain text. It's about HTML vs a way to style text which is actually useful to the users. HTML is so bad for this purpose, in practice 99% of HTML mails don't use any tags in their proper content and mails which could use some styling to make them more readable are using plain text, because HTML is of no help to them. My remark about overhead was actually about the quotes, whose sizes grow linearly as threads get longer (and the threads grow quadratically instead of linearly), not about HTML. You don't pay for tags you do not use (almost). The only rich HTML mails (as opposed to plain text HTML mails) I get are marketing mails, which want to track me and "stand out from the crowd", neither of which I have an interest in, and HR mails.
> What's more, how do you loop someone into a conversation they weren't previously a part of, if you don't have the history of the thread in each mail? This is something Slack gets right
Slack doesn't get it right. When you join a conversation, you always see the whole history. But in practice people conduct conversations according to the assumption of who is taking part in them at a given moment. They can't predict the future and that someone will add another person to the conversation, and now this person will see everything they wrote. There is no way to add them to the conversation with a context of "the last n messages" e.g. In an ideal mail client you would select which messages from the thread you want to share with the newly-added conversation participant.
> Forsaking HTML doesn't imply embracing command line.
To be clear, I agree, but it was the only reason I could see in GP for why HTML was annoying. (Not to say GP doesn't have a right to be annoyed, I just think that particular reason is unique.)
To be clear, I agree, but it was the only reason I could see in GP for why HTML was annoying. (Not to say GP doesn't have a right to be annoyed, I just think that particular reason is unique.)
In my day job I use Thunderbird on a Mac, with HTML turned off. Because too many colleagues send Office attachments. So you don't need to use a command line to turn HTML off (but neither do you need to be afraid to use it CLI ;-)
Citations:
"HTML Email: Whenever Possible, Turn It Off!" https://subversion.american.edu/aisaac/notes/htmlmail.htm
https://phishingtackle.com/articles/phishing-emails-with-htm...
Citations:
"HTML Email: Whenever Possible, Turn It Off!" https://subversion.american.edu/aisaac/notes/htmlmail.htm
https://phishingtackle.com/articles/phishing-emails-with-htm...
Markdown would better serve 95% of the email I see.
Indeed, Markdown is literally derived from the markup conventions invented for usenet and e-mail messages.
Agreed wholeheartedly. I'd love to see email clients embrace markdown rendering (and sending) as an alternative to HTML. For stuff like links, headings, bulleted lists, tables, etc. in a single page, markdown is perfect. Emails rarely exceed the complication of a readme, and markdown works amazingly for those.
Even better: it remains totally readable in its raw unrendered form. So you're not really forcing anyone else to adopt your syntax, just... nudging.
Even better: it remains totally readable in its raw unrendered form. So you're not really forcing anyone else to adopt your syntax, just... nudging.
My MUA (GNOME evolution) supports sending markdown emails.
That’s a compelling feature. Can you have it actually send as `Content-Type: text/markdown` or does it still convert to HTML for now?
It offers three markdown mail composition options: Markdown (text/markdown), Markdown as Plain Text (text/plain), Markdown as HTML (text/plain and text/html). Doesn't seem to be a way to have text/markdown and text/html though.
It also renders incoming text/markdown emails in a HTML-like way using WebKit, rather than showing the raw markdown data.
It also renders incoming text/markdown emails in a HTML-like way using WebKit, rather than showing the raw markdown data.
The markdown spec includes the full html spec (https://daringfireball.net/projects/markdown/syntax#html)
95+% of computer users who mention not wanting to use or see a command line are so utterly terrified by the command line "bogeyman" that they imagine command lines appearing in places they would actually never be, or be required.
What does the command line have to with non-HTML mail? It's perfectly feasible to have a window-based mail client that creates text mails.
As a fellow mutt user, I have the same complaints. Sometimes, the confirmation link can be activated by opening the HTML mail in lynx or w3m but in many cases, using the confirmation requires that the browser runs Javascript so I ended up having to copy the link from the terminal emulator, reformat it (remove line breaks and plus symbols) and paste it into Firefox. :(
My other annoyance is Mailchimp users sending emails that have the correct message in the HTML part but old or previous content in the plain-text part. That’s even worse than those who simply omit the plain-text part.
My other annoyance is Mailchimp users sending emails that have the correct message in the HTML part but old or previous content in the plain-text part. That’s even worse than those who simply omit the plain-text part.
I really wish we could send text/markdown emails and have clients support displaying it natively. It would be a nice middle ground.
I strongly disagree that the problem with email is clients. We simply get too much information sent to us via email. I don't want to have to filter my inbox--I want to receive just as much information that I need.
For example, my company sends me an email everyday telling me about company-sponsored social events. Often, the emails contain information they've already sent at least 5 times. Email is the wrong way to communicate this information. They should have a shared calendar or web page that lists this information. No email client UI can resolve poor information sharing practices.
For example, my company sends me an email everyday telling me about company-sponsored social events. Often, the emails contain information they've already sent at least 5 times. Email is the wrong way to communicate this information. They should have a shared calendar or web page that lists this information. No email client UI can resolve poor information sharing practices.
The same problem exists with physical mail. I don't need advertisement flyers. I want a realtime spreadsheet with updated prices and discounts.
> The same problem exists with physical mail.
I get way less physical mail than email.
People have to pay money to send me physical mail. It's not a lot of money, but it 99% of email spammers would not be able to afford to physical spam me.
I get way less physical mail than email.
People have to pay money to send me physical mail. It's not a lot of money, but it 99% of email spammers would not be able to afford to physical spam me.
True, but I can automate throwing the email into the trash, I have to manually pickup the snail mail at least 3 times a week to keep the mailbox from overflowing. I have a sorting table right next to the trash can. Most days, it all goes into the trash.
Almost all clients have blacklists, instead of whitelists, which is the problem.
Email should be "block" by default. If you want to send me an email, your email address/account should first request to be allowed to email me, and once I approve your emails can come through. If I ever get sick of you, I should be able to block you with a keystroke.
You can implement this flow. It makes a huge difference:
http://blog.nawaz.org/posts/2018/Sep/solving-my-email-proble...
Email should be "block" by default. If you want to send me an email, your email address/account should first request to be allowed to email me, and once I approve your emails can come through. If I ever get sick of you, I should be able to block you with a keystroke.
You can implement this flow. It makes a huge difference:
http://blog.nawaz.org/posts/2018/Sep/solving-my-email-proble...
So you sign up at my website for something. We send you an email. Your blocking system rejects it. I'm not going to send a suitably-formatted request to you.
> I'm not going to send a suitably-formatted request to you.
That is the intended goal.
In reality, if you read the article, your email goes into quarantine and if I really do want to read messages from your site, I simply whitelist the address with a keystroke.
That is the intended goal.
In reality, if you read the article, your email goes into quarantine and if I really do want to read messages from your site, I simply whitelist the address with a keystroke.
> if I really do want to read messages from your site
If you didn't want to read them, you wouldn't have signed up. Your quarantine will be full (even more than "Spam"), and you won't know (necessarily) what the from address looks like.
If you didn't want to read them, you wouldn't have signed up. Your quarantine will be full (even more than "Spam"), and you won't know (necessarily) what the from address looks like.
> If you didn't want to read them, you wouldn't have signed up.
There are many use cases beyond what you're stating. Often I need to sign up for a web site temporarily ("Sign up to get our free ebook!") ("You need to sign up to place an order") In those cases I simply ignore the emails.
If I sign up for a newsletter with the intention of reading it, I'll keep an eye out for it and whitelist it. It's not hard.
> Your quarantine will be full (even more than "Spam"), and you won't know (necessarily) what the from address looks like.
I've been using this system for 3-4 years now, and this so far has not been a problem. I still monitor the quarantine folder as I don't expect everyone to go through the hoops to get to me. It's just a much smaller burden than having it all show up in the inbox and I can check it at a different pace (e.g. once every few days).
And even if I somehow forget to whitelist your site, what's the worst that will happen? I won't get messages from your site. Of all my worries in this world, this just doesn't even register.
There are many use cases beyond what you're stating. Often I need to sign up for a web site temporarily ("Sign up to get our free ebook!") ("You need to sign up to place an order") In those cases I simply ignore the emails.
If I sign up for a newsletter with the intention of reading it, I'll keep an eye out for it and whitelist it. It's not hard.
> Your quarantine will be full (even more than "Spam"), and you won't know (necessarily) what the from address looks like.
I've been using this system for 3-4 years now, and this so far has not been a problem. I still monitor the quarantine folder as I don't expect everyone to go through the hoops to get to me. It's just a much smaller burden than having it all show up in the inbox and I can check it at a different pace (e.g. once every few days).
And even if I somehow forget to whitelist your site, what's the worst that will happen? I won't get messages from your site. Of all my worries in this world, this just doesn't even register.
I think you are sending exactly the kind of email the parent is trying to block — transactional email.
The parent signed up to receive whatever it is that I am sending. But it will not arrive (fully) unless I do something (or they remember to add a From: address that they do not yet know).
I don't want to have to configure blacklists and whitelists. My current workflow which seems to be inline with the rest of the world is if the message is junk, send it to my email. If its important, send it to me via Teams/Slack.
At least everything sent to me via IM apps comes from a real person.
At least everything sent to me via IM apps comes from a real person.
To each his/her own. I'm the opposite. Anything via IM is treated as fleeting, and if I don't get to it now it's forgotten. I'm not going to keep track of dozens of channels.
The benefit of email is its openness. I can organize it as I wish - I can't seem to do that with Teams (nor Slack, most likely). Can I copy a Slack message and put it into my personal channel? Can I tag it with a label, and then do a query to get all messages with a label? Can I make a TODO item in the TODO app of my choice and link to a message?
I do all this with email. It's even easy.
Also, Teams/Slack searching sucks. They're also resource hogs.
The benefit of email is its openness. I can organize it as I wish - I can't seem to do that with Teams (nor Slack, most likely). Can I copy a Slack message and put it into my personal channel? Can I tag it with a label, and then do a query to get all messages with a label? Can I make a TODO item in the TODO app of my choice and link to a message?
I do all this with email. It's even easy.
Also, Teams/Slack searching sucks. They're also resource hogs.
> Anything via IM is treated as fleeting, and if I don't get to it now it's forgotten.
Agree on this - I'll reply to emails I got weeks ago when I finally get around to dealing with them. I've never responded to a chat message more than a day old (unless I've been offline for an extended period).
Agree on this - I'll reply to emails I got weeks ago when I finally get around to dealing with them. I've never responded to a chat message more than a day old (unless I've been offline for an extended period).
Where it disappears into the figurative rear view mirror.
> I strongly disagree that the problem with email is clients. We simply get too much information sent to us via email. I don't want to have to filter my inbox--I want to receive just as much information that I need.
It sounds like you haven't tried an email client where filtering is ergonomic. I use mu / mu4e for filtering and reading emails. At my inbox, I press `s`, enter a search term, and instantly get matches. I can press `S` (capital s) to further refine the search with another term if the previous was too broad. Filtering is incredibly powerful and useful if it is presented in an accessible way in the client.
It sounds like you haven't tried an email client where filtering is ergonomic. I use mu / mu4e for filtering and reading emails. At my inbox, I press `s`, enter a search term, and instantly get matches. I can press `S` (capital s) to further refine the search with another term if the previous was too broad. Filtering is incredibly powerful and useful if it is presented in an accessible way in the client.
The fact that we all need such advanced filtering to make email usable at all should be the canary in the coal mine that we’ve lost our way.
Good email client UI may help facilitate a better information sharing practice
Sometimes I wonder why the email client doesn't look more like Facebook with groups (=mailing lists) and posts/threads and DMs etc
Sometimes I wonder why the email client doesn't look more like Facebook with groups (=mailing lists) and posts/threads and DMs etc
Maybe the problem is that culturally, email is treated like face-to-face talking. We often talk to each other just to be pleasant. It wouldn't be weird for someone to remind you about a meeting if they saw you, or to ask if you're going to the company picnic. Actually, it would be weirder if they just posted it on the calendar and said nothing else.
So, maybe email clients aren't the issue, people are the issue (like most problems).
So, maybe email clients aren't the issue, people are the issue (like most problems).
> email is treated like face-to-face talking.
Really? I tell everyone who emails me that emails are postcards written in granite. Anyone might be able to see them, forever, from now on.
I also tell them that I check my emails once a day. If something is really urgent, stand in front of me.
Really? I tell everyone who emails me that emails are postcards written in granite. Anyone might be able to see them, forever, from now on.
I also tell them that I check my emails once a day. If something is really urgent, stand in front of me.
Hmmm… someone should really make an email client with user-friendly filters to let you sinkhole that junk into a folder you never look at ;).
>someone should really make an email client with user-friendly filters to let you sinkhole that junk into a folder you never look at
If you read past it, he actually wrote "I don't want to have to filter my inbox".
I also agree with him. I never use email clients' software filtering "rules" or "smart folders" because that's extra digital housekeeping work I don't want to do.
Doesn't matter if the email client filtering UI is "user-friendly". I still don't want to mess with it.
If you read past it, he actually wrote "I don't want to have to filter my inbox".
I also agree with him. I never use email clients' software filtering "rules" or "smart folders" because that's extra digital housekeeping work I don't want to do.
Doesn't matter if the email client filtering UI is "user-friendly". I still don't want to mess with it.
Yeah my bad, brain autoparsed that as “filter” == “clean out” in context.
I am surprised that few commenters have criticized the tech-curmudgeon perspective that underlies most of the author's preferences. His rigid view of what email should consist of is not really mainstream.
For personal and some business correspondence, sure, plain-text messages are fine. For transactional messages, structured metadata becomes more important. For anything from a brand, rich formatting helps convey information in a way that's consistent with the rest of the brand's digital presence -- which may not be important to him, but is important enough to enough other people that companies spend a lot of money to make it so, and many consumers appreciate it.
Dynamic elements, like calendar integrations, also have their place, and it feels like a lot of this stuff gets written off as cruft in his article, whereas it's not cruft to a lot of people.
If anything, I would like email to become even more advanced and fluid, rather than scaled back to fit in the little box he has crammed it into.
For personal and some business correspondence, sure, plain-text messages are fine. For transactional messages, structured metadata becomes more important. For anything from a brand, rich formatting helps convey information in a way that's consistent with the rest of the brand's digital presence -- which may not be important to him, but is important enough to enough other people that companies spend a lot of money to make it so, and many consumers appreciate it.
Dynamic elements, like calendar integrations, also have their place, and it feels like a lot of this stuff gets written off as cruft in his article, whereas it's not cruft to a lot of people.
If anything, I would like email to become even more advanced and fluid, rather than scaled back to fit in the little box he has crammed it into.
There's a large overlap between people that want to use email as a central part of their lives and people who think everything other than text is just unnecessary waste. It's not really a technical thing, but a cultural tie. Think suckless folks or the Gemini project people.
I think a good argument could be made for Email being a federated, open substrate to send and receive non-real-time messages but not many people who make that argument want to see rich messages even though it's technically an easily solvable problem (albeit hopefully not the way MIME has done it today.)
I think a good argument could be made for Email being a federated, open substrate to send and receive non-real-time messages but not many people who make that argument want to see rich messages even though it's technically an easily solvable problem (albeit hopefully not the way MIME has done it today.)
> brand's digital presence
Yeah, ok. You lost me there. Technology should exist to enable people, not some marketing asshole that thinks a button would look significantly better five pixels to the left.
Yeah, ok. You lost me there. Technology should exist to enable people, not some marketing asshole that thinks a button would look significantly better five pixels to the left.
I don't think it's necessarily an either/or.
If I go to the Washington Post website, it obviously has a distinctive style that is different from other newspapers. If I download a Washington Post mobile app, it's got that same distinctive style.
Why should the email experience be inconsistent with the style of those other digital applications?
What might seem like a silly, arbitrary "5 pixels to the left" style choice to you can be extremely useful in helping email users distinguish between a trusted brand, like a newspaper they subscribe to, and a knock-off or spam message. When plain text is the only cue, that's somewhat harder to do.
If I go to the Washington Post website, it obviously has a distinctive style that is different from other newspapers. If I download a Washington Post mobile app, it's got that same distinctive style.
Why should the email experience be inconsistent with the style of those other digital applications?
What might seem like a silly, arbitrary "5 pixels to the left" style choice to you can be extremely useful in helping email users distinguish between a trusted brand, like a newspaper they subscribe to, and a knock-off or spam message. When plain text is the only cue, that's somewhat harder to do.
If you feel that is a distinguishing factor between spam and corporate spam, you are quite simply wrong. The layout of an email means less than nothing for authenticating the source.
Corporate spammers love rich formatting and dynamic elements. Nobody else wants that crap.
> and many consumers appreciate it.
I sure do -- if I get an email that has a ton of money spent on branding, it's a useful signal that the email is unimportant, and can be ignored.
I sure do -- if I get an email that has a ton of money spent on branding, it's a useful signal that the email is unimportant, and can be ignored.
I want my email organised by sender, not by message. I want a list of senders with unread messages when I open the client. I may want some way to indicate which senders are more important so that they are displayed more prominently in some way.
Maybe this has been tried and it's shit. I dunno, but I like the sound of it. I think it might be a good way to cut through the noise of the inbox. When I get snail mail I will quickly sort by sender (then read the tedious shite first :-) ).
I should try and write it for myself.
Maybe this has been tried and it's shit. I dunno, but I like the sound of it. I think it might be a good way to cut through the noise of the inbox. When I get snail mail I will quickly sort by sender (then read the tedious shite first :-) ).
I should try and write it for myself.
https://www.shortwave.com/ might be of interest to you! Each sender (or group-of-recipients as group conversation) is bundled together into a thread-of-threads, and you can favorite senders or groups of interest. It's fast and thoughtfully built, by the team behind Firebase. Not affiliated, just happy to have found something that made me actually enjoy email again!
Thanks, shortwave does look interesting. I'm not really a gmail user though, but shortwave does appear to allow for more group or sender oriented presentation of messages.
You basically want something closer to an IM UX. Delta chat does this: https://delta.chat/en/
Only issue: Delta Chat doesn't allow to change the subject, so your conversation with someone is going to be a looooong unique thread.
I am myself thinking about doing something closer to what zulip does, with subjects as "channels". Yet another side project.
Only issue: Delta Chat doesn't allow to change the subject, so your conversation with someone is going to be a looooong unique thread.
I am myself thinking about doing something closer to what zulip does, with subjects as "channels". Yet another side project.
yes, it's an eye opener. "chat(view) over smtp" has untapped potential - against all obituary writers of email.
Cool idea. Looks like there's a thunderbird extension for this but it's woefully out of date and hasn't been updated since 2011. Maybe you can revive it?
https://addons.thunderbird.net/en-US/thunderbird/addon/gathe...
https://addons.thunderbird.net/en-US/thunderbird/addon/gathe...
This is easy in Thunderbird, right?
I have filters that put around 35 specific senders (bank, ISP, VPS-provider, ...) each in their own folder. Thunderbird makes these folders bold when a mail arrives, indicating the number of unread messages.
Whenever an important mail arrives, I immediately notice it.
35 specific filter rules doesn't sound "easy" to most people. I'd probably have about 50 addresses I'd treat that way too.
Outlook by and large does this. It’s also a bloated piece of a desktop app, so pick your poison.
https://www.uniboxapp.com/ has been around for quite long time.
Yep, that's the basic idea. Not suitable for me though as I am not an Apple user.
Who are all of these people who struggle with email? What's causing so many problems? I use the built-in macOS Mail app, and it works brilliantly. It threads conversations, and I can quickly mark multiple messages as read. It's responsive and native, and even themes non-HTML email in a reliably readable dark mode.
I have a few filters set up to send annoying things to spam or a dedicated folder (alas, dear JIRA, I have never wanted to read one of your notifications). But my personal account works perfectly without any kind of filters or folders at all. I even use my protonmail accounts through the protonmail app and those work fine.
Is there something wrong with me? Am _I_ the one using email wrong? But it works well for me, and I seem consistently better at responding to messages, so... I'm mostly just confused. I use read/unread as a means of triaging "email I have to deal with" and "email I've already dealt with", but that's basically my only system.
Seriously, can someone explain this problem? In my eyes, email and RSS are pretty much the only internet protocols that have JUST WORKED for 20-30 years, my entire life. Everything else has been infected by adware and spyware and garbage. Maybe they're stagnant... or maybe they're just mature?
I have a few filters set up to send annoying things to spam or a dedicated folder (alas, dear JIRA, I have never wanted to read one of your notifications). But my personal account works perfectly without any kind of filters or folders at all. I even use my protonmail accounts through the protonmail app and those work fine.
Is there something wrong with me? Am _I_ the one using email wrong? But it works well for me, and I seem consistently better at responding to messages, so... I'm mostly just confused. I use read/unread as a means of triaging "email I have to deal with" and "email I've already dealt with", but that's basically my only system.
Seriously, can someone explain this problem? In my eyes, email and RSS are pretty much the only internet protocols that have JUST WORKED for 20-30 years, my entire life. Everything else has been infected by adware and spyware and garbage. Maybe they're stagnant... or maybe they're just mature?
Email works remarkably well when you can easily control who gets your address. It works absolutely abysmally for anyone who gets subjected to a constant deluge of random semi-reasonable emails from unknown senders. Some are outright spam, some are actually legitimate professional inquiries, and some are a blend between the two.
I think fundamentally the problem is that email works great if you aren't the subject of a random influx. If you create an address and never tell anyone except a handful of good sites, you're okay! If your address is everywhere, ends up in a data breach, or ends up on a marketing list for "important business people / decision makers to try to pitch products to" then you're in for a much different experience.
Why not just use filters? It's truly random who sends what when. The only email provider that I truly appreciate is HEY, which has deny-by-default email. You explicitly allow people to contact you, which is a different and very nice approach. It has other problems, though, which make it hard for me to suggest it as a solution.
I think fundamentally the problem is that email works great if you aren't the subject of a random influx. If you create an address and never tell anyone except a handful of good sites, you're okay! If your address is everywhere, ends up in a data breach, or ends up on a marketing list for "important business people / decision makers to try to pitch products to" then you're in for a much different experience.
Why not just use filters? It's truly random who sends what when. The only email provider that I truly appreciate is HEY, which has deny-by-default email. You explicitly allow people to contact you, which is a different and very nice approach. It has other problems, though, which make it hard for me to suggest it as a solution.
FWIW, you can cut down a lot of the B2B spam by unsubscribing on Apollo. (IME, it does work.)
https://www.apollo.io/privacy-policy/remove/
https://www.apollo.io/privacy-policy/remove/
Grey listing in Postfix does a similar thing, and works amazing! Drawback is senders have to try at least twice - spammer don't (usually) and all proper/legit does.
>Who are all of these people who struggle with email?
The default outlook app is terrible. It keeps hiding important emails from me and putting unimportant ones front and center. It's bad enough I use thunderbird exclusively to manage those mail boxes and read emails only on the desktop/laptop.
The default outlook app is terrible. It keeps hiding important emails from me and putting unimportant ones front and center. It's bad enough I use thunderbird exclusively to manage those mail boxes and read emails only on the desktop/laptop.
You can turn off focus mode in settings. Nothing will be hidden.
I personally find Gmail is much worse at hiding things. I try to be responsive but for whatever reason the way they handle threading tends to cause me not just to neglect to read, but to not know that there is something there.
I think the difference is Outlook shows all of the emails (from all folders) in a thread in a way that makes sense. Google randomly chooses a point in the middle of the list to just stop showing a bunch of emails and you have to manually click to see.
I constantly hear that gmail is better but I just can’t see it. Not in a matter of taste way, but like if people said they preferred being stabbed in the face repeatedly with a dull knife to eating their favorite food. I just can’t understand or empathize and I wish I did. It is kind of lonely being one of the few who not just likes email, but likes the Outlook approach to email.
I personally find Gmail is much worse at hiding things. I try to be responsive but for whatever reason the way they handle threading tends to cause me not just to neglect to read, but to not know that there is something there.
I think the difference is Outlook shows all of the emails (from all folders) in a thread in a way that makes sense. Google randomly chooses a point in the middle of the list to just stop showing a bunch of emails and you have to manually click to see.
I constantly hear that gmail is better but I just can’t see it. Not in a matter of taste way, but like if people said they preferred being stabbed in the face repeatedly with a dull knife to eating their favorite food. I just can’t understand or empathize and I wish I did. It is kind of lonely being one of the few who not just likes email, but likes the Outlook approach to email.
Are outlook-hosted email accounts incompatible with Thunderbird? That's been a solid choice for me in the past, even with their recent stagnant period of development. I do agree that there are a lot of crappy email clients out there, but if you have freedom of choice of the client you use, why not switch?
They work perfectly. The only thing that doesn't fully work in Thunderbird is Outlook calendar. You can't create/edit/delete events from Thunderbird, but can read and accept them fine.
The big issue is if your company opts into Exchange’s features that limit which clients can connect to the server.
>It's bad enough I use thunderbird exclusively
Please read the post before you reply to it. It's only a few lines.
Please read the post before you reply to it. It's only a few lines.
Sorry, I phrased things poorly: why does the outlook app matter at all if you use Thunderbird exclusively?
Up until recently Thunderbird had no phone client. Which meant I needed to be at a laptop/desk to respond to an email. That was fine apart from the 1% of cases where I needed to known that I got an email right away.
1, you bothered to use a good desktop client, putting you ahead of 95% of people. 2, you got a choice of which client to use, not always true in the workplace.
3, how many emails do you get? I averaged 60 emails per day in 2021, or probably 80-90 work emails per work day. More than half don't need to be read, but even spending 30 seconds per email would be a problem. Many people probably get a lot more.
3, how many emails do you get? I averaged 60 emails per day in 2021, or probably 80-90 work emails per work day. More than half don't need to be read, but even spending 30 seconds per email would be a problem. Many people probably get a lot more.
I don't think you're wrong, I too use Apple's Mail. It works pretty well. It's got a good filtering system that can sort incoming mail properly. It doesn't try to make e-mail into anything but e-mail. It also integrates into Spotlight/QuickLook so searching for mail messages can happen outside of Mail and has all the expressiveness of Spotlight.
From memories long ago of using Outlook and Thunderbird I think I can see where people get a hate for e-mail clients. I don't remember either of those being particularly good clients. They've likely changed over the years and could be better but I have no desire to drop Apple Mail.
From memories long ago of using Outlook and Thunderbird I think I can see where people get a hate for e-mail clients. I don't remember either of those being particularly good clients. They've likely changed over the years and could be better but I have no desire to drop Apple Mail.
There's nothing wrong with you. The same people who complain about talking to someone on the phone are the ones who can't deal with e-mail. Ironically they prefer chat, which is probably the worst way to manage information, but definitely the least-effort.
That said, some e-mail clients are worse than others. Outlook for Mac is the worst client I've used in years. It doesn't even use Mac's notification system.
That said, some e-mail clients are worse than others. Outlook for Mac is the worst client I've used in years. It doesn't even use Mac's notification system.
Email issues;
- spam spam spam of the utterly firehose type
- spam spam spam of the corporate "unsubscribe in these easy 10 steps"
- attachment viruses (sometimes without you opening it!)
- even conversation organization is inferior to searchable chat where it's just a history stream
- email addresses obscure the users, chat apps are far better at this
- email addresses are a PITA in general
- no indication of being online
- emoticons are still a bit iffy, certainly worse than chat
- smartphone experience is far worse (could be bad clients... but...)
- legally it's a paper trail, chat is... not?
- attachments are not as smooth as chat, although it's a lot better than it used to be (drag n drop to browsers/clients are a LOT better)
- chat clients can support "undeliver" a bit more easily
That said, email is:
- open standard
- ubiquitous
Email seems fundamentally broken because of lack of regulation, just like the POTS (plain old telephone) system is utterly overridden.
And it would really really be nice if governments would make official email addresses for citizens for official communication and delivery. Or some means for me making money from incoming spam by charging a delivery fee.
The fact there are so many email campaign startups still to this day is depressing. There is zero chance they aren't effectively keeping email unusable. So I guess that's another annoying aspect of email: it will always be attacked by corporations, ceaselessly.
At least chat apps have corporate defenders (while they make you the product) but life is about choosing among non-ideal options.
- spam spam spam of the utterly firehose type
- spam spam spam of the corporate "unsubscribe in these easy 10 steps"
- attachment viruses (sometimes without you opening it!)
- even conversation organization is inferior to searchable chat where it's just a history stream
- email addresses obscure the users, chat apps are far better at this
- email addresses are a PITA in general
- no indication of being online
- emoticons are still a bit iffy, certainly worse than chat
- smartphone experience is far worse (could be bad clients... but...)
- legally it's a paper trail, chat is... not?
- attachments are not as smooth as chat, although it's a lot better than it used to be (drag n drop to browsers/clients are a LOT better)
- chat clients can support "undeliver" a bit more easily
That said, email is:
- open standard
- ubiquitous
Email seems fundamentally broken because of lack of regulation, just like the POTS (plain old telephone) system is utterly overridden.
And it would really really be nice if governments would make official email addresses for citizens for official communication and delivery. Or some means for me making money from incoming spam by charging a delivery fee.
The fact there are so many email campaign startups still to this day is depressing. There is zero chance they aren't effectively keeping email unusable. So I guess that's another annoying aspect of email: it will always be attacked by corporations, ceaselessly.
At least chat apps have corporate defenders (while they make you the product) but life is about choosing among non-ideal options.
> - no indication of being online
> - chat clients can support "undeliver" a bit more easily
Features, not problems.
> - email addresses obscure the users, chat apps are far better at this
What? Funnily enough, my XMPP ID and main E-Mail happen to be exactly the same.
> - even conversation organization is inferior to searchable chat where it's just a history stream
That is the only one out of the list I actually agree with, though I think that could be fixed by clients.
> - chat clients can support "undeliver" a bit more easily
Features, not problems.
> - email addresses obscure the users, chat apps are far better at this
What? Funnily enough, my XMPP ID and main E-Mail happen to be exactly the same.
> - even conversation organization is inferior to searchable chat where it's just a history stream
That is the only one out of the list I actually agree with, though I think that could be fixed by clients.
The lack of regulation and federated style is a huge plus. It provides a lot of advantages that people now just take for granted.
I agree, but for verifiable idenitity/formal comms with government, if they have a Postal Service, they should have an email service.
Of course it would be swamped with spam, just like the snail mail is. Which is an absolute travesty.
Of course it would be swamped with spam, just like the snail mail is. Which is an absolute travesty.
> Of course it would be swamped with spam, just like the snail mail is. Which is an absolute travesty.
Snail mail is not swamped by spam everywhere BTW - that is just a regulation issue. The difference with E-Mail is that you can cheaply send them internationally (so from outside any regulation you control) but even then I think the spam problem is overblown.
Snail mail is not swamped by spam everywhere BTW - that is just a regulation issue. The difference with E-Mail is that you can cheaply send them internationally (so from outside any regulation you control) but even then I think the spam problem is overblown.
> spam spam spam of the utterly firehose type
I have > 5 domains on my mailserver, all with wildcard email going to my inbox and two addresses publicly on my website and in numerous git repositories and bug trackers. I do not have any server side spam filter except a manual subject regexp to filter reject the most lazy spam at submission time. Even that only means about 40-50 trashed mails per day (most of which are moved there automatically by Thunderbird's spam filter), which includes legit mail that I don't want to keep like notifications that I have subscribed to. It takes about no time to double check the subjects to look for false positives. Either your definition of firehose is vastly different from mine or you somehow get vastly more spam than me.
Perhaps one factor might be that I don't have notifications for new mails at all since I check often enough and anyone who deserves my immediate attention has my phone number and/or jabber ID.
> spam spam spam of the corporate "unsubscribe in these easy 10 steps"
These are not a problem since they will keep using the same sender address. Reject at submission if you run the server, filter automatically to trash otherwise. Most will eventually get the hint if you never load their tracking pixels. If you want, report them to their host/mail provider. Corporate spam is only annoying if you do nothing at all about it.
> attachment viruses (sometimes without you opening it!)
Meh, the web has the same "problem".
> email addresses obscure the users, chat apps are far better at this
Good. Central identities suck.
> email addresses are a PITA in general
How so? They are globally unique identifies that you can almost completely customize and therefor easily rememberable. They can be as short as 6 characters including the @ and . for the domain (if you have too much money).
> emoticons are still a bit iffy, certainly worse than chat
What more than unicode + embedded images do you need?
> legally it's a paper trail, chat is... not?
Really depends on the server(s) in both cases.
> chat clients can support "undeliver" a bit more easily
Not having that is a feature. You can do delayed delivery and then cancel that if you are prone to make mistakes but once someone has your message why should you be able to pretend that you never sent it. For all you know they made a screenshot anyway. And if you meen the paper trail then you can bet that most chat networks don't actually delete the message from the database.
I have > 5 domains on my mailserver, all with wildcard email going to my inbox and two addresses publicly on my website and in numerous git repositories and bug trackers. I do not have any server side spam filter except a manual subject regexp to filter reject the most lazy spam at submission time. Even that only means about 40-50 trashed mails per day (most of which are moved there automatically by Thunderbird's spam filter), which includes legit mail that I don't want to keep like notifications that I have subscribed to. It takes about no time to double check the subjects to look for false positives. Either your definition of firehose is vastly different from mine or you somehow get vastly more spam than me.
Perhaps one factor might be that I don't have notifications for new mails at all since I check often enough and anyone who deserves my immediate attention has my phone number and/or jabber ID.
> spam spam spam of the corporate "unsubscribe in these easy 10 steps"
These are not a problem since they will keep using the same sender address. Reject at submission if you run the server, filter automatically to trash otherwise. Most will eventually get the hint if you never load their tracking pixels. If you want, report them to their host/mail provider. Corporate spam is only annoying if you do nothing at all about it.
> attachment viruses (sometimes without you opening it!)
Meh, the web has the same "problem".
> email addresses obscure the users, chat apps are far better at this
Good. Central identities suck.
> email addresses are a PITA in general
How so? They are globally unique identifies that you can almost completely customize and therefor easily rememberable. They can be as short as 6 characters including the @ and . for the domain (if you have too much money).
> emoticons are still a bit iffy, certainly worse than chat
What more than unicode + embedded images do you need?
> legally it's a paper trail, chat is... not?
Really depends on the server(s) in both cases.
> chat clients can support "undeliver" a bit more easily
Not having that is a feature. You can do delayed delivery and then cancel that if you are prone to make mistakes but once someone has your message why should you be able to pretend that you never sent it. For all you know they made a screenshot anyway. And if you meen the paper trail then you can bet that most chat networks don't actually delete the message from the database.
Can’t see really how phone anxiety may connect to email issues.
What problems do you see with Mac OS Outlook. It works well for me. Of course I would never have email notifications enabled anyway, so I don’t see that as a problem. Everything else works well.
The biggest complain I have is that it can’t open Windows EML files that some people forward as attachments. I have to go into the web version to see those. Just a weird miss there.
The biggest complain I have is that it can’t open Windows EML files that some people forward as attachments. I have to go into the web version to see those. Just a weird miss there.
The latest version of macOS Outlook (I have 16.64) can open EML files - for some reasons it cannot preview them, but opening works fine (although I vaguely remember that not working previously, not completely sure).
Using both Outlook and Mail on macOS, strongly prefer the latter, but our IT only allows Outlook for corporate emails :(
Using both Outlook and Mail on macOS, strongly prefer the latter, but our IT only allows Outlook for corporate emails :(
What is a Windows EML file?
If you locally save an email to a file in Outlook for Windows, it uses the EML format. For some reason, the Mac OS Outlook uses a different format. They have not been able to read the other’s format. I have some people who like to send emails with previous emails sent as attachments in EML format. It takes some gymnastics to be able to read those attachments. I see from another comment that the Mac OS Outlook may finally be able to read those files now.
It’s a format developed by Microsoft to store single email’s with headers and attachments.
I use Claws Mail since ..uh.. forever (it was called Sylpheed back then) and never felt the need to change. It's fast, and I mean really fast; I keep all my email since day one online so I can quickly search among all messages exchanged since 1997 (I migrated the earlier mailboxes from Windows/Eudora flawlessly) and find everything, including spam filled with vintage Windows malware or those watermarked Viagra/Cialis banners. It's tens of thousand messages and searches in indexed fields is next to instantaneous. If you think web based mail sucks and console clients are too much for non tech users, Claws Mail might be a middle ground worth of consideration.
https://claws-mail.org/downloads.php
https://claws-mail.org/downloads.php
Sylpheed is still Sylpheed. Claws is a fork of it.
You're right. Memory was mislead by the fact that for a while the forked project was named Sylpheed Claws.
For one brief shining moment, Google Inbox existed. It was the best mail client I've used, dating back to Eudora. Simple, focused. Not everybody liked it, but it was one of the few apps that I immediately loved, and that made me more productive.
Then Google sunsetted it, and folded some of the best features from it into Gmail.
Heads up: you don't fix an overly-complex application by adding the features from a very simple application to it.
Then Google sunsetted it, and folded some of the best features from it into Gmail.
Heads up: you don't fix an overly-complex application by adding the features from a very simple application to it.
it’s batshit crazy they got rid of it. it was perfectly focused on just the messages and nothing else. when i’m done reading something i don’t give a single fuck about where it goes as long as there’s a great search feature to let me find it again.
it kills me there is no spiritual successor. i’ve stripped down mac os mail.app to more or less work like that, but it’s not quite the same.
the hey.com client gets a lot of things right imo, but ive had the same gmail account for the past 17-18 years—and there's just no way im going to switch over to a hey.com address that requires that i keep paying for it or have it be deleted.
it kills me there is no spiritual successor. i’ve stripped down mac os mail.app to more or less work like that, but it’s not quite the same.
the hey.com client gets a lot of things right imo, but ive had the same gmail account for the past 17-18 years—and there's just no way im going to switch over to a hey.com address that requires that i keep paying for it or have it be deleted.
I have the same problem as you. So I just forward my email from Gmail to Hey.
Hey gets most of it right. I just wish they bundled emails automatically (similar to how Inbox did)
Hey gets most of it right. I just wish they bundled emails automatically (similar to how Inbox did)
As of yesterday, you can receive and respond via your Gmail address using Hey.com's client. https://bit.ly/3RdtmsR
got a link that works? i don’t see anything on their site about this.
Fixed link! https://drive.google.com/file/d/1PHWMgjlybynPHu9-fYeEZkdprQg...
They sent an email this week to all subscribers titled: "NEW in HEY: Send emails via Gmail"
I confirmed this works.
I was only receiving my Gmail emails before.
Now, when I reply I can select my hey.com or my gmail.com domain to send.
They sent an email this week to all subscribers titled: "NEW in HEY: Send emails via Gmail"
I confirmed this works.
I was only receiving my Gmail emails before.
Now, when I reply I can select my hey.com or my gmail.com domain to send.
thanks for this, that’s a potential game changer for me!
You can use hey with your own domain now: https://www.hey.com/custom-domains/
Agreed. My company uses Google Workspace, and I find the Gmail UI/UX absolutely unbearable in every way. I personally like Outlook (or rather what it used to be), and just wish for a clean Outlook for Gmail integration.
But the nightmare that is IMAP has prevented me from ever succeeding in cleanly integrating the two. In fact, the general experience of using Microsoft and Google products together is quite frustrating. I get that they are competitors, but not acknowledging the multi-platform reality of modern work and forcing me to suffer because you can't be healthy adversaries, is really ridiculous and I resent both companies for their user-hostile practices.
Looking at you too, Apple.
But the nightmare that is IMAP has prevented me from ever succeeding in cleanly integrating the two. In fact, the general experience of using Microsoft and Google products together is quite frustrating. I get that they are competitors, but not acknowledging the multi-platform reality of modern work and forcing me to suffer because you can't be healthy adversaries, is really ridiculous and I resent both companies for their user-hostile practices.
Looking at you too, Apple.
As much as Google Workspace email feels convenient, they have sort of broken the IMAP with the label system. Syncing to conventional email clients without label feature just creates multiple copies of emails if they have been labeled with more than 1 label. It is frustrating sometimes
Ideally, Google, MS, etc would deprecate IMAP and replace with JMAP.
https://jmap.io/software.html
https://jmap.io/software.html
We might need a protocol update, but many mail providers disabled IMAP for non-premium users already because they tried to force people to use shitty web apps.
Why?
IMAP is antiquated and suboptimal with today’s clients and use cases.
You still send data through a TCP port, there is not much difference. Yes the protocol is in itself different, but that's expected - it's a different protocol after all.
That sound more like fud than fact. Van you back that up?
https://jmap.io/index.html (Scroll to FAQ: Why is JMAP better than IMAP?)
Very trustworthy coming from the site that advocates that protocol. But I agree with some points.
JavaScript, embedded, in email is, pejoratively, a bad idea by putting too much power into a transmitted email.
Too many security holes, discovered and undiscovered with JavaScript, not to mention JMTP.
Better yet,
Hashing the local part of the email address and retrofitting mail clients to do the mapping and rejection is the best way to delete unwanted and unsolicited emails.
Couple that with new decentralized lookup of sender’s PKI (as well as DKIM).
That should add years/decades to SMTP viability and usability.
Too many security holes, discovered and undiscovered with JavaScript, not to mention JMTP.
Better yet,
Hashing the local part of the email address and retrofitting mail clients to do the mapping and rejection is the best way to delete unwanted and unsolicited emails.
Couple that with new decentralized lookup of sender’s PKI (as well as DKIM).
That should add years/decades to SMTP viability and usability.
I was under the impression JMAP was just a sync protocol and had nothing to do with js in email. Is that incorrect?
JMAP is not JavaScript embedded in email. Are you thinking of something else?
But it does nothing to prevent JS in its payload.
I can also put JavaScript in a DNS TXT record; the protocol does nothing to stop that!
There is no "JavaScript" in JMAP in the sense that it's supported by the protocol, and the specification explicitly warns against email clients interpreting JavaScript.
There is no "JavaScript" in JMAP in the sense that it's supported by the protocol, and the specification explicitly warns against email clients interpreting JavaScript.
Now you are getting the idea of how to design a new network protocol in contrast to adding the supporting numbers of parsers and validators.
Potential and actual vulnerabilities explodes, like the chronic problems of Microsoft Macros.
Potential and actual vulnerabilities explodes, like the chronic problems of Microsoft Macros.
sure, but that's not a feature a protocol should have. Because the protocol itself does not interact with it in any way. It's clients that process that javascript and execute it. The protocol is about moving 'emails' from one place to another. If you don't want javascript in your email and run your own email stack you can certainly filter out javascript blobs if you want. Or you can chose clients that disable or simply don't even know what javascript is.
While it is a bit late to close the door on JS usage within SMTP protocol, choices of client SMTP becomes paramount given its legacy stage of SMTP protocol.
again, the protocol should be dumb, its a way to move bytes. If there is js encoded in those bytes the rotocol will not and should not know or care. It's up to a client do decide what it wants to do with the bytes it receives.
the client should be responsible for not executing embedded JS in a message
> JavaScript, embedded, in email is, pejoratively, a bad idea by putting too much power into a transmitted email
The exploits writers would like to politely disagree. /s
The exploits writers would like to politely disagree. /s
You cannot read this email until you disable your adblocker.
Let's be honest, it's IMAP that sucks bad. What neolithic shit is it that a single letter can't exist in multiple "folders".
Does the Outlook Sync Tool work for you?
It has it's own quirks, but you don't have the Google IMAP weirdness.
https://support.google.com/a/users/answer/171710?hl=en
It has it's own quirks, but you don't have the Google IMAP weirdness.
https://support.google.com/a/users/answer/171710?hl=en
Jup. Even using thunderbird with a gmail account it's not great. Google insists on displaying my emails in multiple locations; among others, sent emails show up in the default inbox folder. WTF google?
Anyhow, I am so happy I recently took the time to set up thunderbird for my gsuite account at work. I've been using thunderbird for a long time privately and the UX is just so much better than gmail, it really improved my quality of life during work hours.
Anyhow, I am so happy I recently took the time to set up thunderbird for my gsuite account at work. I've been using thunderbird for a long time privately and the UX is just so much better than gmail, it really improved my quality of life during work hours.
It's not that Google insists, it's that IMAP is antiquated and JMAP doesn't fix it either. Same letter in multiple "folders" should've been added to IMAP/JMAP aeons ago.
So why didn't google add it to IMAP when they added the feature to their mail system? There is no point in clients adding support for label-like folders if there is no server using that extension including the servers that do actually have labels. Gmail on the other hand is big enough that by now most non-Outlook clients would have picked up support.
Because IMAP is not theirs to dictate.
Maybe if someone standardised such an extension they'd add support. Considering how ossified email is, they rightfully have little interest to do it alone.
Maybe if someone standardised such an extension they'd add support. Considering how ossified email is, they rightfully have little interest to do it alone.
I want to like Outlook, even on my Mac. But it doesn't handle quoting in replies the way I want it to, and I have several correspondents whose email chains get heavily into replies to replies.
I mostly use Apple Mail, which is acceptable, if not great. I guess I need to look at Thunderbird (which I haven't looked at since I've been using a Mac) and, maybe, Vivaldi.
I mostly use Apple Mail, which is acceptable, if not great. I guess I need to look at Thunderbird (which I haven't looked at since I've been using a Mac) and, maybe, Vivaldi.
I don't really understand corporations using gmail. Don't you have fears that your company secrets get leaked? Perhaps that isn't an issue for software but I would not be so sure.
AWS does industrial espionage, Google probably does too... Not that the encroaching reliance on Microsoft is much smarter...
AWS does industrial espionage, Google probably does too... Not that the encroaching reliance on Microsoft is much smarter...
It's simply not a concern. Google weaponizing Gmail against competition would be the biggest self-own the company could possibly undertake. Overnight they'd lose the trust of corporations in general, which would cost them the enterprise business, the Cloud business, and a non-insignificant chunk of the ads business.
Google is desperate to find a revenue tent-pole that even approaches the value of ads, and they've bet heavily on that tent-pole being Cloud. Any short-term gains they could acquire from cracking open a user's email would be dwarfed by the long-term losses from ruining their reputation as a reliable keeper of secrets, and they need that reputation to trade in the Cloud space at all.
Google is desperate to find a revenue tent-pole that even approaches the value of ads, and they've bet heavily on that tent-pole being Cloud. Any short-term gains they could acquire from cracking open a user's email would be dwarfed by the long-term losses from ruining their reputation as a reliable keeper of secrets, and they need that reputation to trade in the Cloud space at all.
Maybe. AWS very likely did spy on customers. They met with startups and let them use their infrastructure. Then they launched their own service. They also host data centers for UK spy agencies. Industrial espionage is one of the largest field for these agencies. Doesn't have to be a chip like the Chinese used. And you wouldn't know anyone spied on you.
While talking about email, don't underestimate the need for calendar integration.
There are many projects that start solving "Inbox" before they get in to the abyss that is calendar management and fall flat.
There are many projects that start solving "Inbox" before they get in to the abyss that is calendar management and fall flat.
Do we need better email/calendar integration? Or do we need more separation? Why are we relying on email to get meeting invites?
What's the alternative?
Okay so how do you solve for calendar <-> inbox integration?
What I want is a unified (?) comms client. Email, SMS, RSS, notifications, etc. in a single dashboard.
They all have the very similar properties. Sender / source, subject, body, attachments, etc.
And I want to make it easy to tag / organize them. Maybe a tab for each type + tags within each. Search across all (since too often I forget the medium of a particular msg)
Finally, I don't want the provider of this service / client reading the content and generally probing the sphincter of my privacy.
They all have the very similar properties. Sender / source, subject, body, attachments, etc.
And I want to make it easy to tag / organize them. Maybe a tab for each type + tags within each. Search across all (since too often I forget the medium of a particular msg)
Finally, I don't want the provider of this service / client reading the content and generally probing the sphincter of my privacy.
Thunderbird once had a chat extension that worked great. It supported the big protocols - including Yahoo, AOL, XXMP, MS Messenger, and IRC I believe and a whole slew of lesser known protocols. I had to stop using it when the world embraced Skype and everyone moved there, probably around 2006 or so I think.
Today, most chat protocols have the same flaw as Skype: hostility towards third party clients.
Today, most chat protocols have the same flaw as Skype: hostility towards third party clients.
Thunderbird still has chat-support out of the box. I use it for XMPP and IRC. And it also still supports Newsfeeds, but I would say it could be improved on that part.
I've been using matterbridge[1] to bring all sorts of 'modern' non-standard-compliant chat services back to my irc client[2]
[1] https://github.com/42wim/matterbridge
[2] https://xkcd.com/1782/
[1] https://github.com/42wim/matterbridge
[2] https://xkcd.com/1782/
I pretty much have this setup currently:
Email hosted by a 3rd party (like migadu or purelymail) then moved my cell number over to voip.ms, which sends all texts and voicemails to me via email, where I can now respond to texts via my email client. Then I use feedmail to have all my rss and social feeds email the full text and images to me in either a digest or when they are published.
I have to say I've been loving it. I'm currently setting up notmuch and alot as my mail indexer/sorter and commandline viewer, too.
Email hosted by a 3rd party (like migadu or purelymail) then moved my cell number over to voip.ms, which sends all texts and voicemails to me via email, where I can now respond to texts via my email client. Then I use feedmail to have all my rss and social feeds email the full text and images to me in either a digest or when they are published.
I have to say I've been loving it. I'm currently setting up notmuch and alot as my mail indexer/sorter and commandline viewer, too.
Sounds like the next major version of Thunderbird might suit you.
What's in that version?
Check out the roadmap.
Here are the features mentioned in the GP post:
* Unified client for Email, SMS, RSS, notifications
* Easy to tag / organize mail.
* Service provider cannot read content
* https://developer.thunderbird.net/planning/roadmap
* Firefox Sync (Expected Delivery: Q4 2022)
* Unified Toolbar (Expected Delivery: Q4 2022)
* App Menu (Expected Delivery: Q3 2022)
* Mail Tab Redesign (Expected Delivery: Q4 2022 / Q1 2023)
* Link Preview Card Improvements (Expected Delivery: Q4 2022)
* Account Setup Hub (Expected Delivery: Q4 2022)
* Customizable Shortcuts (Expected Delivery: Q4 2022)
* Calendar UI (Expected Delivery: Q1 2023)
Modernizing the existing feature set, bringing in Firefox Sync to allow syncing settings, tags et al. Even got an Android client for Thunderbird coming down the pipe.
Lack of syncing read/unread state is what stops me from using Thunderbird for RSS currently, but this would change it to my go-to app for most things.
Lack of syncing read/unread state is what stops me from using Thunderbird for RSS currently, but this would change it to my go-to app for most things.
None of that addresses GP posts' specific concerns.
Yes it does. Unified comms via Matrix, which bridges SMS, Facebook Messenger and much more into a single pane. RSS? Yup. Notifications via Matrix, SMS and RSS? Yup. Exactly what he's asking for, and they're modernizing it and adding sync too.
XMPP support
Well, e-mail has different uses, I do use mutt and I send plain text email, but I understand sending newsletter with "nice" format in HTML. I am happy that many includes a "view link" I can just open in my browser if I want to read it.
I use lynx for html formatting, which works, except with long confirmation link, for this I use urlscan[1] which let me browse and open links.
I don't think email must be loved or hated, it's not black and white, it is an old protocol with lots of problems, but it's also the only working federated protocol (and I do operate my own email server with 0 issues, google/ms never rejected me) which is an important freedom.
I agree that many client have bad UX, but many have nice UX, and you are free to use what you want, even if you have a gmail account.
[1]: https://github.com/firecat53/urlscan
I use lynx for html formatting, which works, except with long confirmation link, for this I use urlscan[1] which let me browse and open links.
I don't think email must be loved or hated, it's not black and white, it is an old protocol with lots of problems, but it's also the only working federated protocol (and I do operate my own email server with 0 issues, google/ms never rejected me) which is an important freedom.
I agree that many client have bad UX, but many have nice UX, and you are free to use what you want, even if you have a gmail account.
[1]: https://github.com/firecat53/urlscan
> the only working federated protocol
Even if you're going to discount HTTP, DNS, and IRC for failing to meet various criteria from some definition of "federated", I think we mustn't overlook Matrix here.
Sure, you can claim that email is the most popular working federated protocol, or the oldest, or the best, and you could make some weird restriction like "only popular federated store-and-forward protocol", but I'm not sure if that's a helpful distinction.
The rest of what you say makes perfect sense though, thank you.
Even if you're going to discount HTTP, DNS, and IRC for failing to meet various criteria from some definition of "federated", I think we mustn't overlook Matrix here.
Sure, you can claim that email is the most popular working federated protocol, or the oldest, or the best, and you could make some weird restriction like "only popular federated store-and-forward protocol", but I'm not sure if that's a helpful distinction.
The rest of what you say makes perfect sense though, thank you.
Yes I did not mention DNS or BGP but I could have. I do not agree about IRC because networks are not connected together, yes it is not stricly the protocol fault.
I do agree with matrix, but it still has a lot to improve before I would consider it working. I tried multiple time to get non technical users on it but it is too hard for them. And it is not a client problem but more an account problem.
I do agree with matrix, but it still has a lot to improve before I would consider it working. I tried multiple time to get non technical users on it but it is too hard for them. And it is not a client problem but more an account problem.
> And it is not a client problem but more an account problem.
That's interesting, thank you. For what it's worth, it looks like Matrix is going to become much more user-friendly in the coming months[0], and it will be worth taking another look at this "account problem" once they support Open ID Connect (which is also mentioned in that blog post, and has a dedicated progress page[1]).
[0] https://matrix.org/blog/2022/08/15/the-matrix-summer-special...
[1] https://areweoidcyet.com/
That's interesting, thank you. For what it's worth, it looks like Matrix is going to become much more user-friendly in the coming months[0], and it will be worth taking another look at this "account problem" once they support Open ID Connect (which is also mentioned in that blog post, and has a dedicated progress page[1]).
[0] https://matrix.org/blog/2022/08/15/the-matrix-summer-special...
[1] https://areweoidcyet.com/
Yes I think matrix will get there. The issue is complicated because most people just want to use their phone number, while I (and other tech people) want an account we can use without my phone. There is also contact import/sync, data backup, not having to deal with encryption "at all"...
I emphatically agree that E-Mail clients suck, to the point of wondering whether I should build an E-Mail client (my answer is "probably not").
Instead I did the second best thing and came up with some user styles to make one of the better hosted E-Mail clients, IO.OX (B2B software used by mailbox.org and Strato), a bit more bearable and almost even comfortable: https://gist.github.com/solarkraft/6afcfff8d5283cefad40695c9...
Instead I did the second best thing and came up with some user styles to make one of the better hosted E-Mail clients, IO.OX (B2B software used by mailbox.org and Strato), a bit more bearable and almost even comfortable: https://gist.github.com/solarkraft/6afcfff8d5283cefad40695c9...
I wrote a console-based modal email-client, which was written in 50% C++ and 50% Lua for the user-interface and all scripting.
My advice to anybody considering writing an email client would be .. don't. The amount of broken MIME things you'll have to deal with, strong opinions on UI, and similar things will make you go crazy.
I used to use mutt, then my own client. These days there are a few console-based clients that are new such as aerc, but even so writing the basics is easy, but coping with real mail is way harder than you'd expect
My advice to anybody considering writing an email client would be .. don't. The amount of broken MIME things you'll have to deal with, strong opinions on UI, and similar things will make you go crazy.
I used to use mutt, then my own client. These days there are a few console-based clients that are new such as aerc, but even so writing the basics is easy, but coping with real mail is way harder than you'd expect
> The amount of broken MIME things you'll have to deal with, strong opinions on UI, and similar things will make you go crazy.
Would it make more sense to first build a bunch of libs, to create a common ground, onto which people could more easily build their customized clients?
Would it make more sense to first build a bunch of libs, to create a common ground, onto which people could more easily build their customized clients?
Python's email libraries are pretty complete.
Email clients are absolutely terrible. If the best we can do is Thunderbird, a slow-moving almost abandonware monolith (have a look at its extension store. It's a ghost town), the situation is dire.
Webmail is good enough, but PWA implementation across operating systems is terrible as well. I keep Fastmail pinned in a browser tab, and let's hope I don't close the browser.
I hear CLI email clients are great, but the latest startup newsletter didn't get the memo and I keep receiving HTML emails with images, and I don't want to live in the terminal either.
Webmail is good enough, but PWA implementation across operating systems is terrible as well. I keep Fastmail pinned in a browser tab, and let's hope I don't close the browser.
I hear CLI email clients are great, but the latest startup newsletter didn't get the memo and I keep receiving HTML emails with images, and I don't want to live in the terminal either.
Thunderbird isn’t almost abandonware.
It literally was abandonware for several years.
It was only recently resurrected by 1-2 devs a few years ago and they’ve had to rebuild the community, funding and contributor support.
The fact that Thunderbird worked perfectly well even while being abandonware is a testament to Thunderbird and email.
I think the last part they really need to get completed is separation from the Firefox code. We’re already seeing accelerating delivery of features which should hopefully improve.
It literally was abandonware for several years.
It was only recently resurrected by 1-2 devs a few years ago and they’ve had to rebuild the community, funding and contributor support.
The fact that Thunderbird worked perfectly well even while being abandonware is a testament to Thunderbird and email.
I think the last part they really need to get completed is separation from the Firefox code. We’re already seeing accelerating delivery of features which should hopefully improve.
I've used Thunderbird for probably like 15 years now and this is the first time I'm hearing that it ever was abandonware. At no point during that time did I not like it much better than all alternatives. Pretty impressive given that it apparently wasn't being developed for several years.
You might have noticed that there was a period during which none of your extensions or add-ons stopped functioning? That was the abandonware period.
Now that it's ended once again some of my extensions have stopped functioning.
Now that it's ended once again some of my extensions have stopped functioning.
Good to see that the new developers are continuing Mozilla's legacy.
I do have to agree tho. They force-upgraded from Enigmail to the built-in PGP support which ended up broken for me. Since no one uses PGP mail I haven't bothered looking for a fix...
I do have to agree tho. They force-upgraded from Enigmail to the built-in PGP support which ended up broken for me. Since no one uses PGP mail I haven't bothered looking for a fix...
Does the Thunderbird calendar work as good as outlook for you? Does calendar invites and other communication programs have good integration with Thunderbird?
At my last gig I used a paid extension called owl to sync with outlook, even though the company did not support anything other than MS Outlook or the Office 365 web interface. It was not expensive and worked terrifyingly, even syncing the company calendar and address books.
I honestly can't be sure if terrifyingly was a typo here. Perhaps for terrifically..
I swear this Note 10 changes words that are a few words back. I've had similar "corrections" ever since I changed to this device. It's too late to edit now.
I'm going to experiment recording the screen while I type to confirm or deny this.
I'm going to experiment recording the screen while I type to confirm or deny this.
I always hear this brought up but how essential to emailing is calendaring? Is exchange support built in to mutt or pine?
Calendaring is very much important. How will I schedule meetings? Meetings, appointments are the most important things in business these days.
> How will I schedule meetings?
I suggest using a calendar.
I suggest using a calendar.
What about sending meeting invites via email?
> If the best we can do is Thunderbird
What about KMail/Kontact? Evolution? Sylpheed Claws? The Client of the Vivaldi(?) Browser? Not to forgotten all the commercial clients. Are they all dead or trash?
> a slow-moving almost abandonware monolith (have a look at its extension store. It's a ghost town)
To be fair, Thunderbird has a complicated history. The unloved child of Mozilla, survived far too long on it's own, until it got love again, at the time when the parent moved away from XUL, giving the future of Thunderbird-extensions a timelimit. That it's still surviving on high levels is more of a miracle.
What about KMail/Kontact? Evolution? Sylpheed Claws? The Client of the Vivaldi(?) Browser? Not to forgotten all the commercial clients. Are they all dead or trash?
> a slow-moving almost abandonware monolith (have a look at its extension store. It's a ghost town)
To be fair, Thunderbird has a complicated history. The unloved child of Mozilla, survived far too long on it's own, until it got love again, at the time when the parent moved away from XUL, giving the future of Thunderbird-extensions a timelimit. That it's still surviving on high levels is more of a miracle.
I wouldn’t say it is because it is a miracle, but because it still focuses on being an e-mail client. In Ubuntu kmail requires a database server and groupware.
If you accidentally close that Fastmail tab, just open another one. You will lose nothing.
You can be logged into Fastmail from several devices simultaneously. And I often have several Fastmail tabs open at one time. No problem at all.
The only thing better than Fastmail webmail is the Fastmail app for iOS.
You can be logged into Fastmail from several devices simultaneously. And I often have several Fastmail tabs open at one time. No problem at all.
The only thing better than Fastmail webmail is the Fastmail app for iOS.
(al)pine is pretty good.
Here's a talk from one of the heads of Fastmail: "Email Hates the Living"
https://www.youtube.com/watch?v=4s9IjkMAmns
Email itself is a very weird quirk filled system. If you want to read about the insanity behind some of the protocols watch that talk. That's why things like JMAP are being developed.
https://www.youtube.com/watch?v=4s9IjkMAmns
Email itself is a very weird quirk filled system. If you want to read about the insanity behind some of the protocols watch that talk. That's why things like JMAP are being developed.
I liked the article. The author seems to have the same attitudes and preferences about software that I do. But, does Wired have a policy that forbids linking to anything that’s not another Wired article? The piece contains only two hyperlinks, both pointing to Wired. One of the main points of the Web is that it’s a web of information. Every piece of software he talks about has a web page, and plenty of good articles and tutorials about it; there are certainly other interesting articles talking about the issues the author talks about. Why does Wired hate the web?
Not to mention the auto-playing video stuffed between two paragraphs. I wanted to upvote the article for its message but I can’t in good faith recommend anyone visit this site with its current aggression.
Yeah, that was ridiculous. A random video that has nothing to do with the article. Contempt for the reader and for the author and the material.
Publishers will respond to criticism like this by claiming that economic realities force them to avoid linking outside the site and to use obtrusive advertising and self-promotion. But there are plenty of counterexamples: LWN, for example, links extensively in every article to destinations all over the web and uses none of these user-hostile techniques—and their content is varied and at a consistently high level.
Publishers will respond to criticism like this by claiming that economic realities force them to avoid linking outside the site and to use obtrusive advertising and self-promotion. But there are plenty of counterexamples: LWN, for example, links extensively in every article to destinations all over the web and uses none of these user-hostile techniques—and their content is varied and at a consistently high level.
With uBlock Origin blocking (by default) the javascript that wired serves, I read the whole article and was only aware of an auto-play video even being present when I read your comment.
Good for us? (Yes, I too browse without scripting.) Their offense still exists and we should be careful not to shift blame and the burden of defense to users.
Recently switched from the Gmail web UI to Thunderbird (backed by Gmail IMAP). I don't think I could ever go back---for the first time in many years my inbox is getting the attention it deserves. I've cleaned up the junk mail, added a bunch of folders and filters, and it's a whole different world.
Definitely Thunderbird could be better than it is. But it's definitely better than what it's replacing, at least for my use.
Definitely Thunderbird could be better than it is. But it's definitely better than what it's replacing, at least for my use.
I haven't used Thunderbird in 10-20 years. Why does Thunderbird allow you do that, but not Gmail? My personal Gmail account has ~350 folders (labels) and ~300 filter rules. One of my previous work GSuite accounts had probably 1000-2000 labels and filters.
I migrated from Outlook to Gmail, and I found that I could process 2-4X the amount of emails as I could on Outlook. The key feature for me was the vi-key bindings in Gmail.
I migrated from Outlook to Gmail, and I found that I could process 2-4X the amount of emails as I could on Outlook. The key feature for me was the vi-key bindings in Gmail.
Thunderbird is awesome. One feature I love is that you can use Darkreader to make emails dark mode.
Email is bad for various reasons, but being open and universal is far better than anything else.
MUAs on contrary suck because people have never touched the power of desktops and so they shift blindly and acritically toward webmails for the sake of few giants and as a result most MUAs are stuck in the late '90s at best. Modern ones are just small projects by very small community (like notmuch, mu), too small and geeky to develop a full automation to give something working out-of-the-box for most users.
Another problem is that people still fail to understand their assets. They understand something physical they own, like cash money in their pockets, but they fail with digital assets, so most people fails to understand the value of their mails, from address/domain (like a personal one vs some from GAFAM&alike) to messages and so fails to comprehend why having local mails is important...
We need, for the sake of the society, to improve people knowledge/culture about the tools they need in current daily life, otherwise even a modern MUA will simply be a big effort of few with not much future.
MUAs on contrary suck because people have never touched the power of desktops and so they shift blindly and acritically toward webmails for the sake of few giants and as a result most MUAs are stuck in the late '90s at best. Modern ones are just small projects by very small community (like notmuch, mu), too small and geeky to develop a full automation to give something working out-of-the-box for most users.
Another problem is that people still fail to understand their assets. They understand something physical they own, like cash money in their pockets, but they fail with digital assets, so most people fails to understand the value of their mails, from address/domain (like a personal one vs some from GAFAM&alike) to messages and so fails to comprehend why having local mails is important...
We need, for the sake of the society, to improve people knowledge/culture about the tools they need in current daily life, otherwise even a modern MUA will simply be a big effort of few with not much future.
I agree with a lot of what you said.
I think quite a few MUAs could absolutely be rescued from their shadow death, if funded properly (and if they're capable of being funded). It's just that I personally haven't seen a strong candidate yet. I don't like any of them, they are irritating. Aerc is promising, but CLI is simply not for everyone. Then Thunderbird was on life support for a while, maybe if it gains some speed again? I'm not sure.
So lack of support from users is one side of the coin. But the other side, developers and companies doing email, I don't know if that can be fixed. Sidelined maybe. There's just an immense amount of feet-dragging and archaisms in the ecosystem. "We can't because others don't" - everyone. Can't enforce TLS, can't enforce SPF, can't enforce basically any standards that would improve the quality of the ecosystem. When was the last email-related flag day?
Enough of that rant, it's just a bit frustrating. Forced to use with no visible QoL improvements.
I think quite a few MUAs could absolutely be rescued from their shadow death, if funded properly (and if they're capable of being funded). It's just that I personally haven't seen a strong candidate yet. I don't like any of them, they are irritating. Aerc is promising, but CLI is simply not for everyone. Then Thunderbird was on life support for a while, maybe if it gains some speed again? I'm not sure.
So lack of support from users is one side of the coin. But the other side, developers and companies doing email, I don't know if that can be fixed. Sidelined maybe. There's just an immense amount of feet-dragging and archaisms in the ecosystem. "We can't because others don't" - everyone. Can't enforce TLS, can't enforce SPF, can't enforce basically any standards that would improve the quality of the ecosystem. When was the last email-related flag day?
Enough of that rant, it's just a bit frustrating. Forced to use with no visible QoL improvements.
Try notmuch-emacs to see a modern one:
- search based, entirely
- tags, like GMail labels NOT folders, while they are equally integrated in search (just folder: instead of tag:)
The issue:
- does not embed ANYTHING to fetch your mails, so you need something else to do so, like OfflineIMAP/mbsync or fetchmail etc
- does not touch files so you need wrappers to delete/refile etc them
Why? Because no one have felt the need to integrate to help new users...
Similarly no modern UI, there is a semi-abandoned WebUI, Astroid a webkit/GTk GUI, but almost no one develop them...
- search based, entirely
- tags, like GMail labels NOT folders, while they are equally integrated in search (just folder: instead of tag:)
The issue:
- does not embed ANYTHING to fetch your mails, so you need something else to do so, like OfflineIMAP/mbsync or fetchmail etc
- does not touch files so you need wrappers to delete/refile etc them
Why? Because no one have felt the need to integrate to help new users...
Similarly no modern UI, there is a semi-abandoned WebUI, Astroid a webkit/GTk GUI, but almost no one develop them...
It reads like an advert for Vivaldi. I dont have any issues with Vivaldi, but the content of the article is clearly "clickbait" with "Mutt" for the comparison. Highly avoidable write up.
Speaking of clients, I like Hey. I just like it, and have discretionary income to spend on an important tool shrug
The same here. I use it with the wife, and we even use it for her mother’s shop. Worked great, except for the need of having an smtp server for available to sent email from services ( calendar notification, error, printer message, nas update…)
Still, love Hey. Expensive, but so good.
Still, love Hey. Expensive, but so good.
Same! I’ve been using HEY for a couple years now. I hope they do something similar for my calendar needs.
smtp sucks hard though. Pretty much the only major protocol that never got upgraded (along DNS until DNS over https). Dysfunctional encryption (as in optional, easily downgradable), no assurance on the identity of the sender, bad interoperability (the likes of gmail sending directly to spam folder half of the domains).
It's not quite that bad; you can use SMTP over TLS (without the downgradable STARTTLS, plus there's REQUIRETLS now), and there's been plenty of extensions over the years (like SMTPUTF8). Identity verification has been handled in another layer (the message itself); you could argue that's not the best place, but it is there. And gmail's problems are gmail's problems.
The entire world still runs on DNS; as an end-user you can now use DNS-over-HTTPS and that's nice, but that's mostly a frontend for DNS, which as a whole hasn't really been "upgraded". Upgrading SMTP to something new would require upgrading all the world's email servers, otherwise mail.server1.com can't communicate with mail.server2.com. This will probably happen at the same speed as IPv6.
The entire world still runs on DNS; as an end-user you can now use DNS-over-HTTPS and that's nice, but that's mostly a frontend for DNS, which as a whole hasn't really been "upgraded". Upgrading SMTP to something new would require upgrading all the world's email servers, otherwise mail.server1.com can't communicate with mail.server2.com. This will probably happen at the same speed as IPv6.
TLS without the certificate verification is still vulnerable to MITM.
You get basically the same security level with gpg and plaintext email as you do from email over TLS if someone is trying to MITM.
Even this REQUIRETLS that you mention that I didn't know about before looks iffy. If the problem is that upgrading all the world's email servers is too onerous, that still would pretty much have to happen here to support the new smtp extension. DNSSEC for the MX record or this MTA-STS record. It would require each hop in the path to be equally strict in implementing REQUIRETLS unless you want to randomly drop that assurance somewhere in the middle of the route. If all the servers have to be updated to do this, is it really that much more difficult to just switch to a new protocol entirely to be secure by default?
Not to mention that as a store and forward protocol, any server hop along the way may store or copy the message at rest in plaintext. If DKIM isn't used to checksum the message, it can be modified too unless there's some mechanism here for that that I'm missing.
If every email server needs an infinity gauntlet full of plugins and extensions and DNS records to just have some assurance of the sender's or recipient's validity, how is that really better than just making something new?
It's just not made to be a secure protocol. Someone please correct me if I'm misreading the RFC, but can we please, please let smtp die some day?
Even this REQUIRETLS that you mention that I didn't know about before looks iffy. If the problem is that upgrading all the world's email servers is too onerous, that still would pretty much have to happen here to support the new smtp extension. DNSSEC for the MX record or this MTA-STS record. It would require each hop in the path to be equally strict in implementing REQUIRETLS unless you want to randomly drop that assurance somewhere in the middle of the route. If all the servers have to be updated to do this, is it really that much more difficult to just switch to a new protocol entirely to be secure by default?
Not to mention that as a store and forward protocol, any server hop along the way may store or copy the message at rest in plaintext. If DKIM isn't used to checksum the message, it can be modified too unless there's some mechanism here for that that I'm missing.
If every email server needs an infinity gauntlet full of plugins and extensions and DNS records to just have some assurance of the sender's or recipient's validity, how is that really better than just making something new?
It's just not made to be a secure protocol. Someone please correct me if I'm misreading the RFC, but can we please, please let smtp die some day?
> If all the servers have to be updated to do this, is it really that much more difficult to just switch to a new protocol entirely to be secure by default?
The 80:20 solution here might be for the big email providers to declare a flag day (maybe with a 2 year countdown) saying that any email server they connect to after that date has to support TLS, or they will delay the processing of emails to/from that server by 5 minutes, doubling every 6 months.
Also, such servers will be named and shamed in their webmail interfaces, so users get a nasty red warning whenever you try to send an email to an affected address or receive one from it. I bet the problem would actually be 99% solved before the flag day even arrived, and most of the remaining 1% would be spam anyway.
The 80:20 solution here might be for the big email providers to declare a flag day (maybe with a 2 year countdown) saying that any email server they connect to after that date has to support TLS, or they will delay the processing of emails to/from that server by 5 minutes, doubling every 6 months.
Also, such servers will be named and shamed in their webmail interfaces, so users get a nasty red warning whenever you try to send an email to an affected address or receive one from it. I bet the problem would actually be 99% solved before the flag day even arrived, and most of the remaining 1% would be spam anyway.
> TLS without the certificate verification is still vulnerable to MITM.
By that standard all of https and ssh are insecure too...
By that standard all of https and ssh are insecure too...
I'm not sure what you're getting at. Properly configured https verifies the certificate's CA signature. Now it's true that that's only as secure as the web of trust that is the certificate authority system, but that's a whole other ball of wax. Smtp with TLS just doesn't check, except perhaps this new REQUIRETLS if implemented with all that extra configuration. For most of the smtp TLS already in use out there, it doesn't care if it's a CA signed cert or a self-signed cert. It's not verifying anything about identity.
With ssh it is trust on first use by default, so you kind of have a point with that, but:
1. Ssh then remembers that host key and alerts if it changes to protect against MITM of future connections, whereas smtp over TLS just... doesn't check as far as I'm aware.
2. Ssh implemented certificates a while back using an ssh certificate authority, and thus can work more like https where host key signatures are pre-trusted, or can even issue temporary credentials through something like Vault.
These things are not the same.
With ssh it is trust on first use by default, so you kind of have a point with that, but:
1. Ssh then remembers that host key and alerts if it changes to protect against MITM of future connections, whereas smtp over TLS just... doesn't check as far as I'm aware.
2. Ssh implemented certificates a while back using an ssh certificate authority, and thus can work more like https where host key signatures are pre-trusted, or can even issue temporary credentials through something like Vault.
These things are not the same.
> Properly configured https verifies the certificate's CA signature.
That's also what properly configured SMTP over TLS does. Maybe some clients don't verify the certificate, but that's on the clients and not the protocol.
That's also what properly configured SMTP over TLS does. Maybe some clients don't verify the certificate, but that's on the clients and not the protocol.
Verification was not required as a matter of protocol until a new standard for MTA-STS was published in 2018. Without this new standard configured, as is going to be the case for most organizations out there not on the bleeding edge, TLS over smtp has been opportunistic and not verified the certificates or strictly enforced verification.
https://www.digitalocean.com/community/tutorials/how-to-conf...
The additional daemon that it looks like postfix requires to support this new standard, postfix-mta-sts-resolver, had its 1.0.0 tagged version release in Jun 13, 2020. This does not and would not represent the vast majority of extant deployed smtp over TLS configurations out there.
This right here is still in the README for postfix, one of the most popular MTAs in use:
>Despite the potential for eliminating "man-in-the-middle" and other attacks, mandatory certificate trust chain and subject name verification is not viable as a default Internet mail delivery policy. Some MX hosts do not support TLS at all, and a significant portion of TLS-enabled MTAs use self-signed certificates, or certificates that are signed by a private Certification Authority. On a machine that delivers mail to the Internet, you should not configure mandatory server certificate verification as a default policy.
That's a very load bearing "properly" in your sentence and I wonder just what you're referencing.
Edit: and another good writeup. https://lwn.net/Articles/866481/
The additional daemon that it looks like postfix requires to support this new standard, postfix-mta-sts-resolver, had its 1.0.0 tagged version release in Jun 13, 2020. This does not and would not represent the vast majority of extant deployed smtp over TLS configurations out there.
This right here is still in the README for postfix, one of the most popular MTAs in use:
>Despite the potential for eliminating "man-in-the-middle" and other attacks, mandatory certificate trust chain and subject name verification is not viable as a default Internet mail delivery policy. Some MX hosts do not support TLS at all, and a significant portion of TLS-enabled MTAs use self-signed certificates, or certificates that are signed by a private Certification Authority. On a machine that delivers mail to the Internet, you should not configure mandatory server certificate verification as a default policy.
That's a very load bearing "properly" in your sentence and I wonder just what you're referencing.
Edit: and another good writeup. https://lwn.net/Articles/866481/
You've been able to configure Postfix to verify TLS for ages; you don't need some new daemon for that. I've written plenty of email systems over the years and have always verified certificates (unless explicitly told not to by the user) and that works just fine.
You're confusing a lot of things that are related but actually quite distinct. That DigitalOcean article talks about STARTTLS, but that's something different than SMTP over TLS. I haven't worked that much with email in the last few years so haven't looked at MTA-STS in detail, but it just seems similar to setting a "always require a TLS connection"; that new Postfix service just looks up the DNS records and such; it's not required for TLS functionality.
You're confusing a lot of things that are related but actually quite distinct. That DigitalOcean article talks about STARTTLS, but that's something different than SMTP over TLS. I haven't worked that much with email in the last few years so haven't looked at MTA-STS in detail, but it just seems similar to setting a "always require a TLS connection"; that new Postfix service just looks up the DNS records and such; it's not required for TLS functionality.
Okay, you configure Postfix to verify TLS. Validation fails, what will happen? What does the documentation say about that configuration option?
That aside, an active attacker can also trivially force a downgrade.
Only with the introduction of MTA-STS, connections between MTA-MTA are secure. That's supported by, like, few major players - I guess by volume a fine percentage, but by total count, abysmal.
That aside, an active attacker can also trivially force a downgrade.
Only with the introduction of MTA-STS, connections between MTA-MTA are secure. That's supported by, like, few major players - I guess by volume a fine percentage, but by total count, abysmal.
Assuming you mean identity verification is handled with GPG keys, nobody actually uses that in practice. Even the people that use Usenet today mostly don't.
Email identity is handled de facto by a web of trust anchored by the big domains with no possibility of creating a new trust anchor. You're either managed by Google, Microsoft, or Apple and inherit their trust or you play endless games to not get your mails blocked by default. It's a sad world and didn't need to be this way, but there's no real urge to fix things because the only people who are clamoring to fix email are people who want to encourage folks to use niche experiences like mutt and PRs by mail while the incumbents like Google have no incentive to adopt decentralized trust.
Email identity is handled de facto by a web of trust anchored by the big domains with no possibility of creating a new trust anchor. You're either managed by Google, Microsoft, or Apple and inherit their trust or you play endless games to not get your mails blocked by default. It's a sad world and didn't need to be this way, but there's no real urge to fix things because the only people who are clamoring to fix email are people who want to encourage folks to use niche experiences like mutt and PRs by mail while the incumbents like Google have no incentive to adopt decentralized trust.
Mostly meant SPF/DKIM to verify the sender is authorized to send emails for a particular domain. Verifying that "it is actually the person Karrot_Kream who wrote that email" is harder; but I don't think you can blame that on the SMTP protocol.
If you create a smtpv2 that can guarantee encryption (ok, who cares) but mostly that guarantees the origin of the email, then the gmails of this world should go softer on classifying those emails as spam, and it won’t take long before only spammers and some forgotten box in a closet are using the old smtp, then its death would be imminent.
What do you mean "guarantees the origin of the email" though? That it was you who sent it? That you're allowed to send emails from [email protected]? The latter has been solved for some time; the first one is harder, but solvable through GPG or S/MIME, but few seems to have any interest in implementing it.
That won't stop anyone from creating a new email address (or mail server) that sends out spam though.
That won't stop anyone from creating a new email address (or mail server) that sends out spam though.
There's no MUA-STS, there's no good way to enforce TLS for email clients. Most allow errors to be trivially bypassable.
MTA-STS between MTA's does help, but IMHO MTA-MTA is not the biggest issue.
MTA-STS between MTA's does help, but IMHO MTA-MTA is not the biggest issue.
This. SMTP was built upon FTP originally, and it's a protocol designed for ARPAnet, not Internet. SMTP is inherently the wrong protocol for the job. But it keeps working and is the gold standard for email communication and is dead simple to implement, so it keeps being used.
> Dysfunctional encryption (as in optional, easily downgradable)
Better than the HTTP mess where all URLs had to change until people realized that that didn't solve it anyway and had to bolt on HSTS and HSTS preload lists - we just need to add those for SMTP and optional encryption is no longer an issue.
Better than the HTTP mess where all URLs had to change until people realized that that didn't solve it anyway and had to bolt on HSTS and HSTS preload lists - we just need to add those for SMTP and optional encryption is no longer an issue.
Oh boy, never learn about BGP and you'll be much happier.
Well at least BGP is basically an old boy's club so adherence to group rules, not any technical controls, keep the system in check.
> But the biggest win with stand-alone mail clients is that you can make them work the way you want. Most email clients, especially web-based clients like Gmail, have a workflow in mind. If it’s not your workflow, too bad. You can bend them a little bit, but you never really get the freedom to use them the way you want. Vivaldi Mail has some sensible defaults, but just like the web browser it lives inside of, the settings are fully customizable.
> This is the first step in improving your productivity—establishing a software workflow that conforms to your brain’s specific contours.
Well, I don't think any email client will solve my email problems. I forward email messages into my project management apps and deal with them there. I've never found email clients to be particularly good at managing projects.
> This is the first step in improving your productivity—establishing a software workflow that conforms to your brain’s specific contours.
Well, I don't think any email client will solve my email problems. I forward email messages into my project management apps and deal with them there. I've never found email clients to be particularly good at managing projects.
I'd go a step further and say organizational policies are a layer of hassle far above implementations.
In theory if one client sucks you can change client. Not so if your organization throws hissy fits unless you use "web outlook or else because 2FA sth sth".
So on my slow tiny laptop with a shitty connection, instead of using my lovely alpine client which would have been perfect for this laptop, I'm forced to choose between "zoom out until you can't see shit" vs "zoom in until the menu leaves no space for actual email" mode.
In theory if one client sucks you can change client. Not so if your organization throws hissy fits unless you use "web outlook or else because 2FA sth sth".
So on my slow tiny laptop with a shitty connection, instead of using my lovely alpine client which would have been perfect for this laptop, I'm forced to choose between "zoom out until you can't see shit" vs "zoom in until the menu leaves no space for actual email" mode.
I don't know a whole lot about how email works under the hood but...
When the best vendors out there proudly advertise multiple whole integer seconds in average latency in the best case (https://postmarkapp.com/why), I can only assume there's a lot of room for improvement for the protocol itself, and it's not just an issue with clients.
Sending text between servers on the internet shouldn't take this long in 2022.
(And holy crap what's with Apple's 99s latency?)
When the best vendors out there proudly advertise multiple whole integer seconds in average latency in the best case (https://postmarkapp.com/why), I can only assume there's a lot of room for improvement for the protocol itself, and it's not just an issue with clients.
Sending text between servers on the internet shouldn't take this long in 2022.
(And holy crap what's with Apple's 99s latency?)
In the context of email, why does multiple-second latency matter?
I believe the response times of IM chats - something that looks superficially similar to email - affects people's expectations of response times in email.
Just like with web over something like gopher or modern messengers over IRCs, I think the major problem is that too many fancy features are attached to email like html, calendars, calendar invites. Once you stop using them, emails are very pleasant to use. But becomes less convenient as you have to manually intervene to use a calendar invite or view a link or manage contacts. I'm happy with the "less convenient" way of using it.
I'd love to use a non-web-based email client, but I do need it to sync between my devices, including labels, and search to be available over the entire corpus.
Really surprising to see an article about email clients seemingly ignoring the fact that people have multiple devices. You can set your client however you like, sure, but for most people that's useless if it doesn't work the way you like consistently.
E.g. if my labels show up as clunky folder-ish things, no thank you.
Really surprising to see an article about email clients seemingly ignoring the fact that people have multiple devices. You can set your client however you like, sure, but for most people that's useless if it doesn't work the way you like consistently.
E.g. if my labels show up as clunky folder-ish things, no thank you.
I use mutt from my desktops and phone through ssh to my email server running IMAP. (Mutt supports labels.) This way there’s never an issue of synchronization.
IMAP supports keywords/tags that are synchronized among clients.
Wouldn't that work for you?
I can do another survey of email clients and see if support is good enough. Last I did, it wasn't.
The fact that I am using Gmail today will also be a problem, unless Gmail now uses those tags instead of folders to report its labels.
The fact that I am using Gmail today will also be a problem, unless Gmail now uses those tags instead of folders to report its labels.
I misread “email clients” as “clients” and silently agreed.
Then I'm reading your silent thoughts ;)
Joke aside, a lot of the pain from email seem to come from its users. I have to deal with a lot of people who refuse to reply to the list, add their reply inside of the quoted previous message (not interleaved - I mean inside the blockquote), reply to old unrelated threads with a new question, fail to use the subject field ("question", "inquiry", "please help"), have a questionable sender identity (From: "work account (new) <[email protected]>" - whose work account?).
I am not sure this can easily be fixed by improving either the protocol or user interface.
Joke aside, a lot of the pain from email seem to come from its users. I have to deal with a lot of people who refuse to reply to the list, add their reply inside of the quoted previous message (not interleaved - I mean inside the blockquote), reply to old unrelated threads with a new question, fail to use the subject field ("question", "inquiry", "please help"), have a questionable sender identity (From: "work account (new) <[email protected]>" - whose work account?).
I am not sure this can easily be fixed by improving either the protocol or user interface.
People who hate email what is your alternative? What doesn't suck? Carrier pigeons?
No doubt it's going to be IM for most folks.
IM sucks hard. IM used to be great when it was based on open protocols so you could download Trillian on Windows or Adium on Mac and choose your client and communicate across a wide variety of protocols from the same context.
Now you have to download and run massive resource hogging apps like Team and Slack to simply communicate on 2 protocols.
Now you have to download and run massive resource hogging apps like Team and Slack to simply communicate on 2 protocols.
Matrix protocol has over 60m publicly addressable accounts, and that's not even including all the EU gov, healthcare, military or emergency services. You can even bridge closed protocol apps like Messenger, WhatsApp, Discord et al to your own Matrix Synapse server and get it all in a single client. Works great. Been using it for over a year, can even send files back and forth to people still on Messenger.
IM doesn't work unless everyone you want to keep in touch with is also on IM. I have regular, multiple-times-a-week email correspondents who are never on IM. They don't even keep their phones on enough for texting. It's email or nuthin'.
Have you tried talking to the TikTok generation? They don't do email. Most don't even sign into the email clients on their phones.
> Have you tried talking to the TikTok generation? They don't do email.
And before that it was Snapchat! Met some young people who wanted to keep in touch with me a few years ago and had this funny conversation about email after me saying I didn't have Snapchat or Facebook or Instagram or WhatsApp. Oh, you can text me with SMS (that still works!) or email me!
And before that it was Snapchat! Met some young people who wanted to keep in touch with me a few years ago and had this funny conversation about email after me saying I didn't have Snapchat or Facebook or Instagram or WhatsApp. Oh, you can text me with SMS (that still works!) or email me!
There is just no single universally and actually used IM ecosystem and with the expression of unchecked capitalism Web 2.0 has become (see what happened to XMPP), there is no chance there will be one. Besides that the asynchronous nature of e-mail is a highly desirable feature for everyone who has actually things to do.
e-mail is here to stay.
e-mail is here to stay.
> the asynchronous nature of e-mail is a highly desirable feature
This is a good point and makes me wonder whether e.g. Matrix should incorporate something like a “prefers async” field that could be used by clients to treat messages more like mail.
This is a good point and makes me wonder whether e.g. Matrix should incorporate something like a “prefers async” field that could be used by clients to treat messages more like mail.
This is an excellent idea - on a per-conversation granularity at least you could declare whether the intent of the conversation is sync or async, distinguishing IM from mail or forums.
60m publicly addressable users on Matrix protocol, not even including EU gov, healthcare, military, emergency services.
Nobody is saying email is going anywhere.
Nobody is saying email is going anywhere.
Discord
Email clients suck, but we can't pretend that like three major organizations setting the spam policing rules is a good thing for the protocol
> but we can't pretend
Just watch me! Here's what I imagine: These ~three major organizations all get together and announce that from now on, if you register a new domain with an MX record, you have to also put up a bond which can be slashed if they detect you sending spam from your domain.
Okay, there are obviously problems with this, but to address the main ones:
* All existing domains are grandfathered in, so this system only harms businesses that don't exist yet (and thus aren't around to complain)
* The cabal could instead delegate the bond-slashing power to some group of 5 or 9 guardians of the internet, who could be voted on each year by the ITU, with one vote per country
* This would require all domains to support DKIM signing, so that any evidence of spamming could be cryptographically verified, and let's mandate TLS while we're at it
* To make this system truly global, decentralized, and transparent, it will probably have to be implemented using a distributed ledger, which will also prevent a dependency on any specific national currency or banking networks
Just watch me! Here's what I imagine: These ~three major organizations all get together and announce that from now on, if you register a new domain with an MX record, you have to also put up a bond which can be slashed if they detect you sending spam from your domain.
Okay, there are obviously problems with this, but to address the main ones:
* All existing domains are grandfathered in, so this system only harms businesses that don't exist yet (and thus aren't around to complain)
* The cabal could instead delegate the bond-slashing power to some group of 5 or 9 guardians of the internet, who could be voted on each year by the ITU, with one vote per country
* This would require all domains to support DKIM signing, so that any evidence of spamming could be cryptographically verified, and let's mandate TLS while we're at it
* To make this system truly global, decentralized, and transparent, it will probably have to be implemented using a distributed ledger, which will also prevent a dependency on any specific national currency or banking networks
What are they policing besides the very basics you should be doing anyways?
Plenty, but I'm not in the space to speak to specifics.
A personal friend runs MXRoute and they could go on, and on, and on about how maintaining delivery for them is a very expensive venture -- and I promise you they're doing these 'very basics'
At a minimum you'll need several outbound systems with queuing that leverages them. IP reputation is a full time affair
A personal friend runs MXRoute and they could go on, and on, and on about how maintaining delivery for them is a very expensive venture -- and I promise you they're doing these 'very basics'
At a minimum you'll need several outbound systems with queuing that leverages them. IP reputation is a full time affair
IP reputation is done by everyone doing email who aren't tiny, in both directions.
The large players really aren't doing anything special. It's just frequency bias, because you want to deliver to them.
It's also a full-time affair only if you're trying to deliver content people don't want. Yes it takes some effort in all cases because you can't just go on and start blasting, but it's not a full-time effort with those providers.
The large players really aren't doing anything special. It's just frequency bias, because you want to deliver to them.
It's also a full-time affair only if you're trying to deliver content people don't want. Yes it takes some effort in all cases because you can't just go on and start blasting, but it's not a full-time effort with those providers.
Try to send a short and concise email to gmail, especially from a new alias. Instant spam folder. Fill the mail with AI-generated gibberish (or just whatever scam you want) and it's suddenly fine.
Want to send to outlook? Better pony up for a whole /24 or they will drop all your mail from time to time because of a bad neighbor that you have no control over.
That is the kind of policies they are setting.
Want to send to outlook? Better pony up for a whole /24 or they will drop all your mail from time to time because of a bad neighbor that you have no control over.
That is the kind of policies they are setting.
You're surprised that by following the pattern of a dead-average spammer your letters got treated as spam? That was rhetorical, don't answer.
I think you misinterpreted my sentence in one dimension, it's not that they don't require things, it's that everyone does. Build reputation, pick a better neighborhood, you'll be fine.
It's not Google's fault, it's just the vast amounts of abuse they get that follows the exact pattern you did.
I think you misinterpreted my sentence in one dimension, it's not that they don't require things, it's that everyone does. Build reputation, pick a better neighborhood, you'll be fine.
It's not Google's fault, it's just the vast amounts of abuse they get that follows the exact pattern you did.
Google, Microsoft.. who is the third... Yahoo?
I pulled the number out of the air, but sure -- let's call it Yahoo or 'everyone else'
I feel like Google/MS cover the bulk of recipients, the main barriers to running your own MTA
I feel like Google/MS cover the bulk of recipients, the main barriers to running your own MTA
“I also love email, which I’ve always thought of as the digital equivalent of a postcard.”
Postcards would be the equivalent of email if they didn’t require a stamp. And then your mailbox would be full of 5,000 postcards every day from people you don’t know. You can change the mailbox (client) all you want, but it will still be full of junk.
Postcards would be the equivalent of email if they didn’t require a stamp. And then your mailbox would be full of 5,000 postcards every day from people you don’t know. You can change the mailbox (client) all you want, but it will still be full of junk.
I used Apple Mail for years, followed by Thunderbird, Claws Mail, and Outlook on Windows. The switch to Windows was precipitated by the use of some banking apps that only work on Windows. After about 20 years, I've switched back to using Rmail under Emacs. I don't recall the reason for leaving it before, but it's nice to be using it again.
Since this article is mostly about Vivaldi, anyone had significant experience with it? I'm seeing it's based on Electron, weighs half a gigabyte, immediately requests notification permission and fires up a bunch of requests (including to Google's domains, probably safe browsing related) at startup. How does it fare in long-term use?
What suck is what people came to do with email.
Using it as notification system? That is a big no to me.
Using it as notification system? That is a big no to me.
I use emacs as my mail client, with notmuch to search/organize it. w3m to render HTML messages.
Nothing else even comes close as far as being able to efficiently handle any volume of email I've ever received.
Nothing else even comes close as far as being able to efficiently handle any volume of email I've ever received.
While I agree that email clients pretty much all leave something to be desired, it is far from the only problem with email.
The article even alludes to one of the biggest of these problems: lack of encryption.
The article even alludes to one of the biggest of these problems: lack of encryption.
My email problems would be sorted if I wasn't getting tons of spam all of a sudden.
I don't see how my email client can fix persistent spam from random accounts that constantly change their domains.
I don't see how my email client can fix persistent spam from random accounts that constantly change their domains.
Your email client can't, but your email provider can. They can start using more modern filtering software e.g. rspamd, it can become very accurate. Requiring SPF and an MX server works the best against large majority of throwaway domain spammers.
Hence my point, the problems I have are with the provider, not the client.
> A stand-alone email client gives you the same advantages all native applications have over their web-based counterparts: speed, grace, and offline accessibility.
That exactly describes Superhuman.
That exactly describes Superhuman.
No. It’s not UI that causes people to hate email. Email users need to be trained on how to use it effectively within the context of an organization, and it is not a replacement for structured systems like ticketing systems. Cal Newport has some great articles on this, including the odd fact companies supply no training. All messaging platforms devolve to the same dysfunctional mess eventually.
I do share the author’s hatred of webmail, however.
I do share the author’s hatred of webmail, however.
I disagree. You need to seriously re-evaluate things anytime you find yourself saying something along the lines of "X is just fine, we just need to educate and/or train people to use it more effectively." That's a subtle hint that the system you're talking about will never get any better than it is right now. There are two reasons for that:
1) There are people you can't instruct. Aristotle made that observation 2000 years ago and it's still true today.
2) There are bad actors out there who profit from abusing the system.
I'd really like to see the flow control of email completely reversed, where the only people who can send me email are the addresses I have whitelisted. For example, instead of subscribing to an email list, I add the email list's email address to my whitelist. A notification of some sort is then automatically sent to the email list requesting access. The email list can then accept or decline. It would work exactly the same way between two people, getting receipts, etc. Either side could revoke access at any time. Then you could automatically have email from certain accounts go into certain folders, tags, etc.
1) There are people you can't instruct. Aristotle made that observation 2000 years ago and it's still true today.
2) There are bad actors out there who profit from abusing the system.
I'd really like to see the flow control of email completely reversed, where the only people who can send me email are the addresses I have whitelisted. For example, instead of subscribing to an email list, I add the email list's email address to my whitelist. A notification of some sort is then automatically sent to the email list requesting access. The email list can then accept or decline. It would work exactly the same way between two people, getting receipts, etc. Either side could revoke access at any time. Then you could automatically have email from certain accounts go into certain folders, tags, etc.
There were indeed proposals to use RSS pull style polling to replace push style email. But the main drag on productivity of email in a business setting is not external spam, but internal occupational spam from colleagues misusing email and overly verbose automated emails, whether out of cluelessness, incompetence, CYA or whatever other reason. A company would be perfectly justified in settings standards for appropriate use of email.
> A company would be perfectly justified in settings standards for appropriate use of email.
Most companies do. And yet, the problem persists. See the points in my previous comment to understand why.
Most companies do. And yet, the problem persists. See the points in my previous comment to understand why.
I'm kind of surprised no one has mentioned "Hey!" the email service from the Basecamp folks. I haven't had an opportunity to try it, but the UI looks like something that could be replicated locally.
There is also likely some major pushback from people who already have their workflows set just so and any major deviation from "list of items" is going to break that.
There is also likely some major pushback from people who already have their workflows set just so and any major deviation from "list of items" is going to break that.
I'm surprised nobody is mentioning mailmate.
I've used for a year now, life changing.
It just works.
Write markdown, send html.
I just write and becomes nice stuff.
It just works.
Write markdown, send html.
I just write and becomes nice stuff.
But the biggest win with stand-alone mail clients is that you can make them work the way you want
I want my email to show me a list of contacts a-z (no mru). I can filter this list by: have unread messages, are unknown, etc. Sort however I want. Group however I want, “smart” or manually. Omnisearch at the top. No “inbox”, “trash”, “sent”. I can select a contact just like an icq/wa/tg chat and see messages with it to the right. Maybe group messages by subj maybe not. Subj is not mandatory. The client should remove all of the top and bottom auto-citation, automatically extract and update contact info from signatures, remove them and show messages’ meat in bubbles, mine to the right, theirs to the left. Replies, and forwards have links to their “parent”. I can join two email addresses into one contact card, maybe create a subtree. The envelope encryption just works, because the server has a pubkey, either mine or autogenerated and published, or both. I can choose between local storage and cloud storage per device. I can send files >> 20mb, including archives, executables, js files. My known contacts can see if I received/read their message and vice versa. I can ban, mute, hide contacts. I can change/add my address, phone, position, name, etc and contacts will pick that easily, if I allow them see it at all.
So no, I don’t think I can make any email client to work the way I want.
If you think that all of this was inspired by modern messengers, nope. It’s just common sense. The fact is, messengers f’ing nailed it and email as a whole is mostly a slow and unreliable bloatware and doesn’t make much sense. If it were decently designed, there would be no whatsapp and other pure-messaging systems, because we’d already have one.
I want my email to show me a list of contacts a-z (no mru). I can filter this list by: have unread messages, are unknown, etc. Sort however I want. Group however I want, “smart” or manually. Omnisearch at the top. No “inbox”, “trash”, “sent”. I can select a contact just like an icq/wa/tg chat and see messages with it to the right. Maybe group messages by subj maybe not. Subj is not mandatory. The client should remove all of the top and bottom auto-citation, automatically extract and update contact info from signatures, remove them and show messages’ meat in bubbles, mine to the right, theirs to the left. Replies, and forwards have links to their “parent”. I can join two email addresses into one contact card, maybe create a subtree. The envelope encryption just works, because the server has a pubkey, either mine or autogenerated and published, or both. I can choose between local storage and cloud storage per device. I can send files >> 20mb, including archives, executables, js files. My known contacts can see if I received/read their message and vice versa. I can ban, mute, hide contacts. I can change/add my address, phone, position, name, etc and contacts will pick that easily, if I allow them see it at all.
So no, I don’t think I can make any email client to work the way I want.
If you think that all of this was inspired by modern messengers, nope. It’s just common sense. The fact is, messengers f’ing nailed it and email as a whole is mostly a slow and unreliable bloatware and doesn’t make much sense. If it were decently designed, there would be no whatsapp and other pure-messaging systems, because we’d already have one.
Approach to email suck, instead of async communication it is became information duplication and hoarding. I suspect it is come from usenet times. And of course enterprise, managers (and Microsoft) made it 100x worse.
There were attempts to make it sane - like Lotus Notes. Long gone and forgotten.
Is he trying to push an agenda?
Nobody ever said "email sucks", email is the best medium for online communication, look at the countless of projects using mailing lists, you can easily go back in time and follow the discussions, it is so good
What sucks nowadays is spam, that's it
Nobody ever said "email sucks", email is the best medium for online communication, look at the countless of projects using mailing lists, you can easily go back in time and follow the discussions, it is so good
What sucks nowadays is spam, that's it
That's why you need to write your own email client, or help me to polish mine:
https://github.com/derek-zhou/liv
https://github.com/derek-zhou/liv
IMAPv4 definitely could use some improvements and I think there is room for new standards, like JMAP. Email servers should use some form of checksumming on emails to determine changes between clients.
ActivityPub is a better email than email. Wait and see.
> Email doesn't suck – it's email clients that need improving
The wretched hive of scum and villainy that is my postfix quarantine begs to differ.
The wretched hive of scum and villainy that is my postfix quarantine begs to differ.
I've been thinking that a digital stamp could help a lot with email spams. Price it low enough so that it's not a big deal (maybe $0.01 per address on the receiver side?) but enough to enforce cost for spam + marketing emails. Email is an example where the cost of spam is mostly borne by the receiver in terms of time and effort.
What you're describing does exist in a way. Depending on the TLD, domains do cost money. The cheaper the domain, the more positive signals it requires to exit spam folder.
[deleted]
A protocol is only as good as its available clients
Any other popular email clients deteriorating?
Yesterday I tried to search between 2 dates on gmail and it wouldn't work. I tried using their UI to set the dates and it wouldn't work. I had to manually click through 3 years of emails to get to the dates I wanted.
BTW, I only read the title.
BTW, I only read the title.
Any recommendations for an Android email client besides K9?
Thanks installed that one. So much better than K9
Email does suck. It's an insecure mess that is impossible to secure by its very nature. All it takes is one small mistake and your email is sent in plaintext.
It needs to die yesterday.
It needs to die yesterday.
My work computer has a SSL cert from the employer installed allong with the other ones. I don't see any improvement from plaintext. If we need secrecy we need to use encryption.
I don’t see the point in debating protocols when “the suckiness” always comes down to UI/UX
UX that works for async comms and real time comms can be “backed by” HTTP. One does not literally need the data model to conform to the presentation in mind.
“Email” view might be a good default. “Chat view” could be a toggle for when the group is online at the same time.
UX needs a rethink in general. What a designer finds trendy in the moment is user hostile. I want flexibility and customization at the presentation layer. Give me an API key and I’ll build my own UX in Docker containers, thanks.
UX that works for async comms and real time comms can be “backed by” HTTP. One does not literally need the data model to conform to the presentation in mind.
“Email” view might be a good default. “Chat view” could be a toggle for when the group is online at the same time.
UX needs a rethink in general. What a designer finds trendy in the moment is user hostile. I want flexibility and customization at the presentation layer. Give me an API key and I’ll build my own UX in Docker containers, thanks.
Spam. The protocol is insecure. Consolidation of major webmail providers is a huge problem on multiple fronts (censorship, third-party acceptance (of both delivery and non-GmailMicrosoftYahoo email accounts --- my Protonmail service can't talk to GetPocket's support email on Gmail for months, f'rex), spam, account hacking, authentication, repudiability (yes, that coin has two sides), workflow integrations, proprietary workflows, spam, account lockouts, lack of common email formatting and practice standards, HTML email, spam, pervasive surveillance, attachments, spam, mobile access, spam, spam, infinite diversity in proprietary messaging systems and platforms each fractally worse than email in a myrad ways, spam, spam, spam, inbox overflow, spam, spam, spam, spam, email bankruptcy.
I've had an email account nearly continuously since the mid-1980s. I've all but abandoned it in the past decade.
There is no viable replacement on the horizon, though postal mail is looking increasingly attractive.