Bug 6596 - Text that looks like URL without a valid TLD is not parsed as a hot link
Summary: Text that looks like URL without a valid TLD is not parsed as a hot link
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Libraries (show other bugs)
Version: 3.3 SVN branch
Hardware: All All
: P2 minor
Target Milestone: 4.0.0
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-23 19:59 UTC by Sidney Markowitz
Modified: 2019-08-03 14:12 UTC (History)
6 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Sidney Markowitz 2011-05-23 19:59:56 UTC
A text string http://NO-TLD is not parsed as a URL by the code that is looking for links as text. We may want to recognize them and append a ".com" to form a URL to pass to deobfuscator and RBL code. This is a new issue extracted from bug 5780 comment 38 through bug 5780 comment 43
Comment 1 Dave Jones 2018-01-28 16:14:08 UTC
Is is a good idea to assume any TLD and append it?  Seems like this could lead to abuse of innocent/good .com domains and FPs.
Comment 2 John Hardin 2018-01-28 23:37:46 UTC
What do MUAs do with that? If major MUAs append .com and "just make it work" for the user, then maybe we should also do that.
Comment 3 Giovanni Bechis 2018-01-29 07:39:41 UTC
Not all the world is .com, why not .cn than ?
I think it is not useful, adding a .com tld to a domain does not necessarily "make it work".
I tried a few MUA and they leave the url as-is (as they could work in local environments).
Comment 4 Kevin A. McGrail 2019-06-17 23:05:47 UTC
I vote -1 on fixing this.  If it's an invalid url and our TLD list is accurate, then not parsing it seems accurate.
Comment 5 Giovanni Bechis 2019-06-18 07:44:57 UTC
IMHO, if we keep our TLD list accurate it makes no sense to fix this it.
-1 for me.
Comment 6 Kevin A. McGrail 2019-06-24 15:10:45 UTC
(In reply to Giovanni Bechis from comment #5)
> IMHO, if we keep our TLD list accurate it makes no sense to fix this it.
> -1 for me.

Agreed.  Closing as won't fix.  bug 7165 is open for this purpose if someone can run it and figure out how to automated it.
Comment 7 Henrik Krohns 2019-08-02 08:13:18 UTC
Umm I'm reopening this, it's clear that while MUA itself might not append .com to the link, latest Thunbirdbird will linkify http://foobar and _Firefox_ changes it to http://www.foobar.com when "foobar" doesn't resolve.

Rewriting 4.0.0 parser right now, so maybe it should be implemented.
Comment 8 Sidney Markowitz 2019-08-02 11:20:42 UTC
(In reply to Henrik Krohns from comment #7)

I agree with re-opening it given that new behaviour in Thunderbird
Comment 9 Henrik Krohns 2019-08-02 14:12:37 UTC
Here is current Firefox fixup code

https://hg.mozilla.org/mozilla-central/file/tip/docshell/base/nsDefaultURIFixup.cpp

Will try to emulate that.. atleast this from quick glance

- only for http://
- not if user/password
- not if port != 80
- not for "localhost"
Comment 10 Kevin A. McGrail 2019-08-02 19:11:07 UTC
I'm also +1 for reopening.
Comment 11 Henrik Krohns 2019-08-03 14:12:37 UTC
Part of this update.

Sending        spamassassin-3.4/UPGRADE
Sending        spamassassin-3.4/lib/Mail/SpamAssassin/DnsResolver.pm
Sending        spamassassin-3.4/lib/Mail/SpamAssassin/PerMsgStatus.pm
Sending        spamassassin-3.4/lib/Mail/SpamAssassin/RegistryBoundaries.pm
Sending        spamassassin-3.4/lib/Mail/SpamAssassin/Util.pm
Sending        spamassassin-3.4/t/uri.t
Sending        spamassassin-3.4/t/uri_text.t
Sending        trunk/UPGRADE
Sending        trunk/lib/Mail/SpamAssassin/DnsResolver.pm
Sending        trunk/lib/Mail/SpamAssassin/PerMsgStatus.pm
Sending        trunk/lib/Mail/SpamAssassin/Plugin/URIDNSBL.pm
Sending        trunk/lib/Mail/SpamAssassin/RegistryBoundaries.pm
Sending        trunk/lib/Mail/SpamAssassin/Util.pm
Sending        trunk/t/uri.t
Sending        trunk/t/uri_text.t
Transmitting file data ...............done
Committing transaction...
Committed revision 1864336.