Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of Email

fastmail.com

Post reply on HN
Print view View original

31–40 of 217 posts

Re: The Future of Email

#31

Post by bradfa »

zazuke wrote: post #25

The easiest and best filter is to screen emails. Only emails that were screened in once go to your inbox. It's that easy. HEY.com introduced it, and I can't see email without it; that's why I integrated it into my TUI email client, neomd [1]. Since then, when I get an email from Amazon that lands in my "To Screen" box, I am automatically alerted and know it is potentially spam, because I have approved Amazon and legi…

So the natural extension of this would be plugins which have curated open source allow-lists? Similar to how I trust uBlock Origin's default ad filtering block-lists, I would similarly trust a curated open source allow-list for email domains, and then I would add my own from the "to screen" folder?

Re: The Future of Email

#32

Post by Angostura »

thefounder wrote: post #19
sverhagen wrote: post #2

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…

To have secure email I think html /css should be dropped from email support and 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.

So... not e-mail then

Re: The Future of Email

#33

Post by jasode »

LoganDark wrote: post #12
sverhagen wrote: post #2

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…

I love hearing that I received a "secure message", with no further detail. Straight to trash -- I don't read "secure messages". My inbox is probably more secure.

The gp isn't talking about spam using "secure message" as bait to open unwanted 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.

Re: The Future of Email

#34

Post by jen729w »

thefounder wrote: post #19
sverhagen wrote: post #2

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…

To have secure email I think html /css should be dropped from email support and 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.

> 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 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.

Re: The Future of Email

#35

Post by sph »

A lot of nonsense about AI and this The inbox of the future will be faster, smarter, and more capable than what most of us use today

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.

Re: The Future of Email

#36

Post by upofadown »

>Anyone can put anything in the “From” field of an email.

... 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.

Re: The Future of Email

#37

Post by zazuke »

bradfa wrote: post #31
zazuke wrote: post #25

The easiest and best filter is to screen emails. Only emails that were screened in once go to your inbox. It's that easy. HEY.com introduced it, and I can't see email without it; that's why I integrated it into my TUI email client, neomd [1]. Since then, when I get an email from Amazon that lands in my "To Screen" box, I am automatically alerted and know it is potentially spam, because I have approved Amazon and legi…

So the natural extension of this would be plugins which have curated open source allow-lists? Similar to how I trust uBlock Origin's default ad filtering block-lists, I would similarly trust a curated open source allow-list for email domains, and then I would add my own from the "to screen" folder?

Oh, that's a great idea. Currently, every user has their own private list (it's just text files). It takes a bit of work initially, as you need to approve each email, but it's totally worth it. And it must be per user IMO, as your friends and family have different emails, so its less about public or legit domain, but more what domain and e-mail YOU trust.

But great idea, what i added is the opposite direcrection: showing if a sender used spy pixel. There I used public spylists I found.

Re: The Future of Email

#38

Post by greengreengrass »

What's the point of this article? The most I got was "email is here to stay," followed by some discussion of an MCP server for their proprietary mail platform.

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.

Re: The Future of Email

#40

Post by fc417fc802 »

Angostura wrote: post #32
thefounder wrote: post #19

Earlier quoted context omitted.

To have secure email I think html /css should be dropped from email support and 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.

So... not e-mail then

The necessary bits to facilitate that could be added on top of the existing protocol in a manner that doesn't break existing clients. Essentially it amounts to an out of band registration of the expected sender with your own server, likely by means of a short proxy code or phrase. Couple with key exchange to facilitate an E2EE extension at the same time, while also dodging the logistical issue that would otherwise arise when a sender has multiple addresses or the sending address changes.
Post reply on HN