This is coming from a general perspective of wanting more privacy and seeing news of Mozilla creating an email service “which will definitely not train AI on your email”. Sure Mozilla, whatever you say.

Rant aside, here’s my question: is it possible to store all of your email on your own infrastructure (VPS or even NAS at home) and simply using an encrypted relay to send emails out to the public internet? My idea is that this removes the problems of keeping your IP whitelisted from the consumer, but the email provider doesn’t actually hold your emails. This means your emails remain completely in your control, but you don’t have to worry about not being able to send emails to other people as long as your storage backend is alive.

I don’t know much about email to comment on what this would take. I think something similar is already possible with an SMTP relay from most email providers, but the problem is that my email also resides on their servers. I don’t like that. I want my email to live on my servers alone.

Do you think this is possible? Does any company already do this?

Thanks

  • InnerScientist@lemmy.world
    link
    fedilink
    English
    arrow-up
    8
    arrow-down
    1
    ·
    21 hours ago

    Only thing I can comment on is that 99% of all E-Mails you will get are unencrypted and can be read by your relay. (There are few e2e encrypted emails being send.)

    So either trust them or don’t use a relay.

      • InnerScientist@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        2 hours ago

        The emails are unencrypted, emails in transit are in transit between the e-mail servers and relays and use secure tls channels.
        They are only encrypted from your phone/notebook/browser to the server, then when send they will be encrypted till the next server.

        Every server/relay first decrypts everything send to it, because it has to due to the TLS terminating at each server.

        See also your source:

        Transport Encryption: This form of encryption is used to secure your emails while they are transmitted over the internet. Most of today’s email services, including Gmail, employ transport layer security (TLS) to protect emails in transit. While it encrypts emails between servers, it doesn’t protect the content once it reaches the recipient’s inbox.1

        In practical terms, Your e-mail server, your e-mail servers relay (if it has any) and your recipients relay server/server can all read your email unless

        End-to-End Encryption (E2EE): E2EE takes encryption a step further. It ensures that only the sender and the recipient can decrypt and read the emails. Even the email service provider cannot access the contents of the email. E2EE is typically achieved through third-party encryption tools or services.1

        Which takes active effort from both the sender and the recipient to make work - it’s almost only possible with people you know and little else.

        1 https://umatechnology.org/gmails-new-encryption-can-make-email-safer-heres-why-you-should-use-it/

    • litchralee@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      3
      ·
      21 hours ago

      This 100%. It is well-advised to consider what your security/privacy objectives are, since encryption-at-rest is different than guarding against eavesdropping when sending outbound mail. What threat model you use will define what is or isn’t acceptable.

      • Onomatopoeia@lemmy.cafe
        link
        fedilink
        English
        arrow-up
        5
        ·
        20 hours ago

        Yep.

        Rather than try to single-handedly re-engineer an old protocol to be secure, I just use it for stuff where security isn’t a big deal. Including messages with links to secure resources (and send credentials via a separate system).

        • litchralee@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          4
          ·
          edit-2
          20 hours ago

          Agreed. Email has its uses – ubiquity, mostly “Just Works” ™, most people know how to use it – and while I might send a symmetric encrypted PDF along with a plaintext email, I’m more inclined to suggest that my recipients adopt Signal and get all the benefits of e2ee. EFF even has a guide for it: https://ssd.eff.org/module/how-to-use-signal

    • Dropper-Post@lemm.ee
      link
      fedilink
      English
      arrow-up
      2
      ·
      20 hours ago

      Sorry are not emails like https protected in transit in 2025? I mean equivalent http to https but in email transport. How is this still a thing? Why nobody is concerned. Is this not a problem?

      • bw42@lemmy.world
        link
        fedilink
        English
        arrow-up
        12
        ·
        20 hours ago

        Communication between the email servers is normally encrypted with TLS. The email files themselves are rarely encrypted. Most providers that do encryption of email are using local server managed encryption, so the email providers would still be able to access it.

        For proper end to end protection you would want to setup PGP between you and your recipients, and encrypt the email before its sent.

        • Dropper-Post@lemm.ee
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          1
          ·
          20 hours ago

          But like in 2025 there is still no mechanism to do true end to end without manually setting up pgp? Meaning when i browse using https i do not need to think or anything. It happens automagically. But with emails, where do i even start with pgp when i use gmail via email client like thunderbird

          • markstos@lemmy.world
            link
            fedilink
            English
            arrow-up
            3
            ·
            4 hours ago

            Https give you encryption in transit. The files you view will be accesible to the host.

            Same idea with email.

          • No.

            Use S/MIME or PGP and directly encrypt emails to your recipient. This is the only E2E encryption available to email.

            The best metaphor for email I’ve found is that you’re writing your message on a postcard and handing it to your neighbor closest to the destination, who hands it to her neighbor, and so on, until it gets there. There are usually fewer hops, but also your email is broken into packets which could go through god knows how many routers, each of which can read your email.

            E2E requires setting up a private key; RFC 821 provided no such mechanism. Your only option is out-of-band negotiation, like PGP.

            There is a good proposal out there that sets mail headed announcing that you accept encrypted emails, and includes information about your ID, which clients could parse and verify against public key servers; it hadn’t really gained a lot of traction, as it causes issues for data harvesters but also at the end user side. Like, how is notmuch and mairix supposed to handle these? They’d need permanent access to your private key to decrypt and index the emails, and then now your index is unencrypted.

            There’s been a fair amount of debate about this, and it’s a lot of work that would need coordinating between teams of volunteers… it hasn’t made much progress because of the complexity, but it’s a nice solution.