The Future of Email
fastmail.com
fastmail.com
This will literally never happen. Email doesn't support the features that those messaging platforms need to have, such as recalling messages.
The security layers are also only on the sender part, not on the receiver part, which banks care a lot more about.
I'll settle for a brief edit (not retraction!) window after sending though, say 5 minutes tops.
Edit (I realize the irony): banks of course won't give a hoot about the receiver, the power dynamic is inherently not equal.
"Need".
The messages are usually PDFs, which isn't great for accessibility, e.g. using a translation tool.
Instead, legitimate companies like banks, healthcare, etc tell users to click on a url link to their "Secure Message Center" to read or submit some critical information. It's often the only way to get the info the users need.
E.g. if I open a payment dispute with the bank, the workflow they use is the Secure Message area. I can't just use my normal email client and upload some pdf attachments. Instead, I have to log into my bank website, navigate to their Secure Message area, and then upload the docs there to submit the claim. They also don't send followup status or final resolution in an email. Instead, you log back into the Secure Message area to read the case resolution. Similar for insurance claims.
Similar situation for asking a medical imaging center for some mammograms. They will not send those as PDF or JPG attachments directly to your email address. Instead, you log into a secure message area on a healthcare website and download it from there.
No, this includes all messages from my doctor/healthcare. It's not mass spam.
Theoretically I could want to know what's in the message, but not enough to visit a website I've been logged out of again, perform multi-factor authentication, navigate to the message center and find the message and then back it up manually.
I guess you can avoid the email spam by just directly logging into the website when you need that stuff, but how else are they supposed to notify you when something new has happened?
As it happens, I already knew this because the previous bill 6 months ago also included this information, but the message itself was unique and important. Certainly, there would have been financial consequences if I didn't act on that information.
I would have preferred to receive the contents by actual message rather than having to log in to read it, but that's not an option they offer. It's certainly not safe to assume it can all just be ignored.
Then IMO they accept the responsibility of me seeing the message potentially much later than if they had stated the concern up front in e-mail.
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 recommend everyone try it.
Also, the chances of a phisher trying to get my BigBank details by sending mail to lonely.chicken6382@spuriously-named-and-unused-other-than-for-email-domain.com are … well, it seems unlikely.
I've never felt more secure. For real.
That's why I bought my email domain and use <domain_name>@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.
Whenever there’s this discussion on HN, someone usually points out that can sometimes be a bother, especially when giving out the email in person, because people don’t really understand how email addresses works and ask “how did you get that email” or think you’re impersonating the service, or something similar.
I guess a solution might be to add the details sneakily. E.g. instead of linkedin@hnrobert42.com, saying robert_lkdn@hnrobert42.com
But that’s like 1:100 or so. And usually I’m entering my address to a robot so it’s not an issue.
It also makes it easier to pass off a fake realname! Hi I'm John Smith, jsmith@oneofmydomains-nottooobvious.com...
You can even pick a domain sound like a legitimate mail service or company, e.g. jsmith@jgs-consulting.com.or jsmith@liberty-mail.io
All domains and addresses in this comment are fictitious - overlap with real domains is coincidental.
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
The amount of bots promoting Fastmail here is insane. What the actual ...
A bot I am not.
It's your client that's the problem.
I'm happy in my text only Emacs heaven.
I'm also happy with my custom 5 year old bert based spam detector which hasn't failed me once (unlike whatever gmail at work does).
This post was sent from Emacs.
Fastmail’s spam filter is not very good.
Yes it does. However, I have sent messages to more than a few people who tell me that my message is completely empty. I have my client set to send text-only, no HTML, and apparently the system on the other side drops the HTML version altogether. Something on the other end only processes the HTML part. No HTML, no message.
(I believe these are Outlook/MS based systems, but I don't know for sure. It's certainly not ALL Outlook/MS systems that do this.)
For these people I have to set my client to send HTML. It's all well and good to blame them, but I can't make them do something. They may not even be in a position to do anything. And I don't have an option to tell them "too bad, so sad".
The email situation is really quite bad if you don't conform to the Big Three. I've run my own email infrastructure for a very long time, and it's quite irritating that when we get something good (like DMARC, SPF, etc) it gets forced by the Big Three because along with that we also get things like Google toying with the requirement that you have to have AAAA MX records too.
I don’t think that helps at all. We already know how to consume that securely, we do it billions of times a day in web browsers.
> the inbox should work on an invite only basis. Basically you should pre-authorize the senders just like you add someone as friend on a social network.
Yes. A fundamental problem with email is that the only thing required to send email to somebody is knowledge of their email address, which as a recipient you cannot control. This is what enables spam and phishing. This needs to be changed so that in order to send email to somebody, you also need their consent. A “friend request” mechanism is one way of achieving this.
I think this is a problem that can be feasibly solved in a fairly reasonable way, and I sketched out a protocol for doing so a while back, which I described in more detail in this comment:
But then you’re left dealing with spam “friend requests”, which is still something I have to take action on, filter out, or ignore — same as spam email.
It's extremely difficult to accurately identify which emails have health info and which ones don't (even something like a person's name or IP address could count depending on the context) so they just default to sending everything through their message center. No amount of email security could change that.
Encrypted email wouldn’t require a BAA.
Nothing electronic will ever be secure, unless it is never, ever networked. Networking changes "touch physical thing" into "everyone on the planet plus their bots" can touch it.
Even if you pass harsh laws, you need to geogate network connections to only within that legal jurisdiction. Otherwise, it's pointless.
The real, true problem is anonymousness. I used to advocate for, now I'm done. The problems anonymity solve, are a gnat compared to the ones it creates.
I'm all for ipv8, but with a unique ID in the packet identifying the person directly.
I can't drive a car, own a gun, drive a boat, buy explosives, ply many trades, and 100 other things without a license. Maybe unrestricted internet access is in that category, and bad behaviour means it is revoked.
The Internet was a toy for a long time. Now it's the backbone of all commerce, industry, personal communication, with life threatening implications at times.
Play time is over.
The criminal intent was giving somebody without a license, access to your gear to spoof you. If someone is too ignorant to not know what that means, then they would never acquire a license.
The massed will still be able to access youtube, google. They won't be able to open random ports without proxies, and yes that means even online gaming is going to be controlled.
My understanding is that there's a thing called the "conduit exception" which basically says that if data is transiently passing through a channel and it's not being looked at, it's ok. But wherever the data lands must be HIPAA-compliant.
This seems crazy to me, but that's how it works I think. For example, if you encrypt PHI and store it in AWS without signing a BAA with them, that's a HIPAA violation, even though the data is encrypted and Amazon can't see it. But if you send encrypted data through AWS without actually storing it, that's fine.
Mail is specifically mentioned as a thing that qualifies for the conduit exception. I'm not totally clear why it isn't a HIPAA violation the moment it arrives at a destination (it's not in-transit at that point, and it's potentially not in the possession of the intended recipient either), but it seems pretty well accepted that it's not.
All that to say: I think encrypted email would still require a BAA because it's being stored, not just transmitted.
It was a law written in the 90s, it should be updated and modernized.
I agree the laws need an update. I'd imagine a general 'common communication channels' or whatever would work, rather than specifing every single one that's allowed to be used. That way, it's still illegal to snoop on your communications, regardless of whether they happen by post, phone, email, SMS, Whatsapp, or whatever else we end up using in 20 years.
Sounds like they needed fax to be compliant, and came up with some moon logic to make that happen.
Email is a lot harder. The older SMTP standard sends emails unencrypted so there's a possibility of a MITM reading the email. But also addresses if you get them wrong can end up in the wrong hands. For example, if someone sends an email to cogman10, I'll get it, but if they go to cogman1O I won't get it. A lot of the nuance of how secure and when it's secure gets erased by auditors to just "email is insecure".
With HIPAA, is it not possible to simply encrypt the message? The "forgot password" flow for their message center is probably email anyway.
I can upload my public key to SourceHut and all email from them becomes signed and encrypted. It's a one-time process to generate long-lived keys and another to set up with SourceHut and that's all I need to do.
As such, I tell anyone who sends me one to fuck off and send a real email.
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....
I'm sure there's a sum of compliance reasons why this is not allowed, but it doesn't make any sense at all.
https://en.wikipedia.org/wiki/JSON_Meta_Application_Protocol
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.
Genuinely curious. Why is it posted and being upvoted here?
FM often(ish) posts blog posts that are very low key, sometimes they make it on HM, sometimes they don't.
There you go. They don’t know how to get there, but email’s getting faster and smarter and stuff.
Since I use my own domain for email, I am considering moving over to another provider once my subscription term is up. I really miss widgets.
no caldav support so I couldn't get my next appointment as a widget on my phone. Similarly, your contacts in proton are trapped there and cannot sync with any other system (such as your phone...)
limited quantity of aliases compared to fastmail. this is actually a really sticky feature with fm from what I've been seeing. I would have to rename a bunch of accounts or switch to using a catchall to transfer out.
My 30 years of muscle memory using webmail is made useless by this "app" because some web developer somewhere wants to cosplay as a desktop app developer now.
It's not an oversight either. It's an intentional choice to not have a go-back-to-previous-page keyboard shortcut. A customer support person said they would add it as a "feature request". Gee, thanks.
https://www.fastmail.help/hc/en-us/articles/360058753534-Key...
Not saying your complaint is invalid at all.
It's just a weird choice to make. It's like they are forgoing the back hotkey to make it seem more like a "native" app. But it clearly isn't, and I can't think of any good reason to consciously omit it. Or... since they are likely using a framework (Tauri maybe? I haven't checked) to go out of their way to disable something that is already baked-in.
<shrug>
The thing is Fastmail can't speak with absolute authority about email because Fastmail is not email. It's subordinate to it.
https://www.ietf.org/archive/id/draft-adams-arc-experiment-c...
It will be interesting to see if Google can be convinced to move away from ARC to something else. Gmail is all about email server reputation these days so they can reliably treat email servers they don't like badly.
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.
The origins of "Bitcoin" was actually a PoW system to send e-mail to a server!
The model literally can't function if emails are encrypted. They have to be unencrypted for all the ML to run for the inbox to actually be useable.
If anyone can port their phone number, they should be in theory, allowed to port their email addresses as well.
None of the authentication systems here are helpful enough to allow this. You need a valid way to authenticate people irrespective of whatever provider they are on (not their email domain name)
That means that a standard needs to evolve that allows you sign on the behalf of the hosting provider itself.
My favorite feature of JMAP is that it gives you a single, consistent API endpoint that works for native clients, webmail and programmatic clients (like, backup scripts and things like that). JMAP means you don't have to invent your own REST API for webmail. Unfortunately, gmail, yahoo mail and all the rest predate JMAP. So it doesn't really help them in the same way.
It'd be lovely to get thunderbird working with JMAP!
That is the most evil part. Finally we will have bots talking to bots, no human in the loop.
All email problems can be solved with GPG, but that ruins Fastmail and other email services business, as they won't be able to read and analyze their users' emails. No ads, no selling user profiles to ad companies, not even teaching AI on user data. This is the kind of future of email I would like to see. Sadly, noone uses GPG and it's quite hard to teach people to do it.
We will eventually be forced down this path though, be patient! Upfront key exchange in-person will be the only way left to prove comms are real. GPG is just one path but someone will come along and make it easy on organizational level.
Metadata is more valuable than message content for analysis. GPG solves that how?
Even though they have not been caught, it does no mean they are not doing so. We live in the world of zero trust.
> Metadata is more valuable than message content for analysis. GPG solves that how?
In most cases yes, only From: and To: headers are exposed.
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.
Those were the days, lol!
Either way, we are getting to a point where offline-2FA will be mandatory for all auth systems and when interacting with another party, it will need something like the above to be sure you are dealing with the correct company.
But that makes me think of Hashcash, that was developed to limit email spam via proof of work, but I don't think that has ever been used in practice: https://en.wikipedia.org/wiki/Hashcash (and of course wouldn't work for the proof of humanness you're talking about).
Here's a big part of the problem right there. Google requires something, it becomes a requirement. In fact, Google's hold on email is a problem in itself. Among other things we need variety. Without it, "Google begins requiring" will be a recurring theme. It's happening again now with mobile phone apps! "Google begins requiring" that you register with them so that the apps you write can be installed on Android phones.
> This shifted authentication from something senders could deprioritize to a basic prerequisite for reaching inboxes.
And later, Google and a few other large players could just prevent individuals and smaller email service providers from being able to send email, at all.
> so the filtering systems can tell where bad content is coming from and avoid hurting the reputation of the wrong parties.
Be ready for people who don't register with the big corporations to be marked as having "bad reputation" and being simply blocked. There might be some technical excuse.
> The inbox of the future will be faster, smarter, and more capable than what most of us use today.
That sounds like the inbox of the future might be controlled by somebody else. I don't like that at all.
Of all the stuff Gmail imposes on the rest of the world, requiring proper sender authentication was a good thing and we've helped thousands of senders set up proper authentication because of it.
Forcing the issue finally got rid of the ridiculous practice of ignoring SPF/DKIM failures and just setting the DMARC record to p=none.
None of this changes the fact that Gmail is a problem for so many other reasons, but this specific imposed change was a net benefit for the entire email ecosystem.
I was an email admin for a university. In the past - each college ran their own email. Before DKIM, before SPF, you'd just have basically random servers on the internet sending email as (school).edu. Tons of random subdomains too. math.(school).edu and so on.
Email was eventually centralized but you'd have parts of the university still running their own things. Insisting they're special and can't be brought into the fold.
So, we had a lot of stuff out there just not passing authentication. A lot of spammers could just impersonate our domain.
We'd go to leadership and say "hey we should really get our act together" - but everything was working. Our emails were still getting out. Hard to justify spending the time, getting various higher-ups within departments to give up their things, and so on.
Unless you can get like, the president to back your initiative- universities are very decentralized and it becomes an issue of "do we have the political capital to spend here." The overall relationship between central IT and the various college-based IT departments was terrible, often bordering on combative.
Google and Yahoo made it so we could go to leadership and say "people will not get our emails if we don't get this straightened out" and it became a priority. When I left our DMARC reports were showing something like a 99% pass rate when it was previously like, 50.
So, I'm glad Google and Yahoo made that call, it gave us the kick in the pants we needed to get our own shit together. I am 100% certain we were not the only org like this.
Plus for a small host - where you're just running a single mail server or something - you just need a few things to pass DMARC.
A DMARC record, and an SPF record, and for your emails to pass SPF. You technically don't need to do DKIM signing (though I'd still recommend it because that survives automated forwarding).
For example, I could set rules like “if an email looks like a promotion, move it to the promotions folder.” I could roll my own MCP server sure, but that’s not the direction I want to go.
So on seeing this title, I was a bit worried.
> It’s worth being transparent about what that looks like at Fastmail: we haven’t integrated AI into your inbox, and your mail isn’t being processed by a model in the background. Our MCP server is simply an API endpoint available if you want to connect an AI client of your choosing with your explicit authorization, and nothing changes if you don’t.
Phew.
I don't quite buy this in either direction (although they are both couched as possibilities, which makes it a pretty safe statement). Humans might notice, but years of annual mandated phishing trainings has led me to believe that humans as a whole are generally not great at noticing.
AI agents OTOH mostly do as they are prompted. If the human prompting them tells them to check these things, they will likely check much more consistently than any human. If the prompt doesn't say to check, the agent won't. But that again falls back to what the human might or might not think about.
time and time again it's worth stressing how the Lindy effect directly applies here to email or other layers of the protocol stack.
As one example, I'm now regularly getting phishing email from "The IRS" that always comes from some random account that has been taken over. The latest one was literally from a hotmail account (and my address is dot ca so I'm clearly not subject to the US government). If they can't detect this kind of half-arsed phishing attempt, then things are pretty bleak.
Their customer service was pretty bad when I tried to discuss it. The rep didn't even acknowledge what I wrote. I won't be renewing unless they get this sorted.
Gmail Thinks I'm Stupid, So I Left: https://news.ycombinator.com/item?id=48375016
For instance, I am self-hosted, that without DNS. The email designers were carefull to make the email system work without DNS, that with email addresses with IP literals: mailbox@[x.x.x.x] and mailbox@[ipv6:...] (and I guess once ipv4 is really gone, the ipv6: prefix will be dropped).
This is stronger thas SPF, since as soon as a IP literals in the envelope and the various "from" headers does not match the actually IP from the sending SMTP server, the email is dropped, not even going in spam.
If I send such email to gmail for instance... I get a 'missing a DNS PTR' record, go to hell. How, convenient, to send an email there, you must have bought a DNS domain, knowing perfectly that most registrars nowadays are gated by the web engines of the whatng cartel... which gogol, then gmail does belong to... how convenient, the crime is almost perfect, I don't put that on the account of incompetence, this is beyond that, we are in the realm of toxic malice.
I do presume now they know what they are doing, killing all small tech, or self-hosting is in their agenda of dominant internet corporation.
In time there will be a reckoning though. The geopolitical instability at the moment will see the end of the US dominant services used outside of the US so they will have to work out how to make a not small but balkanised email provider model work again.
Fixing that level of corruption/brain washing is now going to hurt bad.
It's absolutely the worst part of using Fastmail, that they don't clean up in their own house.
I particularly don't understand the constant fanfare around discussions of SPF/DKIM/DMARC. They're widely understood, published RFCs that have been around for at least 10-15 years, some of them longer. They're not obscure folk wisdom passed down through generations of sysadmins, yet I read so many documents and articles that make it sound like a proprietary trade secret that the authors of such articles are graciously revealing to the world.
Nice. ;)
Also there's a spectrum from Gmail to Fastmail to AWS SES to Wireguard on a VPS that's tunneling to a server running at home. And when the people from both extremes of the spectrum interact they look at each other as if they're from other planets.
It's the same for Auth stuff I believe, almost a decade of generic advice like "don't roll your own auth" has lead some people to file it into a tidy corner of their mind labelled "DON'T TOUCH" so most people end up gawking and staring in awe when someone does so and lose all nuance along the way. To be clear I'm advocating for learning how stuff works and playing around with it (time permitting) instead of simply delegating it to the technical equivalent of Higher Powers in perpetuity.
- BIMI (I hadn't heard of that before) which seems like a very minor thing to be calling "the future of email"
- AI might be easier to trick that humans
On that second point, here's the exact text:
> A person reading a suspicious email might notice that the sender’s domain has an extra character, or that something about the request feels off. An AI assistant scanning your inbox for items that need action may not slow down to check those things.
That seems wrong (AI should be better at this than the average human), but let's assume that assertion is correct. It then says "authentication is the safeguard that should stop it before it ever reaches your mailbox". Except then, a few paragraphs down, it says "A scammer with a convincing look-alike domain and a properly configured DMARC record will still pass sender authentication checks." Ok, so authentication isn't a solution to the stated problem at all (it does solve a different problem). And unless I'm missing something, no solution is proposed. No statement is made about what the future actually looks like.
Like you said, what is the point of this article?
For example, making a company named "there's a problem with your account call this number" on a site like PayPal and getting it to generate emails. They'll be from actual paypal.com and pass all authentication.
The other issue I'll often see is subdomain takeovers. Company makes a subdomain a CNAME to some other, external domain. Usually with the intention of hosting a webpage externally or whatever.
That other domain expires, but the CNAME doesn't. Somebody buys up the external domain, now they can publish SPF records and pass DMARC relaxed alignment on the organizational domain.
Now you can send all the emails you want with literally anything you'd like and the providers will say "yep, this passed DMARC."
I'll tell you right now, I've had multiple cases where I've had to quote parts of the RFCs to large companies because they were handling email authentication incorrectly.
They are wildly misunderstood. The moment I see "add this include: directive to your SPF record" in some marketing platform's integration documentation I know they're going to fuck something up.
To add-on, the really pro move is to not touch the client's SPF record at all. Use your own domain in the SMTP envelope and have SPF be valid for that. Just have the client establish DKIM records and use DKIM, and only DKIM, to pass DMARC.
If you insist on using the client domain in the envelope, make it a subdomain with MX records back to your infrastructure (so you can track bounces). That will pass relaxed alignment - or just use a subdomain in the from and now you're passing strict alignment as well.
Most companies have no idea how the envelope domain impacts bounces and frankly, doesn't care about tracking them.
A shockingly high number of companies have no idea of the concept of the envelope address.
You'd think companies generating as much email as Atlassian would know what they're doing.
Unfortunately, I do tend to agree that we can't fix stupid or the inability to read the RFCs. :-(
Thanks for providing a balanced view
Not so for Google Workspace. I get more spam and fake invoices and DocuSign contracts than I used to.
Please, Fastmail, don't fuck this up. I have been a happy customer for years. Do not fuck this up with idiotic AI systems. I just want reliable email.
> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.
... and then the article goes on to talk about SPF, DKIM and DMARC which authenticates only the domain part of the "From" field. So just the reputation of the email server, not the entity that sent you the email. If things get as bad with AI generated deception as suggested by the article this wouldn't be good enough, we would have to start signing our emails again. Emails from entities we don't know would have to be treated with a high level of suspicion.
I am not convinced that things will for sure really get that bad. How can a AI figure out the email addresses of our correspondents? They are not magic.
The name part of the email address is also part of the same signature but is not being authenticated either.
The new fad is "loop". And any loop should have a trigger. Rather having countless integrations, let all the triggers to got email, and those triggers trigger loops. I feel AI can kick off from personal/shared inboxes to deliver meaningful outcomes
Self hosting is hard (which is why I just use Fastmail now), but it's not because of that.
We built a Discord integration so that new emails to our support address would ping us in a Discord channel using the JMAP API. It's only failed to work once that I can recall - and that ultimately ending up being on Discord - not Fastmail.
Just rock solid service all around with no bullshit.
No AI needed, and also no stupid AI summary, as you only get a few legit emails to your inbox, never spam anymore.
But great idea, what i added is the opposite direcrection: showing if a sender used spy pixel. There I used public spylists I found.
Anyone without caller id is also suspicious. Emails have a sender, but it is also about as reliable as a caller id (i.e. not very) when it comes to identity.
They have an MCP end-point, they want to market to both AI proponents and critics -- that's about what I learnt from scanning the article.
Big title, little content.
Another subscription for software- and people outside HN hate paying for software- when outlook, apple and Gmail exist?
It's important that they're secure.
Is it possible to have E2E encryption on emails?
vbezhenar, this is your grandmother. I just got an email from you with a bunch of gobbledygook and I can't read it. /s
If it were that easy, everyone would be doing it.
But even then, the sheer amount of people who'd complain and wonder what the block of base64 data was at the bottom of the e-mail, or the strange attachments I'd have (including signing other attachments) was too much to have to deal with. For the once in a million people who ever looked at key signing...
Once you force people to do it, it is not terrible once they get the hang of it.
E2E encryption is one click away in Telegram. I've yet to find anyone turn it on. Most people just do not care about encryption. The whole encryption story is pulled into mainstream by crypto-enthusiasts IMO.
You literally have a proton email address on your profile.
The question is, Can the encrypted mail be a default?
That can push email companies to make access to email a paid service. And that would cut out a huge chunk of world population from access to email.
It's a full chain reaction and that's why companies like Proton remain small