190120 - Following mailto links always spawns plain-text Composition windows regardless of "Compose Format" setting

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect)

Description

[Blu3]

Clicking on mailto links or using right click->compose to in messenger creates
plain text compose windows.  Easily duplicated by anybody.  My default compose
method is HTML.

Comment 1

[David Campbell]

Yes, I am having the same symptom.  You can see that when you click a mailto:
link, the composer window you get has no gui components such as bold, underline etc.

Comment 2

[John A. Carlson]

I am encounting this problem with 1.3B on a Windows 2000 SP2 machine.  I did not
have the problem with 1.1.

Comment 3

[Greg K.]

*** Bug 182446 has been marked as a duplicate of this bug. ***

Comment 4

[Greg K.]

Also reproduced using FizzillaMach/2003021203. Setting All/All. I could've sworn
this was a dupe, but I can't find the original report at the moment.

Comment 5

[R.K.Aa.]

sounds like a dup of bug 167815, but that one was fixed on Jan 30th.

Comment 6

[Greg K.]

See the build ID in my comment 4.

Comment 7

[R.K.Aa.]

Yes, i saw that. And i have no idea what was fixed in bug 167815 - mailcompose
comes up in plaintext mode here too when i click a mailto link in the browser.
(current CVS). Perhaps bug 167815 should be reopened.

Comment 8

[[e-mail]]

My understanding is that plain text is used for security reasons.

Comment 9

[R.K.Aa.]

*** Bug 180453 has been marked as a duplicate of this bug. ***

Comment 10

[R.K.Aa.]

*** Bug 183084 has been marked as a duplicate of this bug. ***

Comment 11

[R.K.Aa.]

*** Bug 183603 has been marked as a duplicate of this bug. ***

Comment 12

[R.K.Aa.]

*** Bug 191069 has been marked as a duplicate of this bug. ***

Comment 13

[R.K.Aa.]

*** Bug 176504 has been marked as a duplicate of this bug. ***

Comment 14

[R.K.Aa.]

*** Bug 183359 has been marked as a duplicate of this bug. ***

Comment 15

[R.K.Aa.]

*** Bug 183233 has been marked as a duplicate of this bug. ***

Comment 16

[tom]

"RESOLVED INVALID" is a not acceptable resolution since this behaviour will
block workflows.
For example I use a HTML-Page which gives me a full Mail template with
references  from a database. The current behavior of Mozilla does not create a
useful mail template and it can't be used anymore.

I will not reopen this bug but I look forward to more comments for this bug and
perhaps another one who will reopen it.

Comment 17

[R.K.Aa.]

*** Bug 189407 has been marked as a duplicate of this bug. ***

Comment 18

[Blu3]

Might I ask how it's a security risk?  The email address that is opened for
composition is already stripped of everything except [e-mail].  A mailto
link can't be any more dangerous than any other link, particularly links for
javascript.

It's highly undesirable to force plain text composition.  I use HTML mail for
the majority of the data I pass around.

Stating that plain text compose is forced because it's a security risk sounds
suspiciously like a lame excuse to discourage HTML mail.

One can easily 'reply' to HTML mail which can contain every bit as much of a
security risk.

Comment 19

[John Coonrod]

Here here! I strongly disagree with the crippling of mailto capability. I don't
know of any other email client behaving this way. If it's an unproven concern,
it could be made a preference setting option, "[ ] Disable HTML compose on MailTo"

Comment 20

[Tobias]

in difference to compose a "normal" message (html or/and  plain text) the menu
"options-format" is also not there in the message window if you click on a
mailto link.

I say the click on a mailto link should open the mail client in the way it
usually opens when someone is creating a new mail. This mailto link is often
used to simplify email communication by not typing in the mail address - it
would just confuse users if the mail client looks different than they are used to.

Comment 21

[Ed Jones]

  > "it would just confuse users if the mail client looks different than they
are used to."

It certainly does me!

Moreover,its a real pain. Every time I click on a "Contact us" link and want to
use italics, or paste in a URL, I have to
1) Swear
2) Open a new compose message window
3) Go to the first message, copy the recipients address, go to the new message
and paste it.
4) Go back to the first message, copy the text of my message, go to the new
message and paste it.
5) Check the subject I put in the first message and type it into the new message
6) Add the URL or text style I wanted.
7) go back and close the first message before sending the new one.

I have to do this all the time.
Are we that nuts for thinking this a pain? 

Comment 22

[R.K.Aa.]

*** Bug 198044 has been marked as a duplicate of this bug. ***

Comment 23

[Gilles Gravier]

