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.
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.
> To have secure email I think html /css should be dropped from email support
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
> A “friend request” mechanism is one way of achieving this.
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.
Having a trustworthy inbox that contains only legitimate email and a separate friend request queue where you can decide “do I know this person / organisation?” is far better than having a single inbox that’s a vast ocean of emails of unknown provenance you have to make a trust decision for for every single email.
You can do this with email today. Heck, you could do it in 2001, I remember. Hotmail's "exclusive" spam filter policy where anything not from your contacts goes to spam, where you can decide if you want to add them as a contact or not.
That doesn’t work because it relies upon the receiver adding all the possible variations of the sending email address to their address book ahead of time.
Email supports text.
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.
>Email supports text.
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.
can you post some details about the spam detector, and just your general setup? I am also an emacs-emailer, using Notmuch, but never looked too deep into the spam story
Have you put this up anywhere for others to use?
Fastmail’s spam filter is not very good.
> 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.
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 <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.
I do something similar with prepend.com and find it helpful for sorting. Also fun to see which domains sell my email and which dont (blacksocks.com hasn’t show up from anyone else in 20 years).
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
(The RFC also allows for (recursive (comments, so there's probably a middle ground between insanely overengineered specifications and a )))regex( someone found on a PHP forum somewhere (and yes this post is a valid email address (assuming there is a local regex account (or alias)))
> That's why I bought my email domain and use <domain_name>@hnrobert42.com. It helps to use a password manager.
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
I've done alice@myname.com, bob@myname.com, etc. I don't keep track of them carefully so I may pick the same name for two different sites.
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.
And some sites seem to have it not work. I suspect there’s lazy programmers with hardcoded test cases.
But that’s like 1:100 or so. And usually I’m entering my address to a robot so it’s not an issue.
The weird looks when I tell a shop my e-mail is "name plus sign shopname AT mydomain dot com"
Apple’s Hide My Email does the same thing and it’s just phenomenal.
Apple is a problematic email service provider. They don't even send DMARC reports.
Irrelevant to the subject of the Hide My Email feature.
Damn it - ublock origin did not block this promo.
The amount of bots promoting Fastmail here is insane. What the actual ...
Hey.com email does this minus the blocking of html/css. You basically thumps up or thump down a sender and they either go away forever or you happily trust what comes from them. It's been hit or miss on some stuff for me and I hate the way the website looks, but otherwise its a great way of whitelisting senders.
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.
You can call it Secure-Email or RFC-99999
Yeah, because email as a family of protocols never developed different capabilities /s