258653 - Allow mailto: links with multiple addresses delimited by (illegal) semicolons (;)

Status: RESOLVED FIXED

(MailNews Core :: Backend, defect)

Description

[Richard Noboru Kekahuna]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3

Using spamcop.com to report spammers, their mailto: line separates multiple
recipients using semicolons.

When I decide to install Thunderbird and try it out as a new email client,
clicking on those mailto:s results in extraneous quotation marks inside the To:
field of the new email composition window.

Additionally, the email will not send out when multiple recipients are separated
by semicolons. (Even after I remove the quotation mark) It results in an alert
of An error occurred while sending mail. The mail server responded: Bad address
syntax. Please verify your email address is correct in your Mail preferences and
try again.

Mail preferences are correct, it sends out email when to: has a single address,
and also when I separate address out into multiple To: fields, one address each
line. It's just unhappy when I try to have multiple recipients on one To: field.


Reproducible: Always
Steps to Reproduce:
1. mailto: with multiple addresses separated by semicolons, such as:
mailto:[e-mail];[e-mail];[e-mail];[e-mail];[e-mail];[e-mail]?subject=[SPAM%20REPORT]%20&body=<---%20PASTE%20SPAM%20HERE
2. try and send email (notice extra quotation mark in the To: field also betwen
postmaster and @hanaro) 
3. try and send email after erasing extra quotation mark

Actual Results:  
Gives an alert email after contacting SMTP server and says it can't send email
due to bad address syntax.

Expected Results:  
send email

Using latest build of Thunderbird 0.8 090804 build, also didn't work in
Thunderbird 0.7.3

Comment 1

[Mike Cowperthwaite]

The semicolons, as used, are technically illegal; that mailto link should be 
using commas to separate the addresses.  

However, if you copy that semicolon-delimited list into the To: field, Mozilla 
will reconfigure the address list into a comma-delimited list before sending, so 
it would be nice if the same could be done when the semicolon list is part of a 
mailto: link.

The quotation mark thing is very odd.  If you leave the quotation mark in and 
try to send, the actual header included in the message is:
  To:  ""
If you remove it from the list, the final header is:
  To:  "         [only one quote mark]


