For SURBLs we're probably not going to blacklist the U.S. Congress, Google, Dell or Microsoft, so a better solution to their redirectors may be for you to make a good faith effort to contact them and let them know about the issue. Talking about the problem on SPAM-L probably won't do much, other than teaching spammers new things they can abuse, which probably doesn't help fight spam very much.
By the way, being able to redirect to the SURBL website does not prove that a redirector is open, only that it can redirect to the SURBL website. A better test would be to see if it will redirect to a major spammer's site, for example any that are listed in multiple SURBLs.
In case anyone new doesn't already know, here's a letter that may be useful for contacting operators of redirectors and educating them about the problem, and proposing a solution:
http://www.surbl.org/redirect.html
Please feel free to forward a copy or link to it when you contact the redirectors. And don't be shy about contacting them. Anyone who finds a redirector can help out by doing that.
Cheers,
Jeff C. -- "If it appears in hams, then don't list it."
On Friday, April 15, 2005, 6:33:51 AM, Jeff Chan wrote:
For SURBLs we're probably not going to blacklist the U.S. Congress, Google, Dell or Microsoft, so a better solution to their redirectors may be for you to make a good faith effort to contact them and let them know about the issue.
BTW, I mean you plural, i.e. everyone reading this or finding redirectors.
Jeff C. -- "If it appears in hams, then don't list it."
Hi Jeff, At 06:33 15-04-2005, Jeff Chan wrote:
By the way, being able to redirect to the SURBL website does not prove that a redirector is open, only that it can redirect to the SURBL website. A better test would be to see if it will redirect to a major spammer's site, for example any that are listed in multiple SURBLs.
That will give spammers a list of redirectors to use without them having to read these mailing lists. :)
Why are open redirectors being abused? The simple answer is because they are open. The detailed answer is because some antispam filters perform URI checks to block messages. Is it be possible to detect which URIs are redirectors and identify the target URIs instead of going on an open redirect chase?
Regards, -sm
On Saturday, April 16, 2005, 1:39:02 PM, SM wrote:
Why are open redirectors being abused? The simple answer is because they are open. The detailed answer is because some antispam filters perform URI checks to block messages. Is it be possible to detect which URIs are redirectors and identify the target URIs instead of going on an open redirect chase?
Yes, urirhssub in SpamAssassin 3 will check every visible URI, even if it's mentioned within a redirector:
http://some.redirector.com/blah/blah/http://some.othersite.com/
Both redirector.com and othersite.com above would get checked, and including some variations on those. But http://tinyurl.com/blah won't get the redirected-to site checked since it's invisible in the original message.
SpamCopURI in SpamAssassin 2.64 will check the redirected-to sites of certain known redirector sites such as:
open_redirect_list_spamcop_uri snurl.com *.snurl.com open_redirect_list_spamcop_uri snipurl.com *.snipurl.com open_redirect_list_spamcop_uri tinyclick.com *.tinyclick.com open_redirect_list_spamcop_uri babyurl.com *.babyurl.com open_redirect_list_spamcop_uri lin.kz *.lin.kz open_redirect_list_spamcop_uri *.v3.net open_redirect_list_spamcop_uri shorl.com *.shorl.com open_redirect_list_spamcop_uri tinyurl.com *.tinyurl.com open_redirect_list_spamcop_uri xurl.us
In addition, if the following conf is uncommented, it will ask the redirection server to tell it the site being redirected to and will then check that site:
# open redirect resolution off by default # spamcop_uri_resolve_open_redirects 1
Perhaps the SpamAssassin and SpamCopURI authors can provide more detailed info, corrections, etc. on the above, but the quick answer is that some provisions for checking redirected-to sites is already in place.
Jeff C. -- "If it appears in hams, then don't list it."
Jeff Chan wrote:
Yes, urirhssub in SpamAssassin 3 will check every visible URI, even if it's mentioned within a redirector:
http://some.redirector.com/blah/blah/http://some.othersite.com/
Both redirector.com and othersite.com above would get checked, and including some variations on those. But http://tinyurl.com/blah won't get the redirected-to site checked since it's invisible in the original message.
Perhaps the SpamAssassin and SpamCopURI authors can provide more detailed info, corrections, etc. on the above, but the quick answer is that some provisions for checking redirected-to sites is already in place.
SpamAssassin is currently limited to identifying redirectors that require 'http(s)' to be in the URI. So it won't detect domains redirected to by the zdnet redirector and any other similar ones.
Daryl
On Saturday, April 16, 2005, 11:43:30 PM, Daryl O'Shea wrote:
Jeff Chan wrote:
Yes, urirhssub in SpamAssassin 3 will check every visible URI, even if it's mentioned within a redirector:
http://some.redirector.com/blah/blah/http://some.othersite.com/
Both redirector.com and othersite.com above would get checked, and including some variations on those. But http://tinyurl.com/blah won't get the redirected-to site checked since it's invisible in the original message.
Perhaps the SpamAssassin and SpamCopURI authors can provide more detailed info, corrections, etc. on the above, but the quick answer is that some provisions for checking redirected-to sites is already in place.
SpamAssassin is currently limited to identifying redirectors that require 'http(s)' to be in the URI. So it won't detect domains redirected to by the zdnet redirector and any other similar ones.
Daryl
Right. And obfuscation of the redirected-to "http" seems to be enough to confuse SA 3 into not extracting the second URI. Maybe we should make a Bugzilla ticket about that?
Jeff C. -- "If it appears in hams, then don't list it."
On Sun, Apr 17, 2005 at 12:54:57AM -0700, Jeff Chan wrote:
Right. And obfuscation of the redirected-to "http" seems to be enough to confuse SA 3 into not extracting the second URI. Maybe we should make a Bugzilla ticket about that?
It depends what you mean by "obfuscation".
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jeff Chan writes:
On Saturday, April 16, 2005, 11:43:30 PM, Daryl O'Shea wrote:
Jeff Chan wrote:
Yes, urirhssub in SpamAssassin 3 will check every visible URI, even if it's mentioned within a redirector:
http://some.redirector.com/blah/blah/http://some.othersite.com/
Both redirector.com and othersite.com above would get checked, and including some variations on those. But http://tinyurl.com/blah won't get the redirected-to site checked since it's invisible in the original message.
Perhaps the SpamAssassin and SpamCopURI authors can provide more detailed info, corrections, etc. on the above, but the quick answer is that some provisions for checking redirected-to sites is already in place.
SpamAssassin is currently limited to identifying redirectors that require 'http(s)' to be in the URI. So it won't detect domains redirected to by the zdnet redirector and any other similar ones.
Daryl
Right. And obfuscation of the redirected-to "http" seems to be enough to confuse SA 3 into not extracting the second URI. Maybe we should make a Bugzilla ticket about that?
if you find one that SpamAssassin 3.1.0 doesn't decode correctly, sure ;) I thought we had those nailed.
- --j.
On Sunday, April 17, 2005, 10:37:38 PM, Justin Mason wrote:
Jeff Chan writes:
Right. And obfuscation of the redirected-to "http" seems to be enough to confuse SA 3 into not extracting the second URI. Maybe we should make a Bugzilla ticket about that?
if you find one that SpamAssassin 3.1.0 doesn't decode correctly, sure ;) I thought we had those nailed.
TBH, I don't know about 3.1, but here's one that 3.0 does not parse correctly. Perhaps someone can test it in 3.1:
<DIV align=left><FONT face=Verdana size=3><A href="http://r.lycos.com/r/kg_xnsdaz_dqcuewqk/http://wxmnuiuskn.net&xkvo3rhsp6mbz6nky9.coh uneh cnhk.com/">Cl9ick her6e, - no prescr1iption requir7ed!
Note the URI split over three lines and has a probably non-RFC compliant & in the host name to block parsing. Here's how 3.0 handles it:
debug: uri found: http://wxmnuiuskn.net&xkvo3rhsp6mbz6nky9.cohunehcnhk.com-MUNGED/ debug: uri found: http://r.lycos.com/r/kg_xnsdaz_dqcuewqk/http://wxmnuiuskn.net&xkvo3rhsp6... debug: URIDNSBL: domains to query: lycos.com wxmnuiuskn.net
Where in fact the unqualified destination domain appears to be cohunehcnhk.com-MUNGED
Jeff C. -- "If it appears in hams, then don't list it."
Justin Mason wrote:
SpamAssassin is currently limited to identifying redirectors that require 'http(s)' to be in the URI. So it won't detect domains redirected to by the zdnet redirector and any other similar ones.
Daryl
Right. And obfuscation of the redirected-to "http" seems to be enough to confuse SA 3 into not extracting the second URI. Maybe we should make a Bugzilla ticket about that?
if you find one that SpamAssassin 3.1.0 doesn't decode correctly, sure ;) I thought we had those nailed.
Ok I checked this with the latest snapshot version of spamassassin (SpamAssassin version 3.1.0-r161778)
it works if the redirector is like
https://www.g00dl1fe.com/42.asp/http:/sheenier.net/soft/
or
https://www.g00dl1fe.com/42.asp/http://sheenier.net/soft/
0.6 URIBL_SBL Contains an URL listed in the SBL blocklist [URIs: g00dl1fe.com sheenier.net] 2.0 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist [URIs: sheenier.net] 1.6 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist [URIs: g00dl1fe.com sheenier.net] 0.5 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist [URIs: g00dl1fe.com sheenier.net] 2.0 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist [URIs: g00dl1fe.com sheenier.net] 3.9 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist [URIs: g00dl1fe.com sheenier.net]
But it fails to extract the "rdx56.info" from the redirector of Zdnet.
http://chkpt.zdnet.com/chkpt/howbad/rdx56.info/p/yo
where rdx50.info is listed in JP, WS, OB and SC surbls
I think we need to work on FQDN appearing as string in the url.
On Tuesday, April 19, 2005, 5:13:33 AM, Rakesh Rakesh wrote:
Ok I checked this with the latest snapshot version of spamassassin (SpamAssassin version 3.1.0-r161778)
it works if the redirector is like
or
0.6 URIBL_SBL Contains an URL listed in the SBL blocklist [URIs: g00dl1fe.com sheenier.net] 2.0 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist [URIs: sheenier.net] 1.6 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist [URIs: g00dl1fe.com sheenier.net] 0.5 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist [URIs: g00dl1fe.com sheenier.net] 2.0 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist [URIs: g00dl1fe.com sheenier.net] 3.9 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist [URIs: g00dl1fe.com sheenier.net]
Thanks much for the check!
But it fails to extract the "rdx56.info" from the redirector of Zdnet.
where rdx50.info is listed in JP, WS, OB and SC surbls
I think we need to work on FQDN appearing as string in the url.
Indeed, that would be good general solution to the problem, if somewhat resource intensive unless redirectors could specifically be detected. Otherwise checking every URI for additional domains might perhaps require a lot of CPU. It's probably a good question for the SpamAssassin folks.
Cheers,
Jeff C. -- "If it appears in hams, then don't list it."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jeff Chan writes:
On Tuesday, April 19, 2005, 5:13:33 AM, Rakesh Rakesh wrote:
But it fails to extract the "rdx56.info" from the redirector of Zdnet.
where rdx50.info is listed in JP, WS, OB and SC surbls
I think we need to work on FQDN appearing as string in the url.
Indeed, that would be good general solution to the problem, if somewhat resource intensive unless redirectors could specifically be detected. Otherwise checking every URI for additional domains might perhaps require a lot of CPU. It's probably a good question for the SpamAssassin folks.
Yeah. I'd be much obliged if somebody could open a bugzilla ticket on http://bugzilla.SpamAssassin.org/ about this... we should fix it (somehow).
- --j.
On Tuesday, April 19, 2005, 10:22:50 AM, Justin Mason wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jeff Chan writes:
On Tuesday, April 19, 2005, 5:13:33 AM, Rakesh Rakesh wrote:
But it fails to extract the "rdx56.info" from the redirector of Zdnet.
where rdx50.info is listed in JP, WS, OB and SC surbls
I think we need to work on FQDN appearing as string in the url.
Indeed, that would be good general solution to the problem, if somewhat resource intensive unless redirectors could specifically be detected. Otherwise checking every URI for additional domains might perhaps require a lot of CPU. It's probably a good question for the SpamAssassin folks.
Yeah. I'd be much obliged if somebody could open a bugzilla ticket on http://bugzilla.SpamAssassin.org/ about this... we should fix it (somehow).
- --j.
Hi Justin, I'm pretty sure this is essentially the same as the nate.com redirector ticket:
http://bugzilla.spamassassin.org/show_bug.cgi?id=4176
or at least it seems the solution might be similar.
Jeff C. -- "If it appears in hams, then don't list it."
-
Daryl C. W. O'Shea -
Jeff Chan -
jm＠jmason.org -
Rakesh -
SM -
Theo Van Dinter