mastodon - Link to source

Don't believe those who loudly claim email can not avoid metadata! They are ignorant of our continuous works on minimizing metadata:

DONE:

- no phone number other identifying data needed
- no cleartext "Subject"
- no cleartext "To"
- randomized "Date"
- no IP addresses
- group/avatar/attachment/etc metadata only contained in encrypted message parts

Upcoming:

- servers to never see cryptographic ID metadata
- remove "threading" and auxilliary headers
- experiment with Sealed Sender

reshared this

in reply to SkyLuke

mastodon - Link to source

Delta Chat

@SkyLuke This is basically what we do with chatmail.at/ setups. Only encrypted messages are allowed, the clients encrypt everything (Subject, To, Date etc. using rfc-editor.org/rfc/rfc9788.htm…). Transport encryption using TLS >=1.2 is enforced, clients use TLS 1.3. Spoofing is not possible because of strict DKIM requirement (no legacy mechanisms like SPF, no probabilistic spam filtering).

Chatmail

Chatmail provides FOSS infrastructure for interoperable, secure, speedy and reliable end-to-end encrypted messaging. Check out clients as Arcane Chat, Bots or Delta Chat today!
chatmail.at
@SkyLuke
in reply to Delta Chat

mastodon - Link to source

SkyLuke

Yes, but my college email is from Google... Not much I can do... I can use other services for personal use. Also, literally, if a service can just provide semantic search for emails, without generative ai crap, just similarity search in a high dimensional encoding space, and it runs in my computer with a really small open source model, that would be perfect. I know I could do it myself, but it is another side project...

That is just a suggestion for you guys. Do semantic search in a private conscious way. There is no need for expansive crappy text generation on top, just the semantic search and sorting by similarities. My cellphone does this even offline for settings. So it is probably something the client can do just fine.

in reply to Delta Chat

mastodon - Link to source

Adam Katz

thoughts from an anti-spam professional:

If the unencrypted Date header is more than a few hours off, it is likely to be blocked as spam. Randomly skewing it by up to 1800 seconds in either direction should be safe. Changing the time zone to grossly mismatch the geoIP is probably unwise, though +0000 is fine.

I suspect you're trying to make your headers super generic with all the important and identifiable aspects (and metadata) in the encrypted body. That's a good move, just be careful about spam filters.

⇧