Which e-mail provider is more adviseable, protonmail or lavabit reloaded?

Good day,

So recently, two things happened which are somewhat connected with competitors to riseup’s mail service:

1.) Protonmail made their site accessible via a Hidden Service WITH SSL: Tor encrypted email, file storage, calendar, and more | Proton

This should make the encryption between their servers and a browser accessing them more secure overall, especially keeping in mind that their open-source encryption solution for the mailbox very much relies on a secure connection between the two.

2.) In even better news:

Lavabit is back: https://lavabit.com

Yes, the only service with enough integrity to publicly decline a NSL has returned and appears to be better than ever. They have a new more secure implementation of encryption called DIME which is Open Source and can be used by anyone who’d be willing to set-up their own service, like what Protonmail did previously.

However, even better, it is apparently capable of encrypting any metadata and allows users to choose how much trust they’d like to put in their servers.

Their “Trusful mode” is similar to how Lavabit operated in the past, using TLS keys on their servers. Though now, they claim these are stored in a “hardware security module” which isn’t accessible by them, though this sentence worries me a bit since it is hard to prove:

The only account capable of extracting the key is the HSM supervisor. To prevent this we set the passphrase blindly thus locking us out.

The second mode, “Cautious Mode” works similar to Protonmail, though seemingly outside of browsers as well. Just like with PM, only an encrypted key is saved on their servers, which has to be decrypted on access by the user. This means that the user doesn’t have to trust their servers and gets true end-to-end encryption.

The third, “Paranoid Mode” does never get any key, encrypted or otherwise.

For me the dilemma now is the following:

Should I stick with Protonmail, which are in Switzerland, but do not give me the option of storing my private key to access my encrypted messages only on my system.

Or, should I switch to Lavabit, which give me the ability to use “Paranoid Mode” to keep my key to myself, thus trusting no one with it, while relying on servers in the US of A.

The problem is that while both are Open Source, I can’t tell whether that source code is also used by them in the way they claim it is. Adding to that, while Ladar Levison showed, that he would rather stop than cave in under a NSL, nothing says that future laws or more cleverly drafted NSL’s couldn’t force him to do it anyways.

Adding to that, Ladar was somewhat willing to cooperate with US authorities: Lavabit founder offered to log users' metadata if FBI paid him $3,500 | Data and computer security | The Guardian

Have a nice day,

Ego

(Edit by Patrick: split from original topic. The subject Which e-mail provider is more adviseable, protonmail or lavabit reloaded? was chosen by me.)

2 Likes

OK, you beat me too it Ego, but this is something I was hoping to add to the Email wiki, but first you smarter guys in the room can hammer any technical mistakes or falsehoods first. :slight_smile:

How about this →

Email Provider Criteria

Email is a notoriously insecure protocol which is generally recommended against for critical communications, particularly if exposed meta-data is part of your threat model. [footnote: Notwithstanding the emergence of free (beta), opensource end-to-end encrypted email providers that also encrypt meta-data, such as Scryptmail.]

Defaulting to only using SSL encryption with a centralized email provider is a recipe for a security disaster. SSL-stripping, man-in-the-middle (MITM) attacks and a host of other vectors mean it is only a matter of time before your account is breached and exposed under one of the dragnet surveillance programs in operation world-wide.

Privacy is also impossible if you resort to corporate services like Gmail and Yahoo, which have automated software that scan all incoming and outgoing emails for keywords for advertising purposes. Similarly, Microsoft has a history of reading ‘private’ emails and messages and cooperating fully with LE authorities. Recent security breaches experienced by the large providers - like the billion plus users at Yahoo - are likely state-based actors, and further successful attacks can be expected in the future.

PGP encryption is the best method currently available to protect the contents and attachments of your communications. However, it must be remembered that it does not disguise critical meta-data like: End-to-end email encryption – A case study on ProtonMail design limits and security flaws – arno0x0x

  • Who you’ve been corresponding with (recipient email address);
  • Email subject line;
  • When the message was sent;
  • Message size;
  • The frequency of exchanges; and
  • Unless you use Tor, from which IP address the email originated.

