User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:16.0) Gecko/20100101 Firefox/16.0 Build ID: 20121010231231 Steps to reproduce: I'm displaying a text/plain message with text "sftp://something@domain.tld/www" inside. Actual results: The text from above is displayed as mailto: link (mailto:sftp://something@domain.tld/www). Context menu contains options related to email address operations e.g. Add to addressbook. Expected results: The link should not be treated as email address, but URL. Context menu on it should present at least options: Copy link location, Save link as

Confirming on Trunk. Alec is this a regression ?

Moved this to MIME, but I'm not sure it's the right component

I don't know if this is a regression. Just found it recently.

This is being done by the plain text-to-html converter, probably. BenB?

We support *all* URLs that are known to Mozilla and the OS. If sftp://foo is not converted, then it's because you would not be able to click on that link. Solution: Install an application that can handle sftp: URLs. Then it should just work. Not a bug.

I see that you use Linux. In Windows, the URL handler lookup happens via the registry. On Linux, I think it's done via some /etc/ file, see freedesktop.org. You might also be able to set up URL handlers in Thunderbird preferences, somewhere under netwerk.protocol-handler.* .

Ben, the problem is not I can't click the link. The problem is that it is clickable, but as a mailto: link.

In other words. Text "sftp://something@domain.tld/www" becomes <a href="mailto:sftp://something@domain.tld/www">sftp://something@domain.tld/www</a> or sth like that, I don't know Thunderbird text parser/renderer.

This is mostly bug 32442 (netwerk bug), because "/" in email domain part is invalid. I think we should make "/" in username part invalid, too, which would solve this bug. If we want to allow "/" in mailto: in general, we could make these checks in the "freetext" recognizer mode.