Methinks that the developers consider it too much a hassle to fix. Pity. People
will just go back to Netscape 7.

Comment 24

[rhyslin]

If security is the primary concern, then maybe the enhancement mentioned in bug
140800 offers the solution: allow a user to change the compose window on the fly
between text and HTML.  I presume that by first opening the window in text mode,
any "offending" text is either removed or shown very explicitly (so it can be
edited before the switch), or when switching from text to HTML, tags are treated
as text.

Comment 25

[Joshua Nixon]

there are a lot of people i contact by clicking mailto links in our university
or department directory - aside from making it an incredible pain to send
anything in html format, the plain text ruins my html signature file. a minor
annoyance that, but i use a plain text sig file when sending plain text. if i'm
at my desk running moz mail i want to send in html.

i agree with above comments - if it's a security "feature" i at least ought to
be able to turn it off.

Comment 26

[Sander]

*** Bug 199886 has been marked as a duplicate of this bug. ***

Comment 27

[Matteo Settenvini]

This urge to be solved. It appears like a regression to me, since Mozilla 1.2.1
worked right with this. Many sites use "mailto:" by creating a string in
javascript that is passed to the command line to pre-format the email. I feel
this shouldn't be ignored, since the sender as well as the receiver see a mess
in the message.

Still, it's more dangerous a plain-text email full of html commands than a
well-formed html, since the reader mostly ignores the code as well as the bad
layout and he doesn't check the infos he's sending (assuming it's an email
generated by filling in a form). This can result in the sending of unclear or
hidden informations as well as an html comment.

Try to paste this line in the location bar to see the problem:

(Mmmh, sorry for my English...)

Comment 28

[Matteo Settenvini]

mailto:[e-mail]?Content-type=text/html&Subject=Try%20this&Body=<html><b>This
should be bold</b>, instead <i>this should be in italics</i>.</html>

Comment 29

[Ninoschka Baca]

Marking nsbeta1 since this is a regression and should work.

Comment 30

[Samir Gehani]

Mail triage team: nsbeta1+/adt3

Comment 31

[Olivier Vit (just a reporter)]

Still occuring in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b)
Gecko/20030406

Any plan ?
Allowing the user to switch back to HTML mode looks to me as a minimum

Comment 32

[Andrew Schultz]

Olivier Vit: unless you are a driver, you do not have authority to set this as
blocking 1.4b (+).  You can only request it (?)

http://www.mozilla.org/roadmap.html#how-you-can-help

Comment 33

[Matteo Settenvini]

As stated in Comment #32, I felt it was right to set to "?" the "blocking 1.4b"
flag. I've done it since this is a clear regression and it can prevent the
accessibility to some sites' services, as said in Comment #18, Comment #19,
Comment #25 and Comment #27. Comment #21 shows how it can be frustrating for the
standard user. I also confirm it was Ok in Mozilla 1.2.1. Comment #24 propose a
possible solution for the problem, although I think it should be asked if it's
ok to keep page in html through a popup confirm window.

Comment 34

[Sean Su]

Attachment: patch v1.0

patch fixes this bug, however, it looks like it might regress bug 159786 and/or
bug 61893.  Still doing more tests...

Comment 35

[(not reading, please use [e-mail] instead)]

that patch doesn't look right.

why aren't we getting the default identity, and determining html or txt compose
from it?

assuming that on pMsgComposeParams, no identity is set.

steal from nsMsgComposeService::OpenWindow() [or better yet, make a method to
avoid copy and paste]

  //Use default identity if no identity has been specified
  nsCOMPtr<nsIMsgIdentity> identity; 
  params->GetIdentity(getter_AddRefs(identity));
  if (!identity)
  {
    GetDefaultIdentity(getter_AddRefs(identity));
    params->SetIdentity(identity);
  }

  MSG_ComposeFormat format;
  params->GetFormat(&format);

  PRBool composeHTML = PR_TRUE;
  rv = DetermineComposeHTML(identity, format, &composeHTML);

but watch out for this scenario:

