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