> Transport encryption and end-to-end encryption are not conflicting goals. On that we agree. It's better to have both. Even if you already have end-to-end enc

> Transport encryption and end-to-end encryption are not conflicting goals. On that we agree. It's better to have both. Even if you already have end-to-end encryption for the content, transport encryption helps to avoid leaking metadata about who the message is being delivered to. > I refuse to accept the defeatist view that "encrypted email cannot be made mandatory without breaking compatibility anyway". Whether you accept it or not, if you reject unencrypted messages, or insist on only sending encrypted messages, then you aren't interoperable with today's email system. That's not a defeatist view, it's just being realistic. And as we've seen with GPG, if you don't insist on encrypting everything then encryption will not be used—or worse, it will be used inconsistently, as in the case of someone sending an unencrypted reply which quotes an encrypted message. > I'm interested in protecting people who think that email should be safe in transit — the same expectation that postal services give them about their mail today — by seeing everyone who operates an email server enable transport encryption. Plain email can be improved somewhat but it's still essentially the same as writing your message on a postcard. Transport encryption is akin to physical custody of the mail; it's useful but not sufficient. The only people who would see your postcard while it's in transit are postal workers, and yet people still use envelopes to keep their messages private from the people handling the mail. Transport encryption does nothing to help in that area and does not fulfill the expectations that people have in regard to postal mail, which are based in large part on legal codes and physical properties which do not apply to email. To get something similar to a message in an envelope the content must be encrypted end to end, not just at the transport layer.