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

RESOLVED WONTFIX

Status

()

Core
Networking
RESOLVED WONTFIX
18 years ago
3 years ago

People

(Reporter: neil@parkwaycc.co.uk, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

18 years ago
I don't understand this bugreport. Is this "SMTP:" prefix documented somewhere?
(Reporter)

Comment 2

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

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

Comment 4

14 years ago
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.
Product: Browser → Seamonkey
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 ***
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 6

14 years ago
No, this bug is about linkifying email addresses in messages replied to or
forwarded by Outlook that therefore contain spurious SMTP: prefixes in them.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 7

14 years ago
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:foo@example.com>. 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.
(Reporter)

Comment 8

14 years ago
This is the sort of stuff I get, I think it's from Outlook 97:
-----Original Message-----
From:   Neil [SMTP:neil@parkwaycc.co.uk]

Comment 9

14 years ago
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).

Updated

14 years ago
Summary: Message containing address with SMTP: prefix generates strange link → [mozTXTToHTMLConv] Message containing address with SMTP: prefix generates strange link

Comment 10

14 years ago
I meant "assuming that's an syntactically *invalid* mailto: URL that is being
created/passed."
(Reporter)

Comment 11

14 years ago
Ben, thanks for looking into this.

Are you saying that if mailto:smtp:neil@parkwaycc.co.uk was flagged as an
illegal URL then the converter would try again with mailto:neil@parkwaycc.co.uk
or would it skip it entirely?

Comment 12

14 years ago
It probably would, and *should*, skip entirely. Compare jabber URLs.
(In reply to comment #12)
Neil, please note that "smtp:neil@parkwaycc.co.uk;" (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.

Assignee: scottputterman → mail
Status: REOPENED → NEW
Priority: P3 → --
QA Contact: esther

Comment 14

9 years ago
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
Status: NEW → UNCONFIRMED

Comment 15

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

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

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

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

8 years ago
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
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago8 years ago
Resolution: --- → EXPIRED

Comment 20

7 years ago
I'm even seeing this with current Linux trunk.
Assignee: mail → nobody
Status: RESOLVED → REOPENED
Component: MailNews: Message Display → Networking
Ever confirmed: true
OS: Windows 95 → All
Product: SeaMonkey → Core
QA Contact: networking
Hardware: x86 → All
Resolution: EXPIRED → ---

Updated

7 years ago
Status: REOPENED → NEW
Status: NEW → RESOLVED
Last Resolved: 8 years ago3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.