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



MailNews Core
17 years ago
6 years ago


(Reporter: Joerg Sievers, Assigned: Joe)


(Blocks: 1 bug)

Windows NT

Firefox Tracking Flags

(Not tracked)




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


17 years ago
QA Contact: sheelar → esther

Comment 2

17 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.
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 3

17 years ago
Accidentally marked WFM, correcting.
Resolution: WORKSFORME → ---


17 years ago
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.

Last Resolved: 17 years ago17 years ago
Resolution: --- → WONTFIX
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:

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

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


15 years ago
Blocks: 202993

Comment 9

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

15 years ago
Joey loves this function.

Assignee: ducarroz → joey.shen

Comment 12

15 years ago
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


Comment 14

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

Comment 15

15 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?

Comment 16

15 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 ?

Comment 17

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

Comment 18

15 years ago
I already do ;-)
Any objecting to resolving this bug WONTFIX, now that 149126 has landed?

Comment 20

15 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. 
Product: MailNews → Core

Comment 21

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

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.
Last Resolved: 17 years ago11 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.