mozilla suite, mail installed
don't set up mail
go to browser, click on mailto link
(won't have a default identity!)
should get mail compose window, and on top, the account wizard.
but the compose window is open already

so if no default identity, use this pref:  mail.html_compose

Comment 36

[Sean Su]

I think bug 90728 cause this bug.  And fixing this bug might regress that bug.

Trying to get a better grasp at the problem described in bug 90728.

Comment 37

[Jesse Ruderman]

The fix for bug 90728 did two things that I consider orthogonal:

1. Made mailto: links default to text/plain, removed the force-plain-text
parameter, and added an html-body parameter.  (Since this only changes the
default without removing the possibility of including HTML, it has no effect on
security, and I don't know why it was done.)

2. Made HTML bodies supplied by mailto: URLs go through the HTML sanitizer. 
(I'm not familiar with the HTML sanitizer, so I don't know whether this fixes
the hidden-text or the hidden-script versions of the security hole.  And the fix
for bug 159786 might have re-introduced the hole.)

Comment 38

[Sean Su]

Attachment: patch v1.1

Updated patch that fixes this bug and still sanitizes html bodies in the url,
as far as I can tell.  My test cases showes that the sanitize code is still
being done.

mailto: links will now default the current/default mail account's 'Compose
messages in HTML format' pref located in the "Mail & Newsgroups Account
Settings...".

You can only override it to HTML mail composer (not to PlainText) by having
either the 'html-part' or 'html-body' tag in the url, eg:
  mailto:[e-mail]:html-body=This will force the mail compose window to
come up in HTML edit mode.

Test case coming up.

Comment 39

[Sean Su]

Attachment: test case

Comment 40

[Sean Su]

typo.  instead of:
 mailto:[e-mail]:html-body=This...

It should be:
 mailto:[e-mail]?html-body=This...
                       ^

The attached test case is correct though.

Comment 41

[(not reading, please use [e-mail] instead)]

Comment on attachment 122363 [details] [diff] [review]
patch v1.1

1)

+  nsresult GetIdentityAndFormat(nsIMsgComposeParams *aParams, PRBool
*aComposeHtml);

you need to remove that.

2)

+#include "nsIMsgComposeParams.h"

is this necessary, since you added
+#include "nsIMsgComposeParams.idl"
to public/nsISmtpUrl.idl

Comment 42

[Sean Su]

Attachment: patch v1.2

updated patch that addresses sspitzer's comments.  both lines removed.

Comment 43

[Matteo Settenvini]

To keep the patch nearer to standards, could we use a different syntax to
override the compose settings (see Comment #38)?
I purpose the use of "Content-type=text/html" at the command line.

Example given:
         mailto:[e-mail]?Content-type=text/html
instead of:
         mailto:[e-mail]?html-body=This

This will be more clearer and won't be just a Mozilla pref, but exportable to
other browsers too. I'm not sure, but maybe also Outlook use this syntax...
Thank you for the attention, just my 2 cents anyway...

Comment 44

[Jesse Ruderman]

In current versions of Mozilla, the value of html-body is ignored; the presence
of html-body just means that the value of body should be treated as HTML.  The
patch changes html-body so its value matters and overrides the body value.  I
like this change, because it allows better compatibility with clients that do
not support or do not default to HTML message compose.

I disagree with #1 and #3 in the testcase.  I think a mailto: link with a body=
parameter should do the same thing regardless of the user's pref.  Web site
authors who put up mailto: links with body= values are unlikely to think of the
problem of user's prefs interfering with how the body= value is interpreted. 
But I agree with #5 in the testcase.  A mailto: link without a body= (the most
common case) should bring up a message-compose window set to HTML or plain-text
depending on the user's pref.

How about this:
* mailto: links with html-body= always bring up HTML message compose, and any
body= value is ignored.
* mailto: links with only body= always bring up plain-text message compose (to
match Outlook Express 6.00.2800.1123 and to make Mozilla Mail more predictable).
* mailto: links with neither go with the user's pref.

Comment 45

[Matteo Settenvini]

In last comment you said:

* mailto: links with only body= always bring up plain-text message compose

I dunno if it's the better thing to do, however the user should be able to set a
preference about it. Still, it should be possible to switch to HTML mode
whenever wanted.
Personally, I prefer the behaviour of the 1.2.1 Mozilla release, where the
"body" was in html unless otherwise specificated (in prefs or switching manually
to plain text). 
This is useful for sites which use javascript to send a form through a link,
after having assembled it in a formatted email, or either created complex
user-editable tables. Many times a particular formatting is necessary because
the receiver uses a mail filter to label incoming messages. 
If you think that this could violate any security issue, please consider that a
malicious site could always use php to send away private informations, and in a
more subtle and dangerous manner (also the IP number). And no report of the
operation would be given to the end user.
So, trustworthy users will be penalized, and malicious ones could always switch
to php or something similar. 
When I used some services inside an italian site with these preformatted emails,
and I asked for an alternative manner to send them my informations, they said
just "revert to Microsoft Outlook, that will work better". Sad, isn't it? So I
had to cut and copy about 25-30 emails in new messages, reformat them properly
(subject and address) and send them. 
I know it isn't the best way to project a site, but a lot of people use the
mailto: pseudo-protocol in this way.

