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 Future of Email
61–70 of 217 posts
Re: The Future of Email
#62Are there any options left at all to self host email?
Re: The Future of Email
#63What'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 genera…
Agreed. I had some vague hope that this article made it to the HN hope page because someone was saying what needs to be said: that the future of email should be protocols over platforms, as it was in the past. Mail servers and mail clients.
Nice. ;)
Re: The Future of Email
#64> In early 2024, Google and Yahoo began requiring 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…
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.
Re: The Future of Email
#65Earlier quoted context omitted.
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 j…
> The gp isn't talking about spam using "secure message" as bait to open unwanted email. 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.
Re: The Future of Email
#66I 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.
Re: The Future of Email
#67I 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.
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.
Re: The Future of Email
#68Re: The Future of Email
#69Earlier quoted context omitted.
> The gp isn't talking about spam using "secure message" as bait to open unwanted email. 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.
It must be nice to not need to use that crap, but one day you might.
Re: The Future of Email
#70I 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.
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: