341361 - attachment specification in mailto URL is ignored

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Hans Werner Strube]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; de-AT; rv:1.8.0.1) Gecko/20060202 SeaMonkey/1.0
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; de-AT; rv:1.8.0.1) Gecko/20060202 SeaMonkey/1.0

SM 1.0 Solaris SPARC: Whenever a mailto URL contains an attachment specification, this is ignored. Other specifications, such as cc=, subject= etc., are still honoured in this case. Omitting 'file://' does not help. The same happens with
seamonkey -remote 'openURL(mailto:...)',  but the call
seamonkey -compose 'to=xx@yy,attachment=file:///an/existing/file,...'
works correctly (but, of course, cannot be used with the same profile when the browser is alreay running). The alternative form
seamonkey -remote 'mailto(...)' could not be tested since it does not work at all, see bug #338932, and openURL is required as a workaround.

Reproducible: Always

Steps to Reproduce:
1. In the browser location field, enter an URL like mailto:xx@yy?attachment=file:///an/existing/file&subject=Testit
(possibly more specifications like cc=... etc.)


Actual Results:  
The mail composer window will open with correct address, subject etc., but without showing the attachment.

Expected Results:  
The mail composer window should also show the attachment.

Comment 1

[Hans Werner Strube]

Meanwhile I found out that this behaviour is meant as a feature. In mailnews/compose/src/nsSmtpUrl.cpp, attachments are suppressed for mailto URLs for security reasons. May be necessary but precludes using Mozilla Suite / SeaMonkey (in Unix/Linux) as helper for other applications (e.g., OpenOffice) in order to send documents as attachments. If the browser is already running, any attempt to start the composer will result in popping up the Profile Manager. Isn't there a possibility to detect whether the URL was specified as a command-line parameter and allow attachments in this case?

Comment 2

[Hans Werner Strube]

Oops, just found a solution/workaround allowing attachments with -remote:
seamonkey -remote 'xfeDoCommand(composeMessage,to=xx@yy,attachment=...)'

This should be considered a serious documentation deficiency, since it it nowhere mentioned that xfeDoCommand(composeMessage) can have any more parameters. I found this out by looking at xpfe/components/xremote/src/XRemoteService.cpp .

Comment 3

[Christopher Wright]

This problem also applies to TBird 2.0.0.6rc3 on OSX.  the remote trick doesn't seem to work either, unfortunately.

is it really that much of a security problem?  There isn't a way to force TBird to send an e-mail(that I'm aware of; I could be sorely mistaken), so the user still has to consent.

The above-suggested Command-line detection idea sounds like decent solution.  Thoughts?

Comment 4

[Andrew Schultz]

Yes, the commandline in comment 2 is the "correct" way to handle this.  In fact, the startup script we ship with SM 1.1.x sniffs out existing instances and turns -compose "attachment=something" into -remote 'xfeDoCommand(composeMessage,attachment=something)' for you (bug 122698).  SM trunk has a better XRemote backend that handles -compose seamlessly.

Of course, things are a bit different on Mac.  Mac has no XRemote.  I'd expect Mac trunk to handle -compose as well as *nix trunk.  So it won't work in 1.1, but (at this point).  But then TB2 should have the same basic framework we have on SM trunk, so I'd expect it to work there.

Anyway, if this is a problem on Mac TB2 or trunk, it's a different bug than what was originally reported (so you should file a new bug for that, or search for bugs in thunderbird or OS=Mac).

Not sure what the appropriate resolution here is... resolving WFM

Comment 6

[[e-mail]]

I totally understand you are the people that make Thunderbird and therefore you decide. Anyway while I can understand the security hole implications I understand that instead of commenting the code out the code should be "activable" with a switch in commandline or configuration flag of thunderbird.

If a flag is being used then it would make sense to check the dir against a list of allowed dirs, so security is managed.

Anyway, lots of processes are activated by web as the GUI nowadays. And it makes totally sense to be able to start a process that generates some sort of pdf or report that afterwards must be attached to an email. I understand it can be common for lots of people that server folder containing the report is mounted to the client so, if it is a well known path you can attach the result of the process automagically. That is what I do with kmail.

I'd like to ask you to reconsider it. Activating it by a commandline switch would not affect to security for "normal people" while it becomes a powerfull tool for lots of situations.