I see in https://github.com/k9mail/k-9/wiki/Crypto-Design-Thoughts
that there is a notion that it's broken to encrypt but not sign. However, I see this pattern quite often, where people don't particularly want to cryptographically bind statements to themselves, but do want confidentiality. I see the point about not providing a keyid for the reverse direction, but signing isn't really intended to do that. However, I realize that the UI becomes hard. So I'd suggest for config signing: never, if-encrypted, always and perhaps if-encrypted is not necessary, but I bet some people want it. For encryption, I see encrypt: never, if-available, if-available, always I think per-recipient policy is needed; the point is to force it to always for people that you know have keys and that want encrypted mail. Probably this should be stored in contacts, as a property, and be general, but it could be a lookaside table in k-9. Finally, when replying to a message that was decrypted, policy should be forced, more or less, to encrypt always. It should take significant effort (popup with warning) to send an unencrypted reply to an encrypted message, with or without quoted text. -- -- You received this message because you are subscribed to the K-9 Mail Users List. To post to this group, send email to [email protected] To unsubscribe, email [email protected] To report an issue with K-9 Mail, visit http://code.google.com/p/k9mail/issues/list For more options, visit this group at http://groups.google.com/group/k-9-mail --- You received this message because you are subscribed to the Google Groups "K-9 Mail" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
