Closed Bug 99055 Opened 21 years ago Closed 14 years ago

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


(MailNews Core :: Composition, enhancement)

Windows NT
Not set


(Not tracked)



(Reporter: jogi, Assigned: joey.shen)


(Blocks 1 open bug)


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.
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...
QA Contact: sheelar → esther
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.
Closed: 20 years ago
Resolution: --- → WORKSFORME
Accidentally marked WFM, correcting.
Resolution: WORKSFORME → ---
Severity: normal → enhancement
Ever confirmed: true
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.

Closed: 20 years ago20 years ago
Resolution: --- → WONTFIX
to repeat, we can't do this for security reasons.

it's just:  mailto:address

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:

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
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.
Resolution: WONTFIX → ---
If we limit it to command-line only (not trivial) then this should be ok....
Blocks: 202993
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.
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?
Joey loves this function.

Assignee: ducarroz → joey.shen
My pleasure to take this bug.:-)
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

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

  Any suggestions?
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 ?
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. :)
I already do ;-)
Any objecting to resolving this bug WONTFIX, now that 149126 has landed?
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. 
Product: MailNews → Core
(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. 

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.
Closed: 20 years ago14 years ago
Resolution: --- → WONTFIX
Product: Core → MailNews Core
Duplicate of this bug: 478489
You need to log in before you can comment on or make changes to this bug.