Reported by Jeff Ducarroz (ducarroz@netscape.com) Build: Mac May 25 Semonkey build (1999052516) installed on PPC 9600/300 OS 8.5.1 Linux May 25 Seamonkey build (1999052516) installed on Compaq P200 RedHat 5.2 Win32 May 25 Seamonkey build (1999052517) installed on Gateway P200 win98 Problem: In Return Receipt mail message, Seamonkey doesn't not identity the correct email address and make it into a url. It suppose to make just the email address as a clickable URL. It selects a string like "rfc822;3qatest05@netscape.com" as the URL instead of "3qatest05@netscape.com" Steps to reproduce problem: 0) Under Communicator: set your Return Receipt pref to ask receipent for a MDN receipt. 1) Start a new mail message 2) Address message to yourself, add a subject, and a short message 3) Under the option pane, check the option to request for a return receipt 4) Send message 5) Receive message 6) Copy your Inbox and Inbox.snm file to your Seamonkey mail test folder (I was using POP in my tests) 7) Start Seamonkey 8) Open Messenger from the Task menu 9) Double click on the mail server name/icon 10) Select the Inbox 11) Select the Return Receipt that your received 12) Read through the message, you should notice one of the URL listed may have "rfc822;" made part of the email url. Example:"rfc822;3qatest05@netscape.com"

I realize that there will be things that break this new linking code, but its sort of like the fact that we have the same problem today. I can put this text into a message - http://www.x which is invalid, but it is turned into a link. 5.0 is more aggressive than 4.x, but I know cases where it might break down. The best thing we can do is keep this bug filed for a later Milestone and add cases that we notice along the way. Then I can see if there is anything I can do down the road. - rhp

Just marking bugs on the very back burner until M12. - rhp

See my 05/26/99 comment. Basically, I was keeping this open to keep track of cases that may break stuff...but I can break 4.x a lot more than 5.x :-) - rhp

Just a tracker for fine tuning. - rhp

Since Ben is actively rewriting this class, I am marking this bug as a duplicate. - rhp *** This bug has been marked as a duplicate of 19251 ***

The problem currently persists with my new code. ";" is a completely valid char in a generic URI. My function leaves it up to the Necko ProtocolHandler to decide, if the guessed URL is valid. Actually, it's a dup of bug #19313. Changing resolution.

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

Verified as duplicate again. :)