[Bug 8105] New: DecodeShortURLs fails to follow redirect chains with differing query parameters

[bu...@spamassassin.apache.org]

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8105

            Bug ID: 8105
           Summary: DecodeShortURLs fails to follow redirect chains with
                    differing query parameters
           Product: Spamassassin
           Version: 4.0.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Plugins
          Assignee: dev@spamassassin.apache.org
          Reporter: dilldall@bjork.org
  Target Milestone: Undefined

When DecodeShortURLs encounters a returned location header where only[1] the
query parameters differ, it appears it will not follow it, even if the
source/target domain is defined as a url_shortener. I'm guessing it's doing
some comparing to prevent an infinite loop, but stripping away things like
query string first. Sometimes a good idea, other times not.

Consider this example, pulled from a spam message:

https://rb.gy/qcigz2

As of writing, this returns a location header of:

http://rb.gy/qcigz2?rb.routing.mode=proxy&rb.routing.signature=974538

Same URL, different protocol[1], different (added) query parameters.

If it were to follow this redirect, it would get this location header back:

https://rebrandly.info/stop

Which, in turn, could be used in URL_SHORTENER_DISABLED[2].


[1] I say only even though in this example the protocol also differs. If *only*
the protocol differs, however, it does seem to follow the chain.
Consider this:

http://www.shorturl.at/BLOY9

Which redirects to https before redirecting to target. Assuming www.shorturl.at
is defined as a url_shortener[3], it *will* follow the redirect chain to the
same URL with https[4], and then further.

[2] I guess this is another suggestion for improvement, which could be added,
but I don't wanna file individual reports for all these tiny things.

[3] Which it should be, because even though the shorturl.at service provides
shortened URLs as shorturl.at - which is in the list - it first redirects every
URL to www.shorturl.at (and https) - which isn't. But that's (also?) a
different bug, and I'm already working on a larger list update, pulled from
numerous sources.

[4] Incidentally, this will also trigger short_url_chained (and in turn an
assigned score), which perhaps it shouldn't when redirecting to the same (base)
domain. Might be worthy of another report, I suppose.

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

[Bug 8105] DecodeShortURLs fails to follow redirect chains with differing query parameters

[bu...@spamassassin.apache.org]

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8105

Christer Mjellem Strand <di...@bjork.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dilldall@bjork.org

--- Comment #1 from Christer Mjellem Strand <di...@bjork.org> ---
I'm not sure I can reproduce the original issue in this report anymore - it may
have been related to caching, or something else. I've seen occurrences of it
working in logs since reporting.

I'll leave the report however open, however, as it includes various other minor
tidbits which may be worth addressing.

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