Joerg Sievers Reporter
	Description • 23 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 23 years ago

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...

	Keyser Sose
	Comment 2 • 23 years ago

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.

	Grey Hodge (jX)
	Comment 3 • 23 years ago

Accidentally marked WFM, correcting.

	Jean-Francois Ducarroz
	Comment 4 • 23 years ago

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.

	stephend@netscape.com (gone - use stephen.donner@gmail.com instead)
	Comment 5 • 23 years ago

verified.

	(not reading, please use seth@sspitzer.org instead)
	Comment 6 • 22 years ago

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:sspitzer@netscape.com?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

	Henry Jia
	Comment 7 • 21 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 8 • 21 years ago

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

	Joe Assignee
	Comment 9 • 21 years ago

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.

	(not reading, please use seth@sspitzer.org instead)
	Comment 10 • 21 years ago

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?

	Henry Jia
	Comment 11 • 21 years ago

Joey loves this function.

=>Joey

	Joe Assignee
	Comment 12 • 21 years ago

My pleasure to take this bug.:-)

	Dan Mosedale (:dmosedale, :dmose)
	Comment 13 • 21 years ago

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?

	Oliver Braun
	Comment 14 • 21 years ago

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.

	Joe Assignee
	Comment 15 • 21 years ago

  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:joey.shen@sun.com attach=file1,file2"? 
  
  The Onload method in MsgComposeCommands.js could take the response to parse
the options passed following the -compose switch.

  Any suggestions?

	Oliver Braun
	Comment 16 • 21 years ago

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 ?

	Joe Assignee
	Comment 17 • 21 years ago

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. :)

	Oliver Braun
	Comment 18 • 21 years ago

I already do ;-)

	Dan Mosedale (:dmosedale, :dmose)
	Comment 19 • 21 years ago

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

	Joe Assignee
	Comment 20 • 21 years ago

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. 

	Magnus Melin [:mkmelin]
	Comment 21 • 18 years ago

(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. 

	Phil Ringnalda (:philor)
	Comment 22 • 17 years ago

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.