Tickets :: Comment on [#12736] Automatic S/MIME encryption

Search Results: 121 of 126 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]

* Your Email Address
* Spam protection	Enter the letters below: .___. __.. .___. __. \| (__ \| _/ (__ \| .__)\|___./__..__)
Comment	>>> The if-clause in line 55 of your patch doesn't make sense because it >>> can never be true, see the check in 39. >>> >>> This is a great start, thanks a lot! To be applied we would need at >>> least one of the two suggested solution for notifying about missing >>> encryption keys for certain recipients. >> >> Sure, the check in line 39 ensures that encryption is not already >> enabled before attempting automatic encryption. Line 55 ensures that >> if S/MIME signing is enabled it remains enabled in addition to >> encryption. >> >> I'm happy to contribute the remainder of the patch but I'm not sure >> how to best implement either option for notifying the user. I also >> posted on the dev mailing list for tips. Thanks! > > I've attached an updated patch that satisfies the discussed > requirements. Existing functionality changes only when automatic > S/MIME encryption is enabled in the S/MIME preference group. > > If public keys for all recipients are found, the message will > automatically be encrypted before being sent. Otherwise, the user > will be notified of the recipients for which a public key could not > be found. This notification will occur only one time, unless the user > adds additional recipients for which public keys can't be found, in > which case the user will be again notified. The notification is > identical to the one used for detecting missing attachments. > > Let me know what you think. This patch is actually pretty simple and > applies cleanly.
Attachment
Watch this ticket

Saved Queries