{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigqv3qh2q3ktlejag2tu3mhiqtqwuzefdlcvgwrarfiqx53unq7vq",
    "uri": "at://did:plc:haakkg7y3xdghcdmprxeexso/app.bsky.feed.post/3mkv3nok5qnf2"
  },
  "path": "/t/forward-email-new-features/24845?page=7#post_146",
  "publishedAt": "2026-05-02T15:15:49.000Z",
  "site": "https://discuss.privacyguides.net",
  "tags": [
    "https://x.com/DoingFedTime/status/2030108076531995016"
  ],
  "textContent": "dngray:\n\n> What is to say their source code on github actually matches what is on the server?\n\nThis is the ultimate email question, Signal has verifiable binaries, and as both sender and receiver use libsignal, we can indeed satisfy mathematically that its indeed e2ee.\n\nNow forwardemail has a frontend client, you can verify the hashes against the running code, and encryption can happen on the client side with providers that support keys via API, WKD and other forwardemail users.\n\nOn the inbound side you are trusting every email service there is no RFC that has made email e2ee yet.\n\ndngray:\n\n> As a result for a service like email transparency about who is running it, honesty about the service and it’s limitations are crucial.\n\nWhy not pull Proton from the recommended email services?\n\nhttps://x.com/DoingFedTime/status/2030108076531995016",
  "title": "Forward Email (new features)"
}