Ben Bucksch (:BenB) Reporter
	Description • 25 years ago

Spin-off from bug #19313.

nsMailtoURL (mailnews/compose/src/nsSmtpUrl.cpp) (tnx to Andreas for the link)
doesn't ckeck validity of URLs.

Reproduce:
Send yourself a plain text mail with any mailer containing the string
"<mailto:=(/%)(%=(/%=%>".

Actual result:
The string is falsely recognized as link.

Expected result:
nothing

Additional Comments:
This is *not* a problem of the converter/recognizer. It relies on the URL
implementation for validity checking.

Of course, this bug is not limited to the converter.

	Ben Bucksch (:BenB) Reporter
	Comment 1 • 25 years ago

Andreas attached a patch in bug #19313 for this bug (#32442).

Andreas,
Tnx for giving it a cut. But I think, the mailto parsing routine will break at
more complex mailto URLs. E.g. what, if the subject contains an "@" or the
descriptive part ("phrase") of the address contains a "," (in a
"quoted-string")? Nearly all chars are allowed in an address, if they are
escaped.

I suggest, you first parse the URL following the "mailto:"-URL-spec RFC2368,
e.g. search for "to=", "bcc=" etc., and then parse the address following RFC822.
Especially the latter will be difficult - RFC822 allows more than one escaping
("quoting") technique.

	Ben Bucksch (:BenB) Reporter
	Comment 2 • 25 years ago

> Nearly all chars are allowed in an address, if they are escaped.

Note, that "escaped" for RFC822 may simply mean "included in double quotes" or
"prepended by a "\".

	Andreas Otte
	Comment 3 • 25 years ago

I will take a look into rfc822.

	selmer (gone)
	Comment 4 • 24 years ago

Target M17.

	Ben Bucksch (:BenB) Reporter
	Comment 5 • 24 years ago

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

	scottputterman
	Comment 6 • 24 years ago

moving to future milestone.

	Ben Bucksch (:BenB) Reporter
	Comment 7 • 24 years ago

Adding helpwanted in hope, Andreas Otte will fix this bug. With this bug, out
TXT->HTML looks silly and we also need indirectly need it for GNKSA-compliance.

	Gervase Markham [:gerv]
	Comment 8 • 24 years ago

Andreas: are you still working on this?

Gerv (just passing through...)

	Andreas Otte
	Comment 9 • 24 years ago

No, not at the moment. I still have to much work to do in my real job, I'm not
at home most of the week. I'm hoping to resurface in June ...

	Ben Bucksch (:BenB) Reporter
	Comment 10 • 23 years ago

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

	Max Kanat-Alexander
	Comment 11 • 22 years ago

I noticed that somebody had added mozilla1.0 to this. Well, that's long past. To
be nice, I'll re-nominate it for 1.4b, since it was never approved or denied for
1.0.

Is anybody still working on this bug?

-M

	Ben Bucksch (:BenB) Reporter
	Comment 12 • 21 years ago

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

	Ben Bucksch (:BenB) Reporter
	Comment 13 • 20 years ago

<http://www.oreillynet.com/pub/a/network/excerpt/spcookbook_chap03/index3.html>

"
The function only validates the actual email address and will not accept any
associated data. For example, it will fail to validate "Bob Bobson
<bob@bobson.com>", but it will successfully validate "bob@bobson.com". If the
supplied email address is syntactically valid, spc_email_isvalid( ) will return
1; otherwise, it will return 0.

#include <string.h>

int spc_email_isvalid(const char *address) {
  int        count = 0;
  const char *c, *domain;
  static char *rfc822_specials = "()<>@,;:\\\"[]";

  /* first we validate the name portion (name@domain) */
  for (c = address;  *c;  c++) {
    if (*c == '\"' && (c == address || *(c - 1) == '.' || *(c - 1) == 
        '\"')) {
      while (*++c) {
        if (*c == '\"') break;
        if (*c == '\\' && (*++c == ' ')) continue;
        if (*c <= ' ' || *c >= 127) return 0;
      }
      if (!*c++) return 0;
      if (*c == '@') break;
      if (*c != '.') return 0;
      continue;
    }
    if (*c == '@') break;
    if (*c <= ' ' || *c >= 127) return 0;
    if (strchr(rfc822_specials, *c)) return 0;
  }
  if (c == address || *(c - 1) == '.') return 0;

  /* next we validate the domain portion (name@domain) */
  if (!*(domain = ++c)) return 0;
  do {
    if (*c == '.') {
      if (c == domain || *(c - 1) == '.') return 0;
      count++;
    }
    if (*c <= ' ' || *c >= 127) return 0;
    if (strchr(rfc822_specials, *c)) return 0;
  } while (*++c);

  return (count >= 1);
}
"

	Ben Bucksch (:BenB) Reporter
	Comment 14 • 20 years ago

The above code is under the new BSD license
<http://www.secureprogramming.com/?action=license>.


Note that currently *no* checks at all are made on email addresses in mailto:
URLs. Everything passes.

	David Humphrey (:humph)
	Comment 16 • 17 years ago

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

Ben,
I think I'll take a shot at this, given that bug 378826 isn't the right route. 
However, given that I've gone down the wrong road once already, can you tell me
if the patch in bug 19313 is the right starting point or should I begin with your code example above?

Scott,
Did you make any headway that I should know about before I start?

Dave

	Scott MacGregor
	Comment 17 • 17 years ago

I haven't looked at this in a long time David. Feel free to run with it!

	Ben Bucksch (:BenB) Reporter
	Comment 18 • 17 years ago

David, following Andreas Otto's lead is the right approach here, he wrote most of the relevant URI checking code. The other bug was only vagely related, though, and is very old, too. Maybe Andreas can give advise about the right code place and approach, though? I wouldn't know.
You can ignore the code example that I posted, if you want, it's just something I found on the web.

	Ben Bucksch (:BenB) Reporter
	Comment 19 • 12 years ago

For bug 808955, it would help to make "/" and similar stuff in the username part invalid.
In any case, we need to make checks on the domain part, to not allow "/" there.