Comment 46

[Dan Mosedale (:dmosedale, :dmose)]

Are people already depending on html-body?  If not, I like Matteo's suggestion
of using Content-Type instead.  Even if it is in use, we might want to deprecate
it and go with Content-Type instead, since that method is compliant with RFC 2368.

Modulo that, I think I agree with Jesse's proposal in comment 44.  In particular 
mailto:[e-mail]?body=subscribe is a commonly used link, and
I would think that most list processors will barf on that if it's surrounded by
html junk.

Matteo: I'm having a hard time understanding your comment 45.  Are you saying
that Outlook behaves differently than Jesse describes Outlook Express as behaving?

Comment 47

[Dan Mosedale (:dmosedale, :dmose)]

Sean and I just did some testing, and, interestingly, Outlook seems to default
to choosing HTML compose with body=, but send multipart/alternative: one part
text/html and one part plain.  So newer list processors that grok MIME (are
there such things?  are they common?) might do OK with that.

Comment 48

[Matteo Settenvini]

Uh, sorry for my English. However, Outlook Express 5 and others behave treating
new messages as multipart (see above comment).
My last comment focused on the security problem, for this seems to be the most
important thing to consider when setting new messages to compose in html. The
security issue that was discussed is: "could some private informations be sent
through a html comment hidden to the user in html composed messages?"
My point was that html messages through "mailto" are useful to many companies,
and not supporting it would prevent some user to access some sites' services,
also because these companies could use automatic scripts (or email filters) to
catalogue incoming messages. 
It is true that also plain text messages would work with most of these filters,
but the resulting email would be pretty complicated to read. The example I
reported in my previous comment was that of an italian site that asked me to
change email client because otherwise they would ignore my emails.

Let's do an example:

<form action="[e-mail]" name="we">
  <input type="hidden" name="type" value="text/html">
  <input type="text" name="subject">
  <input type="text" name="body">
  <input type="text" name="nickname">
  <input type="password" name="privateinfo">
  <input type="button" value="Send it!"
onClick="writeEmail(document.we.type.value, document.we.subject.value,
document.we.body.value, document.we.privateinfo.value,
document.we.nickname.value);">
</form>

Note that just : "text/plain" and "text/html" should be supported (and also
"multipart/alternative" if you want), but not any other type as "octet/stream"!
Here's the js code that build up the email body (hope there's no error, I'm
writing it "on the fly")

<script language="JavaScript" type="text/javascript">
<!--