With these factors in mind, there are a number of desirable criteria to consider when selecting a suitable email provider for a new account. This includes, but is not limited to:

  • Free services;
  • Hosting jurisdictions outside the 5-eyes countries and their allies;
  • Deployment of fully open-sourced software that has preferably been audited for security;
  • Providers are not in the ‘alpha’ or ‘beta’ stages of development;
  • Providers have a history of resisting government interference in the forms of NSLs, gag orders, seizure of data, and other attacks;
  • Providers have already withstood serious attacks upon their infrastructure (such as DDOS attacks);
  • Providers regularly update their warrant canary on a strict release schedule;
  • Compatibility with open-source desktop email providers such as Icedove/Thunderbird;
  • Availability of client-side (browser-based) end-to-end encryption to recipients of the same service;
  • Compatible client-side (browser-based) PGP encryption for end-to-end encryption to recipients of other email services;
  • Email inboxes are encrypted by default;
  • Full PGP compatibility and key management, including the importing and exporting of keys and electronic signatures;
  • Providers do not keep logs of IP addresses;
  • Providers allow anonymous registration of new accounts via Tor;
  • Availability of Tor hidden services for logins;
  • Availability of two-factor authentification in the form of other devices or tokens;
  • Availability of disposable email addresses;
  • Availability on a range of devices and peripherals; and
  • Ability to obscure or encrypt meta-data.

Email Security Heirarchy

The choice of email provider and set-up is not an easy one. It is determined by many factors, such as the user’s threat model, skill level, financial resources, motivation and willingness to invest time and effort in order to resolve problems.

In general, the most secure, but technically difficult set-up would involve the user establishing their own mailserver based on opensource software and strictly using PGP encryption for almost all emails sent. Unfortunately, this is simply beyond most users and unnecessary for their threat model. Also, this poses many security challenges in the event that something has been misconfigured and the vast majority of internet users do not have PGP key-pairs to begin with, negating the utility of this method.

The next most secure method is for the user to utilize self-created PGP keys, which they alone securely manage, in combination with a secure centralized provider (like Rise-Up), and a desktop email client such as Icedove with the Enigmail plugin. The user also has the ability to utilize split-GPG architecture in Qubes to protect from the theft of their private key. Split GPG | Qubes OS Again, the limitation of this approach is that PGP key-pairs are hardly ubiquitous, meaning most emails will be sent to recipients using standard SSL encryption.

The most usable method for PGP end-to-end encrypted emails, which involves an important security trade-off, is to use a centralized email provider such as ProtonMail or Tutanota. In this case, a desktop email client and PGP key management are both unnecessary, as all encryption is performed client-side (in the browser) with Javascript libraries.

The benefit is that the user does not have to manage PGP keys, only one password is required to send encrypted emails, and emails to users of the same service are automatically encrypted end-to-end. On the downside, the benefits are counter-balanced by the huge attack surface of the browser, reliance (often) upon the broken Certificate Authority (CA) system for server authentication, risk of modification of the application code server-side (leaking the mailbox password), the theft of the encrypted private key stored on the mailserver, and other factors.

The Case for ProtonMail

ProtonMail Threat Model

Protonmail is aimed at users who want to guard against mass surveillance. It is not intended for users who are at high-risk, such as the next potential Edward Snowden. It does not protect against: The Proton Mail Threat Model | Proton https://www.wired.com/2015/10/mr-robot-uses-protonmail-still-isnt-fully-secure/

  • Users with already compromised machines e.g. infected with malware, keyloggers etc;
  • Man-in-the-middle attacks, where an adversary sits between the user and the ProtonMail servers and sends the user’s browser a modified version of the ProtonMail website;
  • Unauthorized backdoors, where ProtonMail servers in Switzerland are accessed and the software is changed to send bad encryption code to the user’s browser, or compromised public keys are sent to execute a MITM attack; and
  • Knowledge of whether a message sent to another user is being encrypted with the correct public key stored on ProtonMail’s keyserver (potential eavesdropping risk).

