HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
59% Positive
Analyzed from 4233 words in the discussion.
Trending Topics
#email#don#more#secure#message#emails#fastmail#send#spam#mail
Discussion (106 Comments)Read Original on HackerNews
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.
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:
https://news.ycombinator.com/item?id=44969726
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 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.
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.
Fastmail’s spam filter is not very good.
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.
The amount of bots promoting Fastmail here is insane. What the actual ...
As such, I tell anyone who sends me one to fuck off and send a real email.
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.
The messages are usually PDFs, which isn't great for accessibility, e.g. using a translation tool.
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".
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.
The thing is Fastmail can't speak with absolute authority about email because Fastmail is not email. It's subordinate to it.
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).
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!
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.
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
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.
Gmail Thinks I'm Stupid, So I Left: https://news.ycombinator.com/item?id=48375016
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.
No AI needed, and also no stupid AI summary, as you only get a few legit emails to your inbox, never spam anymore.
[1] https://neomd.ssp.sh
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.
Self hosting is hard (which is why I just use Fastmail now), but it's not because of that.
... 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.
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. ;)
- 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?
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.
Not so for Google Workspace. I get more spam and fake invoices and DocuSign contracts than I used to.
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.
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.
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.
You literally have a proton email address on your profile.