23075 - Don't quote "signed/encrypted mail not supported text"

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[lchiang]

Mozilla mail does not support signed or encrypted messages.  When a signed or an
encrypted message is encountered, we display some text in the message pane
informing the user of the situation.  This text brings up some concerns for
I18N.

Comments taken from http://bugzilla.mozilla.org/show_bug.cgi?id=21993 which
[e-mail] writes:

> We do quote the following text:
> "This is an ENCRYPTED message. Mozilla Maildoes not support encrypted mail."
> "This messages is possibly SIGNED. Mozilla does not support signed mail."

I have some I18N concerns. You can't insert this english string into a localized
version. But you can't insert a translated text either, as users with localized
versions potentially communicate with (for them) foreign correspondents.

E.g. I may want to see German text in my UI, but I don't want you to see German
text in my replys.

-- end comments --

Any ideas on what we can do here?

Comment 1

[Katsuhiko Momoi]

This is a classic problem of L10n.
One solution is to have an universal ID for the dialog
internally which then corresponds to the same message in different
languages depending on what language client you're using.

Comment 2

[Ben Bucksch (:BenB)]

momoi,
this is no UI text, it is in the quote, i.e. it is inserted in the text body of
msgs I create, and I send it out.
I'm sure, this is not the first time this problem appears (compare "<From>
wrote:"), but I don't think, it is acceptable.

Comment 3

[Katsuhiko Momoi]

I think we should separate the issues for display and sending.

For display, we display these additional info texts when displaying
any msg which is signed and/or encrypted. This means to me that
the texts are not in the received message itself but is inserted
by Mozilla in the process of sending the data to the layout.
For this part, I'm suggesting that we substitute appropriate
language text if one is available.

On sening/replying to such a msg, why do we need to quote
this text at all? Can we skip it in the quoted part?

Comment 4

[Ben Bucksch (:BenB)]

momoi,
this bug is only about replying/sending.
CCing rhp to answer your questions.

Comment 5

[Katsuhiko Momoi]

Let me add a bit more thoughts on this.

1. For legitimate RFC 822 headers, e.g. From, To, etc., there is no
   need to use translation. We should send them out as it is quoted
   including foreign names as content of such headers.
2. For warning like the one we are talking about here, we might want
   to take hints from MIME info which we or servers add to a
   msg, e.g. "This body part will be downloaded on demand.".
   We don't display this type of msg but it's in the source.
   Can we do something similar for quoting this type of info?
   So, 2 options I'm suggesting are:

   A. Skip this type of info in reply/quote.      OR
   B. Include it but in such a way to make it an optional
      text to display by mail agents. And you don't need to
      translate this type of text.

Comment 6

[Phil Peterson]

So, it seems like the right fix is to not quote the S/MIME message in replies,
right? Changing the bug summary to reflect that, and reassigning to rhp.

Assuming we can avoid quoting the vcard, how hard is it to avoid quoting the
S/MIME warning? If this is reasonably cheap, I'd like to do it, but if it's not,
you can push it out aways. It's way not a beta1 stopper in any event.

Comment 7

[rhp (gone)]

This is a simple fix. I have it in my tree and I will check it in when the tree
opens.

- rhp

Comment 8

[rhp (gone)]

This should be fixed now.

- rhp

Comment 9

[pmock]

Verified as fixed on win32, linux, and macos using the following builds:
 Win32 commercial seamonkey build 2000-080104-m17
 Linux commercial seamonkey build 2000-080104-m17
 Macos commercial seamonkey build 2000-080104-m17