So I've given @mailfence a very quick test on their Free tier.

That seems to be quite reasonable alternative for e-mail services. In som parts it's what I would expect @mailbox_org being. Except of one thing: Unencrypted incoming e-mails will not be stored encrypted.

Since I'm on the free tier currently, I've not tested the IMAP integration.

The weakness of #Mailfence and #Mailbox are that the PGP setup requires some efforts to happen. The "settings" panel on Mailfence is cleaner and better organized than mailbox.org, but the latter one is capable of ensuring all received e-mails are stored encrypted - regardless if it was encrypted at arrival or not.

PGP key management is still not as easy as it should be for non-tech users. "It should just happen automatically", is my stance here. It's close to being good, but you need to explicitly enable encryption on each mail you send - unless you reply to an already encrypted mail. This will confuse users and it will result in more unencrypted mails sent than intended.

Neither Mailfence nor mailbox.org will decrypt encrypted Subject fields.

I've briefly tested the WebDAV integration, which seems to work. But WebDAV is not end-to-end-encrypted, so uploaded data will not be stored in so-called "zero access" mode. This means the Mailfence people managing their servers can access and read your data. This will be the same for CalDAV/CardDAV too (calendar and contacts synching)

Mailbox.org recently announced they will upgrade their login system - which is long overdue. Their OTP setup is currently just confusing and very far from user friendly. Here Mailfence is very straight forward.

Both Mailfence and #mailbox_org still got quite a long way to provide a properly privacy enabled service. They're on a good path, but currently far from the capabilities of @protonprivacy, even on the most basic features in e-mail.

#openpgp traditions and #signal both bind a cleartext identifier, phone number or email address, to a cryptographic key. It opens up attack vectors as the servers/orgs controlling this binding can interfere.

#deltachat avoids such cleartext identity bindings by creating random #chatmail addresses, as transport only. The cryptographic key becomes the identifier and we want it hidden from the transport layer. Only people being in end-to-end encrypted chat need to identify each other, after all.

Delta Chat es demasiado buena

https://fediverse.tv/videos/watch/21b54e75-f8ae-4a61-919c-a7d264f67b57

»Gmail Gets End-To-End Encryption From Google As 21'st Birthday Present:
[…] Google Claims To Have Invented An Entirely New Type Of Encryption For Gmail Users […]«

This is not an April joke and yes Google offers OpenPGP for Gmail Accounts. This is not difficult to set up but too many people are too lazy in my opinion.

https://www.forbes.com/sites/daveywinder/2025/04/01/gmail-gets-end-to-end-encryption-from-google-as-21st-birthday-present/

We are not aware of other FOSS development teams that have as extensive knowledge, both theoretical and practical, about #email and #openpgp and regularly release across all platforms for users world wide ... except for #protonmail with whose technical and security experts we discuss regularly. They are the other major game in town doing pervasive email encryption after all. Did you know that Proton's and delta's VCards are compatible across ecosystems and establish immediate encryption?

@mathilde #chatmail server users don't have these problems because they don't even need to know their password or email address. Messages in delta chat are stored locally and the server only stores them for a limited time, up to 20 days by default, so all devices have a chance to download the message. Blocklists are also not used, the only requirements are #DKIM signature and #OpenPGP encryption.

The downside of our project approach was that we often got experts being very dismissive on re-using email and #OpenPGP ... and there still is some opposition which often subsides when actually trying #deltachat and #chatmail, looking at security audits and our strong usable security focus.

There may also be surprising upsides. The UK "Online Safety Bill" which attacks end-to-end encryption integrity seems to not apply for ... e-mail. Because everyone knows, e-mail is unencrypted, right? :)

Has anyone here on #fedi figured out the correct recipe for dealing with #OpenPGP, #DMARC and #mailman ?

The problem, by default mailman will modify messages and this will break the dkim signature.
https://gitlab.com/mailman/mailman/-/issues/1079

Mailman provides two DMARC mitigation options (other option is reject or discard which is not useful in this case).

1. Replace the from address with list address
2. Wrap original message in an envelope

thunderbird flags 1 and fails 2.
#askfedi #gnupg #gpg #thunderbird

New Privacy Guides article
by me:

If you are using a YubiKey,

you might get in some situations where you need to reset your key to factory default, and/or set up a backup of it on a spare key.

This tutorial will guide you
through each step to reset and back up your YubiKey successfully, with clear instructions and plenty of visual support.

I hope you find it helpful!

https://www.privacyguides.org/articles/2025/03/06/yubikey-reset-and-backup/

I made a couple of changes to sopass, my command line password manager that uses a Stateless OpenPGP implementation for cryptography.

* It no longer creates the configuration file.
* It has built-in help for all sub-commands, options, and other command line arguments.

There is also a rudimentary manual page.

https://sopass.liw.fi/

Initializing a new project - Interplanetary Markdown. Might explore a #Web3 (off-chain) approach later for a better experience, but for now, keeping it simple with good old #OpenPGP.

A censorship-resistant #Markdown publishing platform, enabling seamless content distribution. Powered by the Interplanetary File System (#IPFS), ensuring #blogs, #articles, and other written content remain accessible and verifiable across the distributed web.

https://github.com/rvnrstnsyh/cupoftea

@libreoffice

The #Libreoffice Youtube channel is posting a lot of interesting talks from the "Libreoffice and #Opensource Conference 2024"

Some of them:

#LuxChat for Governments: https://www.youtube.com/watch?v=JXdMKaEXq0Q

#OpenDesk on #OpenCode: https://www.youtube.com/watch?v=rVhAltODe-M

#Education: https://www.youtube.com/watch?v=V4fkWfuFXfo

#Encrypted and #Signed Documents (UI, with #OpenPGP or #x509): https://www.youtube.com/watch?v=W-qFr8tL-LE

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Good afternoon, folks! Just a quick reminder: PGP isn't dead. Sign with pride!

Signed with my GPG key: 1BBD C23D 1853 255D 6415 D2EC 814E DF85 1AAB 370E

#OpenPGP #GPG #Cybersecurity #Tech #DigitalIdentity #SignYourCode
-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQTHaQ+iFRwfaXx+TxhjUbpCCVDiNAUCZ7cd5gAKCRBjUbpCCVDi
NOZSAPoDPFoZXKuxya98iY6nAV6hzgOghpqF/OtOVSW4qtEdMQEA3x/jqaD4R9vo
qi89wA4Hsd4KeqwTSQxKDECesI+W8QU=
=3gty
-----END PGP SIGNATURE-----

Isn't it poetic and ironic that out of all possible time lines we are in one where #securejoin #openpgp protocols on top of the existing #email protocols offer the arguably most solidly scaling, useable, world-wide federated end-to-end encrypted messaging reality, safe against compromised #mitm servers? Hundreds of billions spend to create "the email successor" and here we are in 2025 .... #interoperable #email and #cryptography as the tortoise looking at Achilles through the back mirror :)