Fortunately, Protonmail has just established a new Tor hidden service for ProtonMail, which also includes an Extended Validation (EV) certificate, increasing the difficulty of targeted MITM attacks. The service can now be accessed at:

https://protonirockerxow.onion

The benefit of using the hidden Tor service includes: Fighting Censorship with Proton Mail Encrypted Email Over Tor | Proton

  • Adversaries will find it difficult to know you are accessing the service;
  • Tor’s extra layer of encryption makes MITM attacks more difficult;
  • Attempts to censor the use of Protonmail by governments will be more difficult;
  • The service is more resistant to DDOS attacks;
  • The weakness of just relying on the CA system for end-to-end authentication is mitigated;
  • It is more difficult to serve malicious code to a targeted individual based on their IP address; and
  • The EV status of the certificate reduces the threat of phishing attacks by impersonators.

Protonmail Features

Protonmail meets a number of the suggested criteria for selecting a suitable email provider. For instance: How Safe is Proton Mail? Security Features Explained

  • ProtonMail has withstood recent attacks on its infrastructure;
  • A free service is available;
  • It is outside the 5-eyes jurisdictions;
  • It is available on a range of devices or peripherals;
  • Strict warrant canary updating is in place;
  • Messages are stored in encrypted format on ProtonMail servers at all times;
  • Messages are encrypted in transit between servers and user devices;
  • Data is encrypted and inaccessible to ProtonMail staff due to client-side encryption;
  • Opensource deployment software and cryptography is used e.g. AES, RSA and OpenPGP;
  • Data never goes to the cloud;
  • No tracking or logging of personally identifiable information;
  • No targeted advertisements are served;
  • Emails sent can be set to be automatically deleted after a set time period (those sent to both non-ProtonMail addresses and ProtonMail addresses);
  • Encrypted emails can be sent to non-ProtonMail addresses;
  • Two-factor authentication is available;
  • Full PGP key management is available;
  • Tor Browser registration is possible; and
  • A Tor hidden service is available.

Additionally, features already incorporated or on their roadmap for development include: 2016 Email Security Roadmap | Proton

Authentication:

  • Challenge/Response login password improvement so that every login uses a different one-time hash.
  • Store mailbox password in memory only, not session storage. This means the user will have to re-enter the mailbox password if the page is refreshed, but will avoid the mailbox password ever touching the disk if the browser caches session storage.
  • Two factor authentication.

Server

  • Public Key Pinning (HPKP): This pins our certificate such that we can’t be impersonated if a root CA or intermediate CA is compromised.
  • Content Security Policy (CSP): An extra layer of XSS protection which disables all inline scripting and whitelists only our domain for loading Javascript.
  • Migration to Certificate Transparency (CT) for EV Certificates.
  • DNS-based Authentication of Named Entities (DANE).

Full PGP Support

  • Support importing PGP public keys of contacts so PGP emails can be sent automatically through ProtonMail.
  • Support keychain functionality so users can import their own public/private keys.
  • Allow the export of ProtonMail user private keys.

Application Security

  • Add ProtonMail SSL certificates to the HSTS browser preload list(s). This needs to wait until we have stabilized our certificates.
  • Client-side public key verification mechanism for recipients. This allows you to automatically check the fingerprints of recipient public keys to ensure that there is no key spoofing.
  • Browser extensions or desktop applications so client side code does not need to be loaded each time ProtonMail is accessed.
  • Splitting the ProtonMail webmail into a separate subdomain isolated from other services.
  • Adding a Web Application Firewall (WAF).

Conclusion

