Open Bug 442180 Opened 16 years ago Updated 2 years ago

when recipient cert isn't known, don't default to "Encrypt This Message" when replying to an encrypted message

Categories

(Thunderbird :: Security, enhancement)

Product:
Thunderbird
Component:
Security
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: donald, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: 2.0.0.14 (20080421) If you reply to an encrypted message that was sent to you, Thunderbird defaults to encrypting the reply. It does this even when you've set your Account Settings to send unencrypted by default. It also defaults to this even though you don't have a public cert for the recipient. The default should be whatever is set in Account Settings. Reproducible: Always Steps to Reproduce: 1. Receive a message that was encrypted (S/MIME) with your public key 2. Reply to the message 3. Observe that Thunderbird is going to try to encrypt reply, even though you don't have a public cert for the recipient installed. Actual Results: Clicking send brings up the error that the message cannot be encrypted. The user must then use the Options->Security menu to disable encryption in order to send. Expected Results: I expect a warning (with a don't show this again option) that replies to that recipient will not be encrypted.
Summary: Defaults to "Encrypt This Message" (Options->Security) Replying to an encrypted message → Defaults to "Encrypt This Message" (Options->Security) when replying to an encrypted message
Defaulting to encrypt is per design (bug 137071). Though I guess it could be smarter and don't do it if you don't have the recipient key to encrypt it with anyway.
Component: Message Compose Window → Security
QA Contact: message-compose → thunderbird
That would be wonderful. We have a system that acts as an encrypting proxy between the sender and recipient. It encrypts outbound mail auto-magically. The existing user experience takes away the ease of use that the proxy is trying to provide.
Changing summary and confirming RFE.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: Defaults to "Encrypt This Message" (Options->Security) when replying to an encrypted message → when recipient cert isn't known, don't default to "Encrypt This Message" when replying to an encrypted message
Donald, what is the name of this encrypting proxy? What exactly does it do? It sounds from your description like your TB client is receiving an encrypted email (rather than having the proxy decrypt it for you and hand TB a clear-text email). So I'm not sure what the proxy is doing. And why wouldn't your senders send their encryption cert? Or is the proxy interfering with that as well? As Magnus noted, this behavior is by design. If a sender wants to have an encrypted conversation, the correct behavior is for you to reply (which will usually include the original email) also with an encrypted email. You should have to do some work to override the other sender's implicit desire for confidentiality. But I'm still interested in learning more about this proxy.
Folks, this bug report describes an issue with a significant impact on usability. I encounter this situation in about 30% of the replies that I send, meaning that sending a reply often involves this annoying series of clicks to change the encryption status of a message when TB should have been smart enough to not be trying to encrypt it in the first place.

I would urge this to be set to a Won't Do status (or equivalent).

Professionally, I think dropping the encryption requirement on replies is a terrible idea. If someone sends you something sensitive and has encrypted it to protect the info, and you reply, but because you don't have the sender's current certificate, you send your reply (probably containing the sensitive information inside your reply) as plain text, you've violated the sender's intent of privacy. Worse, if it changes status to plain text automatically, you may not have intended to do so.

If you really do want to take responsibility for removing the encrypted status, it is only two clicks.

Peter (Comment 5) & I work in the same group. Since I have basically the same environment as Peter, I would suggest that what he is missing is the essentially automatic access to the public keys of the recipients. We do use a LDAP server to supply those (they expire yearly), but in order to ensure company privacy and assurance of the LDAP data, the LDAP server can only be accessed internally (or via VPN). We often reply to mail when we aren't internal (at home, at an airport, etc.). Always using a VPN would solve this problem (at the cost of other inconvenience).

Another alternative would be the automatic retrieval of new keys for individuals in your address book whose keys have expired, say when you initially contact the LDAP server or once a day. I'm not sure how that scales over the years & size of address book. You can download the LDAP server info from within TB, but it is only used for offline use. So, if you are online but can't contact the LDAP server, you can't use it. But those would be different RFEs.

I have configured my email provider to automatically encrypt all incoming messages for myself. If I now reply to such an automatically encrypted message, Thunderbird always tries to encrypt my message even when setting encryption to "default off", which is very annoying. It would be great to have more fine-grained options like

  1. Always try to encrypt (and show warning/error if keys are not available).
  2. Always encrypt if keys are available.
  3. Always (try to) encrypt replies to encrypted messages. (This could be split into two separate options similar to 1 and 2.)
  4. Never encrypt by default.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.