7 ms·

Included in our comparison list here https://forwardemail.net/en/open-source/linux-email-server#email-server-comparison https://forwardemail.net/en/open-source/

Included in our comparison list here https://forwardemail.net/en/open-source/linux-email-server#email-server-comparison https://forwardemail.net/en/open-source/linux-email-server#e...

codetrotter 3y ago
I think having “encrypted SQLite” as a column is a bit too specific, and biased to favor your own product in the comparison. I think a more fair column would be “encrypted at rest” – even if it comes out that your own solution is the only one that ends up with a green check mark.
- forwardemail 3y ago
  We also thought of renaming it to "Mailboxes Encrypted Individually". We really wanted to make it clear that each individual mailbox is encrypted. Any other suggestions?
  - robertlagrant 3y ago
    Why does that matter? As in if I as a user have three mailboxes, they're encrypted individually? Or each customer has their mail encrypted separately to other customers? I think the latter is worth mentioning more than the former (though if you're doing the former you're of course doing the latter also).
    - forwardemail 3y ago
      Correct, the former. There are no other open-source email servers (or closed even) that does the former that we know of. The deep-dive write-up is here if you want to read more https://forwardemail.net/encrypted-email https://forwardemail.net/encrypted-email. Edit: It matters because if someone has access to the filesystem, or our MongoDB database, then they still can't read/write to your email mailbox because they don't have your IMAP password (which we only show to you _once_ for 30 seconds and render in-memory). We use ChaCha20-Poly1305 encryption on the SQLite mailboxes (which is generally considered quantum-secure[0]). Passwords are generated[1] via Node.js `crypto.pbkdf2`. [0]: https://crypto.stackexchange.com/a/90311 https://crypto.stackexchange.com/a/90311 [1]: https://github.com/forwardemail/forwardemail.net/blob/d537fcee6aff81f17f5a1bc492c0edc93b2d53d1/helpers/create-password.js#L18-L35 https://github.com/forwardemail/forwardemail.net/blob/d537fc...
      - infogulch 3y ago
        I guess since you encrypt the whole sqlite db that means you can still offer indexing and FTS while remaining encrypted. But, the application would still have the encryption key in memory. So this protects against an attacker/bad-actor that can access the FS but not if they could access the memory space of the application serving mail items. Is that right?
        forwardemail 3y ago
        [dead]
      - robertlagrant 3y ago
        Thanks for the detail. Makes sense. On "matters" - I was distinguishing all of a customer's mailboxes being encrypted together vs their mailboxes being individually encrypted. I was saying that the former is the most useful point of comparison I'd want to see - is my data encrypted separately to other people's - not the latter. But I may not be representative.

Included in our comparison list here https://forwardemail.net/en/open-source/linux-email-server#email-server-comparison https://forwardemail.net/en/open-source/linux-email-server#e...

codetrotter 3y ago

I think having “encrypted SQLite” as a column is a bit too specific, and biased to favor your own product in the comparison. I think a more fair column would be “encrypted at rest” – even if it comes out that your own solution is the only one that ends up with a green check mark.

forwardemail 3y ago
We also thought of renaming it to "Mailboxes Encrypted Individually". We really wanted to make it clear that each individual mailbox is encrypted. Any other suggestions?
- robertlagrant 3y ago
  Why does that matter? As in if I as a user have three mailboxes, they're encrypted individually? Or each customer has their mail encrypted separately to other customers? I think the latter is worth mentioning more than the former (though if you're doing the former you're of course doing the latter also).
  - forwardemail 3y ago
    Correct, the former. There are no other open-source email servers (or closed even) that does the former that we know of. The deep-dive write-up is here if you want to read more https://forwardemail.net/encrypted-email https://forwardemail.net/encrypted-email. Edit: It matters because if someone has access to the filesystem, or our MongoDB database, then they still can't read/write to your email mailbox because they don't have your IMAP password (which we only show to you _once_ for 30 seconds and render in-memory). We use ChaCha20-Poly1305 encryption on the SQLite mailboxes (which is generally considered quantum-secure[0]). Passwords are generated[1] via Node.js `crypto.pbkdf2`. [0]: https://crypto.stackexchange.com/a/90311 https://crypto.stackexchange.com/a/90311 [1]: https://github.com/forwardemail/forwardemail.net/blob/d537fcee6aff81f17f5a1bc492c0edc93b2d53d1/helpers/create-password.js#L18-L35 https://github.com/forwardemail/forwardemail.net/blob/d537fc...
    - infogulch 3y ago
      I guess since you encrypt the whole sqlite db that means you can still offer indexing and FTS while remaining encrypted. But, the application would still have the encryption key in memory. So this protects against an attacker/bad-actor that can access the FS but not if they could access the memory space of the application serving mail items. Is that right?
      - forwardemail 3y ago
        [dead]
    - robertlagrant 3y ago
      Thanks for the detail. Makes sense. On "matters" - I was distinguishing all of a customer's mailboxes being encrypted together vs their mailboxes being individually encrypted. I was saying that the former is the most useful point of comparison I'd want to see - is my data encrypted separately to other people's - not the latter. But I may not be representative.