While Protonmail is not a perfectly secure solution or privacy magic pill, the perfect should not be the enemy of the good. Many criticisms aimed at the service have been addressed in recent times, with others on their roadmap. End-to-end email encryption – A case study on ProtonMail design limits and security flaws – arno0x0x Mr. Robot Uses ProtonMail, But It Still Isn't Fully Secure | WIRED

ProtonMail is likely a suitable solution for the threat model of most Whonix users, who desire a usable solution that provides resistance against mass surveillance programs targeting emails. This of course requires them convincing their friends and family to also make the switch. In addition, secure use of the service can probably be increased when used in combination with a Disposable VM in the Qubes-Whonix architecture and a suitably long and unique Diceware passphrase.

1 Like

Also consider adding sigaint to the wiki http://sigaintevyh2rzvw.onion/

They have been providing this service for years (at least 3 that I know of) and seems to be the only hidden service email provider that doesn’t currently require anything other than captchas to create and use it. bitmessage.ch required another email account and refused when I gave disposable email address.

I tried to register with protonmail but they required sms or a “donation” with credit card (not even bitcoin) to create my account so I can’t see how this can be recommended for whonix users as the main concern here is anonymity, not privacy. Funny how it reminds me facebook also has a hidden service and requires sms for account creation.

Too many ProtonMail accounts have been created from your connection.
Thus, we are requesting additional verification to ensure you are human and not a spam bot.
Because Tor is frequently abused by spammers, this check may be triggered because of the Tor exit node you are using.

Bullshit, what’s wrong with captchas?

No wonder account creation doesn’t work if you use the hidden service like https://protonirockerxow.onion/create/new

Not to mention javascript is required at account creation and to use the mail service.

sigaint doesn’t use javascript

http://deepdot35wvmeyd5.onion/2015/02/16/interview-sigaint-darknet-email-admin/
http://deepdot35wvmeyd5.onion/2015/04/26/70-malicious-tor-exit-nodes-exposed-by-siganit-org/

They even helped remove 70 malicious exit nodes

https://protonirockerxow.onion/

Until they drop the webmail-only requirement they are not really recommended IMO. Nonetheless an Onion service is good news.

@Patrick will sdwdate work with an https address?

Nice. Last time I saw the Dark Mail Alliance initiative was stalled with a new standard missing many sections. Seems they are no longer vaporware at last.

Sigaint looks pretty good to add I suppose.

Bonus of no Javascript and PGP compatible. Downside of small inbox size. The only problem again for mass adoption is this bit:

Can I use PGP with your service?

Yes, but you must do all of your signing and encrypting locally on your own computer and paste the ciphertext into the compose/reply box. (There are some browser plugins that may assist with this.) We do not want you to trust us with your keys. The system is designed this way on purpose.

Again, I don’t think we can write off Protonmail just because it doesn’t (yet) have desktop email compatibility with Icedove et al and the Javascript issue.

There are gonna be a lot of (most?) Whonix users - the kind that ask questions in the forums every day - who won’t/can’t manage PGP due to technical issues and are willing to risk Javascript in a separate VM just used for email and nothing else. What is the real Javascript risk if they are accessing email via a Whonix-WS DispVM?

Further, you again run into the problem of mass adoption. PGP is great if I wanna send an encrypted email to Patrick or entr0py or Joanna Rutkowska, but not Joe SixPack in real life. This is why it’s adoption has been dismal over the last two decades. The security trade-off with Protonmail solves this i.e. auto PGP encryption.

Re: ProtonMail sign-up. I didn’t run into any problems when signing up via Tor. The wiki could just note to rotate Tor circuits until the message is no longer received.

Also, re: “confirmation of human status”, anybody could just create another account with Tutanota or a host of others to ‘prove’ they are a real person at sign-up stage. Easy problem to side-step.

I tried a few different times before and there were only sms and donate options, on my last attempt now did I see the email verification option.

