[Bug 3311] New: RFE: add support for URIs with opaque redirects such as tinyurl.com

[bu...@bugzilla.spamassassin.org]

http://bugzilla.spamassassin.org/show_bug.cgi?id=3311

           Summary: RFE: add support for URIs with opaque redirects such as
                    tinyurl.com
           Product: Spamassassin
           Version: SVN Trunk (Latest Devel Version)
          Platform: All
               URL: http://www.surbl.org/
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: spamassassin
        AssignedTo: spamassassin-dev@incubator.apache.org
        ReportedBy: jeffc@surbl.org


(Opening a separate bug for this at the suggestion of Justin in Bugid 3261, 
comment #4.  Doing this mainly for completeness; we may not want to actually 
implement this feature due to the network and server resources it would impose, 
at least on high volume servers.  Therefore giving low priority, etc.  Also 
breaking this out as a different case so we can eventually close the mostly 
solved case of open (visible) redirects now handled as described in the other 
bug.)

The request would be: to add support for handling of URIs with opaque 
redirects such as tinyurl.com where the target site is not visible on the 
original URI and must be actually followed somehow to find the final site.
This would be needed in URIDNSBL's urirhsbl, for example.  In principle
multiple opaque redirections could be used in series.

(From Bug 3261, comment #4:)
>>> tinyurl will have no problem shutting down spam URLs I should think
>>I'm not so sure about that.
>
>Well, in that case we'll have a problem ;)  We'd have to expand the
>URI lookup to support including the path part for certain domains.
>(I'd suggest another bug to track that.)

(And comment #17:)
>2. redirects from sites like tinyurl, where the URL is registered in advance nd
>a shorter keyword is used to refer to it, is not fixed though.
>
>However, I'm not sure we want to hit the redirector from our code, because t'll
>slow down scanning to perform a HTTP operation... thoughts?

Other comments also suggested this might be an RFE to *not* implement.  ;-)



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.