Live data from Hacker News

The Future of Email

fastmail.com

121–130 of 217 posts

Re: The Future of Email

#121
A little bit off topic but We need dmarc to prevent phone spoofing. STIR/SHAKEN should adopt the DMARC model from email. The legitimate holder of a phone number should be able to publish a policy declaring that any call claiming to originate from their number without A-level attestation must be blocked by the terminating carrier. Just as domain owners can instruct mail servers to reject unauthenticated email sent in their name, number holders should be able to instruct carriers to reject unauthenticated calls spoofing their numbers.

In my experience since phone scammers tend to scam a small subset of numbers like dell, facebook, Microsoft, the Internal Revenue Service, copying this could allow big companies to block a huge number of phishing calls requiring their numbers. Since many calls originate from authenticating carriers now we need to go to the next level and block fake calls.

Re: The Future of Email

#124
post #113

I read this article and was surprised when I reached the end because the whole thing felt like it was setting the stage for some announcement or new thing. But nothing came..? Forgive me if I'm being thick but what was the takeaway?

As a fastmail user I'm glad there was no announcement. Every time a company starts telling me about some bright future, this usually means my user experience is about to sink.

Re: The Future of Email

#125
post #113

I read this article and was surprised when I reached the end because the whole thing felt like it was setting the stage for some announcement or new thing. But nothing came..? Forgive me if I'm being thick but what was the takeaway?

That was how I felt. "The Future of Email", from Fastmail - I immediately assumed some big announcement.

It's basically "you need to pass DMARC now" which has been true for 2 years.

It also goes into how authentication helps stop spoofed domains which yes, is true. But in my opinion the biggest problem isn't spoofed domains at all.

Attackers will figure out how to make your payment platform (PayPal, Stripe, etc) send out emails. They'll figure out what pieces of info make it into the generated emails, so they'll do things like set their company name to "there's a problem call this phone number." So next thing you know you're getting an email from PayPal that sounds urgent because they'll put that company name in the subject or body of the email.

These emails will be legit, from-the-actual-company, passes-all-authentication emails. DMARC can't catch that, and that's what I've been observing attackers do. They'll find a ticketing system or payment processor and get them to generate "authentic" emails.

I was sincerely hoping that Fastmail had something to deal with that problem.

Re: The Future of Email

#127

I find it hard to judge how much, if at all, this will help, but I'm all for email being more secure, to the point that organizations (banks, governments, insurance companies) stop creating walled-email alternatives: please log in to our secure message center, where you can only see our messages poorly formatted, and for a short time, until we permanently delete them . I like that my Inbox is a somewhat-searchable, h…

My bank does a PUSH notification that is "Please log into the app to read an important message", which is usually just my monthly statement or whatever.

And then also sends an e-mail, which sometimes I confuse and think is ANOTHER message, and log in again....

It has a "Download this message as a PDF" button, which just takes you to a web-browser wrapper....

Re: The Future of Email

#128

It's insane that in 2026 signing and encryption of emails still isn't the norm, but as long as the business model of the largest email vendors rely on us not having it, I guess we never will.

In 2026, pushing for encryption of emails is a sign that you care more about box-checking requirements rather than actual security practices. Encrypted email sounds good--it's encrypted, how can that be bad?--but when you actually work through various threats and see what encrypted email protects against, it's really not much compared to the status quo, and encrypted email also turns out to lose a lot of features.

Keep in mind that the baseline is that, when you send an email, it is encrypted from your computer to your email server, your email server to your recipients' email servers, and your recipients' email servers to their computers. The only people other than you and the recipients who can see it are the email servers involved in the middle, so the best you can get with encrypted emails is maybe cutting out some of the entities that have a critical role in the process (and which therefore can't entirely be cut out). In particular, encrypted email leaves all the email headers public, so it's not like the best case here is particularly private.

But encrypted email also breaks the ability to do any server-side processing of email, like server-side email filters (okay, not the hugest loss in the world). Or spam processing--no one's come up with a workable solution here, especially given the vast amount of spam that never hits an email folder (the things that get routed to your spam folder are the emails your spam filters aren't sure is spam). Users also expect the ability to log onto their email server's website and just read their email: such webmail is the dominant email client used, and even people like me who almost exclusively use email clients still end up using a webmail client from time-to-time. You can fix this by giving your email server your key... which puts them back on the list of people who can read your email again, oops, you've gained nothing over the status quo.

Worse still is the problem of key distribution. To send an email, you need to look up the recipients' keys... and the most practical approach to make that work at scale is probably to ask the mail server what its users' public keys are. The one entity that is guaranteed to be able to intercept literally every message to somebody, and thus is in prime position to offer its own key instead, strip the encryption, and re-encrypt it to the user without anybody else finding out. Alternative approaches like keyservers don't work: the PGP keyserver ecosystem collapsed several years ago when PGP encryption was of interest to fewer than a million users, far less scale than the billions of email users.

Encrypted email is a useless pipedream, and not because of the business models of email vendors, but because the architecture of email provides good-enough security today that makes improving on it very challenging without negating the supposed benefits of extra encryption.

Re: The Future of Email

#129
post #113

I read this article and was surprised when I reached the end because the whole thing felt like it was setting the stage for some announcement or new thing. But nothing came..? Forgive me if I'm being thick but what was the takeaway?

Yeah I had the same reaction. From the title I was expecting to find out what the "future of email" is. I'm still waiting.

Re: The Future of Email

#130
post #34

Earlier quoted context omitted.

> Basically you should pre-authorize the senders This is kinda what 'masked email' services like Fastmail's – of which I am a delighted customer – do. Until you've known the comfort of creating an address; giving it to a service; deciding that you want to end your relationship with them; just deleting that address, without changing your mailbox or infrastructure or archives or anything else … it's kinda life changing…

I like per recipient emails, but I worried how I would know I authorized that sender to send to lonely chicken. The original site could have been compromised. That's why I bought my email domain and use @hnrobert42.com. It helps to use a password manager. I get a lot of convincing emails to linkedin@hnrobert42.com. As well as zynga, wework, etc.

I use +, so username+domainname@email-vendor.com

Which is in the RFC, but yet the sheer amount of times I sign up for something. Like a bank, or a financial firm, get the confirmation e-mail, and then click "Verify your address"

And get HTTP500 as their SQL has kicked up a stink

Post reply on HN