I don’t think any of us know what is the overall situation on exit nodes, do most people see an email option or not? Is this going to improve or worsen as it scales? But they don’t seem Tor-friendly to me. It doesn’t feel right when they identify me as a Tor user and provide no anonymous options:

Because Tor is frequently abused by spammers, this check may be triggered because of the Tor exit node you are using.

I would feel better if they didn’t mention Tor here

Good day,

Yes, that seems to be the case whenever using Tor for their “normal website” or their new hidden service to create an account. Even reloading the connection and changing the exit node doesn’t help here. That’s quite problematic.

Signait though doesn’t seem to encrypt your mailbox. So anything not encrypted before reaching their servers can be read by them. Any non GPG/PGP message thus is by design exposed. Not ideal either in my eyes. They actually sell full disk encryption as an “optional feature” which certainly is problematic. Especially since we can’t tell how they implemented that full disk encryption. Is the mailbox encrypted end-to-end, that is to say, only the client used to access the mailbox has decrypted access. The name full disk encryption implies otherwise sadly.

Javascript is used for this very reason by PM. To keep the mailbox encrypted until it reaches the users browser. That’s also why I am rather happy for the new implementation created by Ladar, as it is said to work outside of browsers as well while offering similar security.

Like mentioned, if you look at their source (Proton Mail · GitHub) and specifially the Client, you’ll see that their encryption concept for the mailbox very much relies on JavaScript which in the way required no (at least to me) known desktop mail program can process. Maybe they’ll make some bigger changes with Protonmail 3.0, though it doesn’t seem to be the case looking at their timeline.

That’s also why I’ll have to take a closer look at DIME. I can hardly see any way of making a fully end-to-end encrypted mailbox possible with a standard mailing program like Thunderbird.

Making a purely subjective guess, I’d say it’ll stay the same unless PM changes their stance on Tor nodes, seeing how over time more “bad guys” will likely try to use PM over Tor, while at the same time, new nodes are added to the network at a steady pace.

Have a nice day,

Ego

Unless your key is on your machine none of this is considered safe. Malicious JS could easily be injected by an attacker doing mitm on CA SSL, or an attacker who controls the server or who has compelled the service provider to target a user.

As for usability that is what Enigmail is for. We should not encourage users to trust inherently unsafe services just because they are easier. Instead we should look at making secure mechanisms more user friendly.

This reddit thread may also be helpful:

Malicious JS could easily be injected by an attacker doing mitm on CA SSL, or an attacker who controls the server or who has compelled the service provider to target a user.

True - with the same risk applying to logging into forums on Whonix on a daily basis.

This all raises a couple of issues:

1) This email guide here →

http://kkkkkkkkkk63ava6.onion/wiki/Email

Needs a lot of cleaning up.

2) I think we (or me) should outline the steps for the ‘easy’ creation of PGP keys and using the Enigmail plugin. It’s only ‘out of scope’ because no one could be bothered to write it.

I’m happy to do it.

3) Trade-offs are made every day. The wiki strongly advises against using Windows as a host OS because it is a privacy and security disaster, but the masses still flock to it & a windows Whonix installer was just recently released by devs here, because they are not allowing the perfect to be the enemy of the good.

4) I think a more subtle argument needs to be made around compartmentalization of email activities based on the real world and perceived risks to the user of their encrypted emails being busted by the Stasi.

  • If I’m a freedom fighter or Whonix developer, I want PGP (where I control the keys, using a desktop email client) in almost all my daily activities.
  • If I’m protecting against mass surveillance i.e. PRISM, and want to hide emails to family members who will never install Enigmail or create PGP keypairs, then ProtonMail or equivalents are perfectly fine, since it simply raises the bar for attackers who want to know about me attending next Sunday’s BBQ.
  • If I want to do both (self-created and controlled PGP keys for freedom fighting, ProtonMail to make mass surveillance tools harder of my mundane activities without targeting of Javascript for ‘normal emails’), then that is also perfectly fine, because the ‘risk’ is that they discover I like BBQs in the worst-case scenario.