function writeEmail($type, $title, $body, $privateinfo, $name) {
	var validate = true;
	if ($title == '' || $body == '' || $name == '') {validate = false};
	
	if (validate) {
		$today = new Date();
		$todaydate = $today.toUTCString();
		re = new Array();
		rewith = new Array();
		re = [
			/%/gi,
			/&/gi, 
			/\n/gi,
			/è/gi,
			/é/gi,
			/ò/gi,
			/à/gi,
			/ù/gi,
			/ì/gi,
			/£/gi,
			/ç/gi,
			/°/gi,
			/§/gi,
			// /</gi,
			// />/gi,
		     ];
		rewith = [
			"%25",
			"%26",
			"\<br\>",
			"e'",
			"e'",
			"o'",
			"a'",
			"u'",
			"i'",
			"pnd",
			"c",
			"<sup>o</sup>",
			"<b>sign</b>",
			// "%3C",
			// "%3E",
			 ];

		for (h = 0; h < 15; ++h) {
			$body = $body.replace(re[h], rewith[h]);
		}

		$send = ('mailto:[e-mail]?');
		$send += ('Content-type=' + $type + '&');
		$send += ('Subject=[' + $title + ']' + &MIME-Version=1.0&charset=iso-8859-1&');
		$send += ('Body=\<html\>\<body\><p style=\"color : #000066\"> On ' +
$todaydate + ', ');
		$send += ($name + ' wrote : \n\<\/p\>\<ul style=\"border-left : black 1px
solid; padding-left : 5px\"\>"' + $body + '"\<\/ul\>\<p style=\"color :
#000066\"\>Sent by : www.domain.com\<\/p\>');

		//watch out the following line ...
                $send += '<!-- Private info: ' + $privateinfo + '-->';

                $send += ('\<\/body\>\<\/html\>');
	        self.location.href = $send;
	} else {
		alert('\tError');
	}
}

// -->
</script>

This is just a poor example. Think about a form where you insert some values and
the resulting email includes a table that has already sums calculated and also 
a graph (with the use of DIVs and CSS, it can be done).

You can just send one email per time with js, and the recipient is shown in
clear. So, what's the security problem? Any information has been inserted
awarely by the user, and it is intended to be sent. 

Confirmation is ALWAYS asked before the sending.

On the other hand, malicious companies have not interest in using the "mailto"
pseudo-protocol to send away messages with hidden informations, since they can
compose mail through the "mail()" PHP function, just to give an example. And
this could contain more private infos that those sent with javascript, as the IP
number. More, user won't have any feedback.

So, there's no reason to block html composing, since good companies will have to
 change their

Hope it's clearer, sorry for the english. Thank you for your patience.

Comment 49

[Matteo Settenvini]

There were a few mistakes in the code above. Created a testcase at
http://www.intelligenzartificiale.it/html/spe_contact.htm

Description is in italian, but you won't have any problem at filling it and
testing. If anyone of you has a previous release of Mozilla (such as 1.2.1), the
old behaviour is shown. In this example, Outlook will attach a file at the email
(because of the form's method). This file can be saved, renamed to .htm and viewed.

Comment 50

[Blu3]

I write a list processor that will handle html in depth in a little while, it
handles simple html now.

Comment 51

[Sean Su]

We're running out of time.  I'm going to fix the problem initially stated in
this bug.  People who want other/enhanced mailto: url support should open new
bug on it.

Comment 52

[Sean Su]

Attachment: patch v1.3

update patch given review with dmose.

Comment 53

[Sean Su]

Attachment: patch v1.4

forgot one minor change.

Comment 54

[Dan Mosedale (:dmosedale, :dmose)]

r=[e-mail] for patch v1.4.  This doesn't address the Content-Type issue
or Jessie's and my semantic issues, but I think it does make things perform as
expected more of the time than they do in currect builds.  Please file a new bug
on the remaining issues from this bug, including one about popping up an error
message if the HTML sanitizing parser fails rather then just dumping HTML gunk
into the plaintext compose window.

Comment 55

[Sean Su]

Comment on attachment 122552 [details] [diff] [review]
patch v1.4

got r=dmose
seeking sr= and a=

Comment 56

[(not reading, please use [e-mail] instead)]

Comment on attachment 122552 [details] [diff] [review]
patch v1.4

sr/a=sspitzer

another spin off bug (low priority) use the "right" identity when the mailto
link is in an email message.

also, just double checking, do we use the "right" identity when you click on an
address in the msg hdr pane?

Comment 57

[Matteo Settenvini]

Can we have the patch improved for 1.4 final? It would be interesting to have
the Content-type request fixed, if possible (See Comment #46).

Comment 58

[Sean Su]

> another spin off bug (low priority) use the "right" identity when the mailto
> link is in an email message.

opened bug 204911.

> also, just double checking, do we use the "right" identity when you click
> on an address in the msg hdr pane?

This works great.

> To keep the patch nearer to standards, could we use a different syntax to
> override the compose settings (see Comment #38)?
> I purpose the use of "Content-type=text/html" at the command line.

opened bug 204914.

patch v1.4 checked in.  closing this bug as fixed.

Comment 59

[Ed Jones]

OK, so this is marked fixed.

Yet my spiffy new 1.4b still pops up with a mail window that does not allow me
to insert a url or mark something in italics.

See comment #21. I still withhold recommendation of Mozilla as a suitable
client. I use it, but this is such an irritating flaw that I won't stake my
recommendations on it.

Comment 60

[Sean Su]

that *just* got checked in, so obviously it won't be in 1.4b cause it's already
released.  This fix should show up in 1.4f though.

Comment 61

[Matthias Versen [:Matti]]

*** Bug 205356 has been marked as a duplicate of this bug. ***

Comment 62

[Joel Nelson (don't send email)]

*** Bug 205746 has been marked as a duplicate of this bug. ***

Comment 63

[esther]

Using trunk build 20030519 on winxp, macosx and linux and the original scenario
this bug is fixed.  Clicking on a mailto link within a browser page will bring
up a compose window in the format selected for the default mail account in
either HTML or plain text. 

Comment 64

[http://tinymailto.com/oliversl]

Comment #58 solved bug #194809

Comment 65

[http://tinymailto.com/oliversl]

on comment #58
>> also, just double checking, do we use the "right" identity when you click
>> on an address in the msg hdr pane?
>This works great.
This is not working in 1.4RC2

When I click on a mailto: link in MailNews in a seconday account, the "right"
identity is not used. Instead, the default Identity is used.
Bug #194809 is still open regarding this issue. It is late for including a patch
for 1.4rc3? Thanks