Re: Redirectors.pm vs DecodeShortURLs.pm

Bill Cole <[email protected]> Wed, 20 May 2026 18:15:35 -0400
Newsgroups gmane.mail.spam.spamassassin.devel
Message-ID <[email protected]>
On 2026-05-20 at 14:41:04 UTC-0400 (Wed, 20 May 2026 18:41:04 +0000)
Kent Oyer <[email protected]>
is rumored to have said:

> Is the ultimate goal to replace the DecodeShortURLs plugin with the 
> Redirectors plugin? It seems like Redirectors was forked from 
> DecodeShortURLs in 2024 and new features have been added to 
> Redirectors but not much has changed in DecodeShortURLs.

That's very odd. I don't recall that being discussed at all, and I can't 
find any discussion or the commit email creating Redirectors.pm in the 
archives. I had not realized that we were handling these as distinct 
things.

> The problem I'm seeing is that Redirectors runs at priority -15 and 
> DecodeShortURLs runs at priority -10. So a chain like:
> REDIRECTOR -> SHORTENER -> target
> gets fully traversed, but a chain like:
> SHORTENER -> REDIRECTOR -> target
> does not. The only feature I can find in DecodeShortURLs that's not in 
> Redirectors is url_shortener_custom_user_agent. That would be trivial 
> to add and then we could just have one plugin, one cache, shared 
> loop/maxchain counters, and one set of eval rules.
> Currently we have an overlapping set of rules:
> eval:short_url
> eval:short_url_redir
> eval:short_url_200
> eval:short_url_404
> eval:short_url_code
> eval:short_url_chained
> eval:short_url_maxchain
> eval:short_url_loop
> eval:short_url_tests   <-- deprecated
> eval:redir_url
> eval:redir_url_valid    <-- was redir_url_redir before I renamed it
> eval:redir_url_404
> eval:redir_url_code
> eval:redir_url_chained
> eval:redir_url_chained_domain
> eval:redir_url_maxchain
> eval:redir_url_loop
> What are we trying to acheive?

I share your confusion, given the replicated code. I also can't see how 
the logical overlap is conceived to work, since all shorteners are 
redirectors but not all redirectors are shorteners. It seems to me that 
we should only have one tool for turning HTTP(S) URLs in mail into their 
ultimate target URLs and intermediates which may also need to be judged 
by URIBLs and other URL-based rules. Just the existence of 16 
mostly-redundant(?) evals hints at all the edge cases we want to handle 
correctly.

It looks like Giovanni is the person who can answer all of this.

-- 
  Bill Cole
  [email protected] or [email protected]
  (AKA @[email protected] and many *@billmail.scconsult.com 
addresses)
  Please keep discussion mailing list replies *on-list*
  Not Currently Available For Hire