Assume I'm mike@example.com and I'm sending a message to dave@example.org. "sender if you want ACK" The example.org service doesn't need to know the sender ad

Assume I'm mike@example.com and I'm sending a message to dave@example.org. "sender if you want ACK" The example.org service doesn't need to know the sender address. It only needs to know a method for prompting the sending server to send an ack to whoever the sender of the incoming message was. "recipient so you can deliver the message" My own mail service only needs to know that I'm sending a message to somebody at some domain managed by the example.com server. It doesn't need to know that I'm sending it to dave@example.com. A better mail system (from a privacy perspective) would be one where the routing logic was handled by the email client first, and the outgoing mail server was just a dumb queue. Imagine I'm sending the email to dave@example.org: My email client encrypts the message body, subject line and sender address with dave@example.orgs public key. It then looks up the IPs of the MXs, and their public keys. It then adds the recipient address (encrypted with those public keys) to the message. It then connects to my outgoing mail relay, tells it the list of IPs to try, and passes the encrypted message on. When the message is passed on from example.com's servers to example.org's, they can decrypt the recipient address and pass on the message to that recipient. dave@example.org can decrypt the message and sender address after downloading it. If you want to retain the "bounce" capability rather than example.org just refusing the message at SMTP time, example.com could pass a unique identifier with the message when it sends it to example.org. Then example.org can just send the bounce back with that unique identifier, and example.com can then map that unique identifier to the original sender.