53186 - [mozTXTToHTMLConv] Message containing address with SMTP: prefix generates strange link

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[[e-mail]]

While I can appreciate that text with an SMTP: prefix should have been given a
special effect, what I actually saw was not what I was expecting.

I clicked on some text [SMTP:user@domain] in a message and this opened a new
message with the To: address given as SMTP:user@domain

However I expected one or other of the following:

1. A new message with the To: address given as user@domain
2. A new address book card.

Comment 1

[Håkan Waara]

I don't understand this bugreport. Is this "SMTP:" prefix documented somewhere?

Comment 2

[[e-mail]]

Possibly not but in that case the SMTP: shouldn't have been linked.

Obviously I can't block messages just because they contain the SMTP: prefix!

Comment 3

[Thomas]

I agree with comment #1: I don't understand this bugreport

Comment 4

[Luc Rooijakkers]

The SMTP: prefix comes from MAPI (Windows Messaging API) and is required when 
passing RFC822 addresses there; see also 
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/mapi/html/_mapi1book_mapirecipdesc_simple_mapi_.asp

I'm decidedly not an expert on Mozilla, but it would appear to become confused 
somewhere along the line.

See also bugs 221673 and 243177.

Comment 5

[WADA:World Anti-bad-Duping Agency]

Enhancement of MAPI ResolveName is beeing processed by Bug 244222.
Close as DUP of Bug 244222.  

*** This bug has been marked as a duplicate of 244222 ***

Comment 6

[[e-mail]]

No, this bug is about linkifying email addresses in messages replied to or
forwarded by Outlook that therefore contain spurious SMTP: prefixes in them.

Comment 7

[Ben Bucksch (:BenB)]

First, I don't know an smtp: URL and it's likely malformed message, so blame
sender. I wouldn't expect Mozilla to do anything meaningful with it.

THe behaviour of the linkyfier depends on if we have a hander for smtp installed
and the URL is thus recognized as SMTP url by Necko. In that case, the link
target would have an smtp URL scheme, and clicking it would pass the URL to that
handler, and the linkyfier would work as designed. That would probably be WONTFIX.

But I guess you get a mailto: URL ala <mailto:smtp:[e-mail]>. That's the
fault of the mailto URL handler which is brain-dead (basically a null-op,
accepting any garbage as URL). That would be a dup of bug 32442.

Comment 8

[[e-mail]]

This is the sort of stuff I get, I think it's from Outlook 97:
-----Original Message-----
From:   Neil [SMTP:[e-mail]]

Comment 9

[Ben Bucksch (:BenB)]

OK, I get a mailto: link for that. This is the "abbreviated" mode of the recognizer.
I'd blame the mailto: URL handler (i.e. dup of bug 32442), assuming that's an
snytactically mailto: URL is created/passed.
Otherwise I'd need to special-case the recognizer to not allow colons in the
username of email addresses (= abbreviated mailto: URLs for the recongizer).

Comment 10

[Ben Bucksch (:BenB)]

I meant "assuming that's an syntactically *invalid* mailto: URL that is being
created/passed."

Comment 11

[[e-mail]]

Ben, thanks for looking into this.

Are you saying that if mailto:smtp:[e-mail] was flagged as an
illegal URL then the converter would try again with mailto:[e-mail]
or would it skip it entirely?

Comment 12

[Ben Bucksch (:BenB)]

It probably would, and *should*, skip entirely. Compare jabber URLs.

Comment 13

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #12)
Neil, please note that "smtp:[e-mail];" (last ";" is aded) becomes
valid mail address format, although I don't know whether this format is valid or
not as mail address part in "mailto:" schema URI.
See Bug 276057 Comment #2 for rough summary of RFC2822's mail address format in
mail header.

Comment 14

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 15

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 16

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 19

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420

Comment 20

[Karsten Düsterloh]

I'm even seeing this with current Linux trunk.