The real worst case scenario is that people keep using GMail, Hotmail and Yahoo, which is plainly retarded based on disclosures to date :slight_smile:

Well, the trade-off by using protonmail / lavabit… If most of the user’s contacts don’t use the same provider, which is very reasonable to assume, their mails are still sent in cleartext around the world.

I easily grant them this to be true, yet that doesn’t give one what they are implying with it. How much worth is your super secure SSL engine, if the communication between the web server and the SSL engine on their server is still easily compromised by an adversary that can force local hardware access.[quote=“HulaHoop, post:4, topic:3459”]
@Patrick will sdwdate work with an https address?
[/quote]

No.
url_to_unxtime https support
https://phabricator.whonix.org/T133


Mr. Robot Uses ProtonMail, But It Still Isn't Fully Secure | WIRED nailed it perfectly,

Of course, this doesn’t mean ProtonMail couldn’t give the government plaintext messages—just that it would require ProtonMail to actively attack you and steal the required password.

A way around that would be the browser add-on. Then they would have to ship the backdored add-on to everyone and then there would be evidence that there is a backdoor.

I don’t think an add-on will find widespread adaption either. It would be another nice geeky nice-to-have but that’s about it.

What could help with widespread implementation and strong security would be implementing DIME inside Firefox and Chrome browsers. Then if a backdoor was demanded to be added, it would affect the whole user base of these browsers. With public source control systems (git…) and reproducible builds this would have a very good chance of detection. (Much more people involved than just a few people using some unpopular browser add-on.)

Someone feeling awesome to check if that was suggested / can suggest that to them?


While that is really awful, doing that was not doing that is only security by policy (a promise), not security by design.

That is hard since meta data hiding is currently provider specific and very far from widespread adaption.

Yes, that would be great!

On the other hand, e-mail even with enigmail, I am not sure usability is so broken beyond repair, unencrypted subjects and meta data, that at the current state the most sensible thing would be to discourage using e-mail for private communications.

I haven’t looked enough into replacements like bitmessage, freemail, pretty Easy privacy (p≡p) and whatnot.

As per Post-Quantum Cryptography (PQCrypto) it does not seem too sensible to me to start recommending a replacement that gets broken in ~ 10 years anyhow. So PQCrypto safe seems like a sensible criteria.

Depressing stuff. Email really is horse & buggy insecure shit to be honest. That’s why I prefer to rarely use it.

When you add the future busting of most encrypted content via quantum computers, one can only really state to the very high-risk individual:

  1. Don’t communicate electronically if possible; or

  2. Use one-time pad software that is informational theoretically secure (& hope and pray your computer isn’t already backdoored or the RNG isn’t backdoored or non-functional); or

  3. Resort to OTPs where IN/OUT pads are generated by hand using dice and obscure your message with steganography that is plausibly deniable e.g. WPS method (otherwise your encrypted message will attract attention like flies to shit). Meanwhile, also hope the ciphertext hasn’t changed in transit, since there is no message integrity available in your implementation; or

  4. Forget email altogether, and instead shift to instant messaging e.g. Ricochet as a hopeful alternative - that is, peer-peer, meta-data free, server-free, and run via Tor hidden services. Again pray that Tor hidden services don’t have a host of chronic undiscovered bugs (unlikely), nor the experimental Ricochet software itself.

Yeah - sad state of affairs indeed, particularly the fact that we even need to have this discussion on the extreme lengths one has to go to in order to guard our personal affairs from supposedly ‘democratic’ governments.

Has anybody tested that AnnealMail (quantum-resistant) implementation of Enigmail? That might be worth writing up alongside a basic outline for secure PGP key generation and Enigmail with Icedove when/if I get around to it. I might test it for laughs.

