99055 - RFE: add parameter to RFC2368 to be able to handle attachments through "mailto:"-functionality

Status: RESOLVED WONTFIX

(MailNews Core :: Composition, enhancement)

Description

[Joerg Sievers]

IMHO it would be a nice feature to use an additional parameter e.g. 'attach=' to
add an attachment in the mailto: functionality. 
The result would be the same like 

mozilla.exe -compose "attach=file://c:/filename.ext"

now does but it would be possible for other mail apps/browsers to use those
functionality while composing new mails/docs.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This seems like a bad security risk.... especially once mailto: form actions are
enabled.  People can not notice that their files are being attached
automatically to outgoing mails...

Comment 2

[Keyser Sose]

Marking these all WORKSFORME sorry about lack of response but were very
overloaded here. Only reopen the bug if you can reproduce with the following steps:

1) Download the latest nightly (or 0.9.6 which should be out RSN)
2) Create a new profile
3) test the bug again

If it still occurs go ahead and reopen the bug. Again sorry about no response
were quite overloaded here and understaffed.

Comment 3

[Grey Hodge (jX)]

Accidentally marked WFM, correcting.

Comment 4

[Jean-Francois Ducarroz]

we have removed this functionality for security reason. Also, why would you let
a mailto url attach a file! You cannot setup a mailto url with an file path that
will work for every users! Typically, you will never be able to fetch
"file://c:/filename.ext" on a Mac user.

Comment 5

[[e-mail] (gone - use [e-mail] instead)]

verified.

Comment 6

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

to repeat, we can't do this for security reasons.


from http://www.w3.org/Addressing/rfc1738.txt
it's just:  mailto:address

from http://ftp.ics.uci.edu/pub/ietf/uri/rfc2368.txt
it's:  mailto:address?to=xxx&cc=xyz

bascially, any header can be expressed on the mailto query string.

But not attachments.  

One concern we've had is people doing this:
mailto:[e-mail]?attach=cookies.txt

So when you click on it and send me, you might not see that you are attaching 
something accidentally.

I've added a comment to nsMsgComposeService::OpenComposeWindowWithURI() so that 
someone doesn't add this functionality accidentally

Comment 7

[Henry Jia]

How about just making the command line work and still forbidding other usages?
This is a good feature for integrating with other applications. For example, a
lot of applications have a function 'Send by mail...'. If we can make this
happen, we can make other applications use mozilla as the backend.

Reopen the bug for more discussion. If we still think it's 'WONTFIX', just close
it again.

Comment 8

[Boris Zbarsky [:bzbarsky]]

If we limit it to command-line only (not trivial) then this should be ok....

Comment 9

[Joe]

Yes, it would be a nice feature to add attachments by mailto commandline. for
example it could be used by office-like software to implement "send document as
email" funtionality.

Comment 10

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

If we limit it to the comand line (mozilla -compose, I think) then I'm ok.

but it has to be blocked from the mailto urls.

henry / joey, you want to take this bug?

Comment 11

[Henry Jia]

Joey loves this function.

=>Joey

Comment 12

[Joe]

My pleasure to take this bug.:-)

Comment 13

[Dan Mosedale (:dmosedale, :dmose)]

bz and I spent some time talking this over on #mozilla, and we came to the
conclusion that a separate command-line switch is less risky.  Maybe

mozilla -compose -attachment=file1 -attachment=file2

etc?

Comment 14

[Oliver Braun]

Hi Dan,

just to be sure I got it right: the difference of your proposal and the already
working mozilla.exe -compose "attach=file://c:/filename.ext" is basically that 

1) it becomes a supported command line option :)
2) it becomes possible to attach more than one file

Correct ?

Actually I think whatever you come with with, the most inportant thing is that
the command line switch works with an already running mozilla via
-remote "xfeDoCommand (composeMessage)" or - even better - regardless if an
instance of mozilla is already running or not.

Just my 2 cents.

Comment 15

[Joe]

  According to nsCommandLineService::initialize(), nsCommandLineService only
support one value for each switch with frefix '-'. For example, if we launch
"mozilla.exe -compose arg1 arg2", nsComposeService would only accept arg1 as
window.arguments[0], while arg2 would be lost.     

  So, in order to keep nsCommandLineService unchanged, how about we achieve the
feature like this: 
mozilla.exe -compose "mailto:[e-mail] attach=file1,file2"? 
  
  The Onload method in MsgComposeCommands.js could take the response to parse
the options passed following the -compose switch.

  Any suggestions?

Comment 16

[Oliver Braun]

I am mostly concerned about the code in
xpfe/components/xremote/src/XRemoteService.cpp, which comes into the game when a
browser instance is already running:

  // open a new compose window
  else if (aArgument.EqualsIgnoreCase("composemessage")) {
    nsCString tempString("mailto:");
    rv = OpenURL(tempString, nsnull, PR_FALSE);
  }

This mapps a mozilla -remote -xfeDoCommand(composeMessage) to a blank mailto url
that still does not know anything about attachments.

Any plans to change this code as well ?

Comment 17

[Joe]

Oliver, I submitted a patch for bug#149126 to make -remote xfeDoCommand accept 
more arguments. 
the patch has been sr + and are being waited to be reviewed. We're trying 
to add the feature into Moz 1.4, if the review finished in time (blizzard seems
too busy....).
With that patch, you can add attachments by -remote in the commandline as:

$mozilla -remote "xfeDoCommand(composemessage attachment=fileURL)"

I think you would love the feature. :)

Comment 18

[Oliver Braun]

I already do ;-)

Comment 19

[Dan Mosedale (:dmosedale, :dmose)]

Any objecting to resolving this bug WONTFIX, now that 149126 has landed?

Comment 20

[Joe]

Since above discussion came to the conclusion that we don't want to touch the
mailto URL, currently the attachments could be only added through -compose
commandline. for example:
$mozilla -compose "attachment='fileURL1,fileURL2'"

and with the patch for 149126 into the trunk, this feature could be supported by
xremote mode. for example
$mozilla -remote "xfeDoCommand(composeMessage,attachment='fileURL1,fileURL2')"

But there is one more thing I'm concerning. When I look over the Mozilla source
code, I noticed some comments mentioned, that -compose switch would be removed,
and take mailto URL handler instead, although such comments seem to be exsiting
  several year ago. I'm not sure whether this removal would take place in the 
future. If the answer is yes, I'm afraid we still need to come back to the
mailto URL. 

Comment 21

[Magnus Melin [:mkmelin]]

(In reply to comment #19)
> Any objecting to resolving this bug WONTFIX, now that 149126 has landed?

Nope. Since you can do it using -remote nowadays I think there isn't much left to do here. 

Comment 22

[Phil Ringnalda (:philor)]

Particularly since we have comments in the code saying "absolutely positively never ever allow attachments in mailto: URIs, see #99055," which is rather odd when it's an open bug to do just that :)

Bug numbers are cheap, if at some point in the future something else has to be done for commandline attachments, a fresh new bug will be a far better thing.