User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 If I compose a message and the original sender identity does NOT have digital message signing enabled, when I switch to a sender identity that DOES have digital signing enabled, the message is not signed, by default, as it should be. I must manually select this option. The message is _encrypted_ by default, if appropriate, just not signed. Reproducible: Always Steps to Reproduce: 1. Select a mail identity that does not have digitial signing configured 2. Hit the compose button 3. Switch the sender identity to a selection that has digital signing turned on Actual Results: The message is not signed, unless I manually select signing from the security button. Expected Results: Change the 'signed' status whenever I choose a different sender identity.
Chris, I agree with you. But the current behaviour isn't a bug. Look at http://lxr.mozilla.org/seamonkey/source/mailnews/extensions/smime/resources/content/msgCompSMIMEOverlay.js#381 and you'll see that it's intended. See bug 106988 (the one introduced this behaviour), especially comments #9 and #16 for more information. I close this bug as WONTFIX since the current behaviour turned out to be a wanted feature and I don't think a change will go through. Please reopen if you don't agree.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WONTFIX
I have read the bug you mentioned (106988) and commented on it. From my reading of that discussion, it seems the only justification for not signing messages by default (when the user has requested this behavior) when you switch to another identity while composing a message is: a user might accidentally sign a message that he/she did not indend to sign. This is illogical because the _whole purpose_ of the sign-by-default setting is to sign-by-default! If there is really a need to protect users from accidentally signing messages, then that feature should be removed entirely. Otherwise, it should work as advertised! If it is necessary to notify the user that the signing settings have changed, then some GUI instrument should be employed to accomplish that goal, such as flashing/highlighting the icon, rather than ignoring the settings configured by the user. Somebody in that discussion said (paraphrased) "protecting the user is more important than a little inconvenience". Unfortunately security guys have been saying that for years and users _still_ write down passwords on sticky notes. If security is to work, it must be easy. If a user has to select the 'sign this message' button for EVERY message they send, most will not bother. Please reconsider. "Sign by default" should work as advertised, regardless of which identity I started composing the message with.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Status: UNCONFIRMED → NEW
Component: Composition → Security: General
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
*** Bug 235403 has been marked as a duplicate of this bug. ***
*** Bug 237903 has been marked as a duplicate of this bug. ***
I agree with Chris that messages should be signed when the account that is switched to has "Signed by Default" enabled. If the user switches away from that account into an account that does not have "Signed by Default" enabled, then the message should not be signed, though I think that if the account that is being switched into is signable and that account does not have "Signed by Default" enabled, then the UI should warn the user _if_ the user changed the signature setting for the e-mail message through the UI (if the user didn't explicitly change the signature setting for the currently open e-mail message, then it can go back to unsigned without telling the user). Just my $0.02 as an end-user and, perhaps eventually, future Mozilla developer ;-).
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: esther → security
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.