The others programs referenced e.g. Codecrypt looks horribly user-unfriendly from the references I’ve glanced at, and the OneTime program (and paradigm at large) basically has zero usability, for obvious reasons like having to exchange pads in person or via trusted peers.

PS What is DIME? Couldn’t find an easy reference.

2 Likes

Dark Internet Mail Environment (DIME) as per https://lavabit.com/

1 Like

Codecrypt is really a PQ gpg drop-in replacement - a crypto engine/backend not meant for end users. Thats where AnnealMail comes in. I got it successfully building but without Codecrypt in Jessie I couldn’t test further. I would be happy to work with you on a step by step guide when Whonix Stretch releases.

1 Like

Last I saw DIME support is in Thunderbird is worked on a fork called Volcano behind closed doors.

Nonetheless if you think this belongs better in the browser I’ll see what I can do.

Email is a pile of shit however its going nowhere. The best thing is to point people to use modern secure alternatives with backwards compatibility so they can interoperate. For those who know people who are smart enough the messages will never exit the secure network between them.

HulaHoop:

Last I saw DIME support is in Thunderbird is worked on a fork called Volcano behind closed doors.

Dark Mail Alliance - Wikipedia

Nonetheless if you think this belongs better in the browser I’ll see what I can do.

Yes, please do (if you think DIME is worthy or promising).

DIME support in Thunderbird is great. DIME support in browser would be
even greater.

It’s not so much about good/better. For widespread adaption, it needs to
be included everywhere. And users using webmail in browsers are a large
group.

Good day,

Well, the thing is, historically, E-Mail’s were never designed to be used in the way we are using them now. Just like a lot of other standards today used as a basis for network based communication, the idea and implementation used today was created by scientists which didn’t really see what they had developed as being used in such a major way as it is today.

There was one differences though, between E-Mail’s (or MAILBOX, as it was called at MIT) and other standards used to this date like HTML. Whereas the latter was designed as somewhat of a standard which could be expanded, E-Mail (or what we call E-Mail today) wasn’t really made with that in mind. Part of this, at least as far as I can tell, was likely the fact that while HTML was first made public in the 80s, MAILBOX came out almost two decades before it. Because of this, mailing is a lot older then the Usenet, the Internet, or even ARPANet. A lot of things we know about how to make a standard futureproof and adaptable for new requirements thus was learned via the evolution (or rather lack there off) of E-Mail’s. And while it was in the 70s somewhat introduced into ARPANET and latter the Internet, with SMTP, most of the basic design stayed the same. The format we use for mail addresses (nameofsystem/user@server/systemused) as well as the simple nature of the whole process thus has been kept the same ever since the days in which it was only used by scientists to communicate with eachother.

That’s why the standard doesn’t include encryption. That’s why the standard can’t verify who was the real author of a message. That’s why you may impersonate anyones mail address with ease. It just didn’t evolve or improve like HTML or other standards have.

The only changes we’ve seen were SMTPS (which is the implementation of SSL on top of SMTP) and Extended SMTP, which as far as I’m aware mainly introduced a few new commandos.

Thus, looking at it, there appears to be no genuine effort in improving what we currently call E-Mail. Maybe SMTP just isn’t flexible enough to make any significant improvement in regards to verification and encryption.

Though it seems to be getting replaced for better or for worse anyways. Love them or hate them, but modern Instant-Messaging-Services have a better encryption and user verification standard than mail ever will. And for as much distaste as we might have for the practices employed by Whatsapp, Telegram or Signal the fact of the matter is that when it comes to giving the average user a rudimentary surface level protection from surveillance, they can only be rivaled by SSL.

So, long story short, it seems that the issues found in E-Mail will be somewhat solved not by improvements to the standard, but by replacing them all together.

Have a nice day,

Ego

1 Like

Done. Asked the TBB/Mozilla uplift team and Google’s Adam Langley.

1 Like

That’s great. Let’s see if they pick that up. If not, please create a pubic feature request ticket on their tracker.