https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8101
--- Comment #9 from Christer Mjellem Strand <[email protected]> --- (In reply to Sidney Markowitz from comment #7) > (In reply to Christer Mjellem Strand from comment #6) > >> https://ml-trk.com/ >> aff_c?offer_id=8822&aff_id=37119&url_id=0_15409_15410_15411_15412_15413&aff_s >> ub5=email&source=s002 >> >> Returns a location header of: >> >> /rd.html?go=https%3A%2F%2Fwww.SingleUkrainianBeauty.com%2Findex. >> php%2Fpromote%2Fclick%3Faid%3D2354%26oid%3DCP231375%26qpid_offer_id%3DSUB_235 >> 084TSAEI%26qpid_subid%3D37119%26qpid_clickid%3D45_37119_8822_52c5875f9b6d77a8 >> b48d37630ad127b4%26source_tag%3Ds002 > > If that is not recognized as a redirect to a local page and handled by > looping to process it, then that should be fixed within the scope of this > issue. This was my reasoning too, and why I didn't open a separate issue. In case it turns out to be relevant, I have (fairly aggressive) caching enabled, and the first link hits a cached response, but according to logs doesn't follow the (cached) relative link. This was not a one-off - I've received more spam since my last comment involving ml-trk.com, which follows this same pattern. > However, it is a separate issue that it is not detected as a redirect to the > urldecoded form of the URL that comes after the ?go= > > If I use curl to get the body of the /rd.html?go=... URL, I see it returns a > page with Javascript that does a redirect to the urldecoded specified URL. > The plugin will have no way of recognizing the /rd.html?go= form of the > redirect unless we add it as a special case when handling ml-trk URLs. I've > opened bug 8114 for dealing with that, and will consider if it is worth > doing. Right, I filed bugs for several other cases (see 8109 and 8111), but I didn't file one for urldecode. That would certainly be nice to support too (preferably in a generic fashion), in the spirit of handling all types of obfuscation through redirection, although I would probably put urldecode at the bottom of that list, below the other (presumably more easily supported) methods I've suggested. > However, it is strange that when I run > > curl -I > 'https://ml-trk.com/ > aff_c?offer_id=8822&aff_id=37119&url_id=0_15409_15410_15411_15412_15413&aff_s > ub5=email&source=s002' > > it comes back with a 302 redirect with a location header of the > SingleUkrainianBeauty URL, not what you say the logs showed. > > I'll try running it through SpamAssassin to see if the way the plugin > fetches the URL gets different results than curl -I, or whether the ml-trk > site is changing behavior. As suggested in the last comment, this has every indication of being a case of UA sniffing. Use the default Mozilla UA that the plugin uses, and you'll see what I see: curl -A "Mozilla/5.0 (Windows NT 10.0; Win64 ;x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.67 Safari/537.36)" -I "https://ml-trk.com/aff_c?offer_id=8822&aff_id=37119&url_id=0_15409_15410_15411_15412_15413&aff_sub5=email&source=s002"; This would be covered by bug 8110, which I recently filed. So if you were able to do something like this: url_shortener_ua ml-trk.com "curl/1.23.4" Then that should be a functioning workaround for this particular redirector (and others with similar behavior, such as t.co, as noted in the other bug report). -- You are receiving this mail because: You are the assignee for the bug.
