When composing a message, the 'digitally signed' attribute it not set when switching the sender field



MailNews Core
15 years ago
7 years ago


(Reporter: Chris, Unassigned)


Firefox Tracking Flags

(Not tracked)





15 years ago
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

Expected Results:  
Change the 'signed' status whenever I choose a different sender identity.

Comment 1

15 years ago
Chris, I agree with you.

But the current behaviour isn't a bug. Look at
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.
Last Resolved: 15 years ago
Resolution: --- → WONTFIX

Comment 2

15 years ago
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.

Resolution: WONTFIX → ---


15 years ago
Component: Composition → Security: General
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All

Comment 3

15 years ago
*** Bug 235403 has been marked as a duplicate of this bug. ***

Comment 4

15 years ago
*** 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 ;-).
Product: MailNews → Core
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


10 years ago
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.