Re[2]: Redirectors.pm vs DecodeShortURLs.pm
"Kent Oyer" <[email protected]> Fri, 22 May 2026 20:06:50 +0000
| Newsgroups | gmane.mail.spam.spamassassin.devel |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_125_473435295.1779480410 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable If we merge these plugins, we might lose the ability to detect whether a = link is "shortener" or a "redirector". Specifically, __URL_SHORTENER will= not work like it does today. It will either fire for both shorteners AND= redirectors (preferred), or it won't fire at all. In reality, we'd proba= bly have a new __URL_REDIRECTOR rule and __URL_SHORTENER would remain as = an alias for backwards compatibility. =0APersonally I'm fine with this. I= think the line between shortener and redirector is blurry and mostly irr= elevant. They both have legitimate uses and they're both abusable by spam= mers. =0AMy current plan is to make the Redirectors plugin handle url_sho= rtener/url_shortener_get directives instead of changing those directives = to url_redirector/url_redirector_get. That way people can still use the D= ecodeShortURLs plugin while it's being deprecated and we don't have to ma= intain two lists. We could aim to deprecate it in 4.0.3 and remove it in = 4.1.x.=0AIf we really REALLY need to track shorteners separately, I still= suggest merging the plugins but setting a flag on URLs that we consider = "shorteners" so eval rules can differentiate. =0AThanks=0AKent ------=_Part_125_473435295.1779480410 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <!DOCTYPE html><html><head><meta http-equiv=3D"Content-Type" content=3D"t= ext/html; charset=3Dutf-8" /></head><body><div data-crea=3D"font-wrapper"= style=3D"font-family: Tahoma, sans-serif; font-size: 16px; direction: lt= r"><div>If we merge these plugins, we might lose the ability to detect wh= ether a link is "shortener" or a "redirector". Specifically,=C2=A0__URL_S= HORTENER will not work like it does today. It will either fire for both s= horteners AND redirectors (preferred), or it won't fire at all. In realit= y, we'd probably have a new __URL_REDIRECTOR rule and __URL_SHORTENER wou= ld remain as an alias for backwards compatibility.=C2=A0</div><div><br></= div><div>Personally I'm fine with this. I think the line between shortene= r and redirector is blurry and mostly irrelevant. They both have legitima= te uses and they're both abusable by spammers.=C2=A0</div><div><br></div>= <div>My current plan is to make the Redirectors plugin handle url_shorten= er/url_shortener_get directives instead of changing those directives to u= rl_redirector/url_redirector_get. That way people can still use the Decod= eShortURLs plugin while it's being deprecated and we don't have to mainta= in two lists. We could aim to deprecate it in 4.0.3 and remove it in 4.1.= x.</div><div><br></div><div>If we really REALLY need to track shorteners = separately, I still suggest merging the plugins but setting a flag on URL= s that we consider "shorteners" so eval rules can differentiate.=C2=A0</d= iv><div><br></div><div>Thanks</div><div>Kent</div><div><br></div><div><br= ></div></div></body></html> ------=_Part_125_473435295.1779480410--