I've seen another instance of quote-marks being inserted unexpectedly when a 
("legal") semicolon was in the address -- see bug 239821 comment 1 -- but in 
that case the quote was inserted on send, after copying a full group email 
address into the To: field.  Setting up a mailto: link with a correctly-formed 
group address (per <http://rfc.net/rfc2822.html#sA.1.3.>) results an incorrect 
parsing of the address; but that's a different problem.

Comment 2

[Richard Noboru Kekahuna]

Microsoft has helpfully encouraged the use of unapproved semicolons in mailtos:

http://msdn.microsoft.com/library/default.asp?
url=/workshop/networking/predefined/mailto.asp

"Syntax

mailto:sAddress[sHeaders]
Tokens

sAddress
One or more valid e-mail addresses separated by a semicolon. You must use 
Internet-safe characters. Use %20 for the space character."

And of course many other people jumped on the usage of semicolons to delineate 
multiple email addresses with. (Noticed other companies using semicolons to 
separate addresses as well.)

Comment 3

[Mike Cowperthwaite]

*** Bug 278745 has been marked as a duplicate of this bug. ***

Comment 4

[Andy Shellam]

(In reply to comment #3)
> *** Bug 278745 has been marked as a duplicate of this bug. ***

Sorry but I cannot control how OTHER PROGRAMS create the links.

The other program (Time and Chaos 6) uses semi-colons to separate addresses, and
I cannot change this.

What I posted (in my original bug, #278745) was only an example.  Outlook
Express, and Outlook both verify these addresses perfectly fine (despite
Microsoft damming the use of the semicolon), why can't Thunderbird?

Comment 5

[Mike Cowperthwaite]

*** Bug 257705 has been marked as a duplicate of this bug. ***

Comment 6

[Mike Cowperthwaite]

(In reply to comment #1)
> if you copy that semicolon-delimited list into the To: field, Mozilla 
> will reconfigure the address list into a comma-delimited list before sending

Hmm.  This is not true in current builds, and I don't know if it was true at the 
time I made that comment.  (It *was* true at one point -- xref what I posted in 
2003 at bug 210521 comment 2.)  Pasting the semicolon-separated list of 
addresses results in the same sorts of unhelpful errors as seen at bug 242693 
and bug 254000.

This bug may be a subset of 242693, depending on whether the extra intelligence 
for parsing semicolons is limited to the URL handling or actually built in to 
the compose window.  I do think this case should be handled, because such URLs 
exist "in the wild" and it's not reasonable to just throw up our hands and force 
the user to tweak the addressing.


(In reply to comment #4)
> Sorry but I cannot control how OTHER PROGRAMS create the links.

You can file bug reports against those other programs, perhaps not as easily as 
you can with Mozilla.  In fact, I encourage you to do so.

Comment 7

[Mike Cowperthwaite]

*** Bug 305115 has been marked as a duplicate of this bug. ***

Comment 8

[mics01]

*** Bug 354051 has been marked as a duplicate of this bug. ***

Comment 11

[emorris]

In the current release of Thunderbird, having semicolons works fine, but, four years (!) on, we still get the problem with extra double quotes...

Comment 14

[Wayne Mery (:wsmwk)]

have we accepted this as a bug?
if not, should be ENH

Comment 15

[Nikolay Shopik]

If that illegal should be treated like ENH, we don't brake anything by not supporting that.

Comment 16

[Robert Sander]

(In reply to comment #15)
> If that illegal should be treated like ENH, we don't brake anything by not
> supporting that.

Thunderbird brakes expectations of ordinary users who just want to click on a mailto link.

Comment 17

[Karsten Düsterloh]

JFTR:
RfC 2368 says:
    mailtoURL  =  "mailto:" [ to ] [ headers ]
where "[ to ]" nowadays means "mailbox-list" from RfC 5322, so semicolons are illegal here. I'm not sure that violating an RfC would be an enhancement...

(In reply to comment #16)
> Thunderbird brakes expectations of ordinary users who just want to click on a
> mailto link.

You can expect something to work only if it _should_ work that way. 
Interpreting random crap doesn't really help.

Comment 18

[Robert Sander]

(In reply to comment #17)

> You can expect something to work only if it _should_ work that way. 
> Interpreting random **** doesn't really help.

I do know that semikolons are not allowed by RFC, but Thunderbird does not generate the mailto: URL, it just has to interpret the input. And what Thunderbird does is then try to send an email with an empty To: and an empty recipient that never gets delivered. Doesn't this also violate an RFC (the empty To:)?

Comment 19

[Karsten Düsterloh]

(In reply to comment #18)
> what Thunderbird does is then try to send an email with an empty To: and
> an empty recipient that never gets delivered.

Wrong.
No mail gets sent unless you specifically say so.
No mail is tried to be sent if you don't specify a recipient.

> Doesn't this also violate an RFC (the empty To:)?

No.

Comment 20

[Bryan Clark (DevTools PM) [:clarkbw]]

I don't feel like a strict standards stance on not allowing semicolons here is helping our user base.  More likely it makes our users believe that Thunderbird is broken.  I'd like to look into making this happen.  Perhaps there we can make web sites that generate this more aware of how it's wrong at the same time.  Though I'm not saying we make the user aware of this as it's more often not their choice.

Comment 21

[Wayne Mery (:wsmwk)]

I too think we should be slightly left of center on this issue, leaning toward http://en.wikipedia.org/wiki/Robustness_principle

Comment 22

[Karsten Düsterloh]

> http://en.wikipedia.org/wiki/Robustness_principle

Sure, I fully agree with that.
But (there always is one!) making too many pseudo-fixes on our end to fix others' bugs will deteriorate the application of standards.

The question is how common that mistake is. If it's a single library etc., it should be fixed there.

At the moment, I don't see any far-spread misuse that'd require us to act here.

Comment 24

[Jae-Seong Lee-Russo]

Fixed by Bug 242693.