You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "@lbutlr" <kr...@kreme.com> on 2018/03/03 13:08:52 UTC
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's response)
On Feb 26, 2018, at 09:55, shanew@shanew.net wrote:
>
> This is why the DecodeShortURLs plugin has an explicit limit of 10
> lookups (and penalizes such with a total of 8 points).
I’d guess more than one redirect is highly suspicious and more than two is probably a waste of time, just score 5.0 and be done with it.
Has anyone done any analysis on multi-redirects?
--
This is my signature. There are many like it, but this one is mine.
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by David Jones <dj...@ena.com>.
On 03/18/2018 06:59 PM, RW wrote:
> On Sun, 18 Mar 2018 18:24:36 -0500
> David Jones wrote:
>
>> On 03/18/2018 06:01 PM, Alan Hodgson wrote:
>>> On Sun, 2018-03-18 at 17:14 -0500, David Jones wrote:
>>>> I have Steve Freegard's DecodeShortURLs.pm installed but didn't
>>>> get any HAS_SHORT_URL hits on this one:
>
>
>>> Is it getting any hits? It definitely hits on that one in a test
>>> here.
>>>
>>> Note it needs Perl's LWP::UserAgent and DBD::SQLite to get it to
>>> work at all.
>
> I don't think you actually need DBD::SQLite, it just enables caching to
> work.
>
>>>
>>
>> I am getting other HAS_SHORT_URL hits.
>
> Probably they are http links and you are missing LWP::Protocol::https
> which is needed to handle the https link in that email.
>
>
>
>
I was able to get LWP::Protocol::https installed on my mail filters and
now I am getting HAS_SHORT_URL hits on https links. Thanks for the tip!
--
David Jones
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by RW <rw...@googlemail.com>.
On Sun, 18 Mar 2018 18:24:36 -0500
David Jones wrote:
> On 03/18/2018 06:01 PM, Alan Hodgson wrote:
> > On Sun, 2018-03-18 at 17:14 -0500, David Jones wrote:
> >> I have Steve Freegard's DecodeShortURLs.pm installed but didn't
> >> get any HAS_SHORT_URL hits on this one:
> > Is it getting any hits? It definitely hits on that one in a test
> > here.
> >
> > Note it needs Perl's LWP::UserAgent and DBD::SQLite to get it to
> > work at all.
I don't think you actually need DBD::SQLite, it just enables caching to
work.
> >
>
> I am getting other HAS_SHORT_URL hits.
Probably they are http links and you are missing LWP::Protocol::https
which is needed to handle the https link in that email.
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by David Jones <dj...@ena.com>.
On 03/18/2018 06:01 PM, Alan Hodgson wrote:
> On Sun, 2018-03-18 at 17:14 -0500, David Jones wrote:
>> I have Steve Freegard's DecodeShortURLs.pm installed but didn't get any
>> HAS_SHORT_URL hits on this one:
>>
>> https://pastebin.com/t85b0Bns <https://pastebin.com/t85b0Bns >
>
> Is it getting any hits? It definitely hits on that one in a test here.
>
> Note it needs Perl's LWP::UserAgent and DBD::SQLite to get it to work at
> all.
>
I am getting other HAS_SHORT_URL hits. My 8 SA boxes are setup
identically with those 2 perl modules. The original server that
received this message does have other hits on HAS_SHORT_URL but this
message still is not hitting. Now it's scoring a 10.4 and would be
blocked because of DCC_CHECK and other things have caught up to it.
--
David Jones
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by Alan Hodgson <ah...@lists.simkin.ca>.
On Sun, 2018-03-18 at 17:14 -0500, David Jones wrote:
>
I have Steve Freegard's DecodeShortURLs.pm installed but didn't get any
> HAS_SHORT_URL hits on this one:
>
> https://pastebin.com/t85b0Bns
Is it getting any hits? It definitely hits on that one in a test here.
Note it needs Perl's LWP::UserAgent and DBD::SQLite to get it to work
at all.
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by David Jones <dj...@ena.com>.
On 03/10/2018 10:57 AM, Rob McEwen wrote:
> On 3/10/2018 11:43 AM, Matus UHLAR - fantomas wrote:
>>> On 3/10/2018 11:22 AM, Matus UHLAR - fantomas wrote:
>>>> this is apparently not the case of one url redirector (shortener)
>>>> points to
>>>> another shortener.
>>>>
>>>> I really hope that the DecodeShortURLs only checks fopr redirection
>>>> at those
>>>> known redirectors (shorteners), not each http->https shortener and only
>>>> evaluates redirection between them, ignoring http->https redirects
>>
>> On 10.03.18 11:32, Rob McEwen wrote:
>>> But also keep in mind that it is NOT rare for the initial shortner
>>> found in a spam... to redirect to a spammer's page (that isn't a URL
>>> shortner), then THAT page then redirects to the spammer's OTHER page
>>> (that isn't a URL shortner)... where the FIRST one is NOT blacklisted
>>> very many places... but the second page (that is often the final
>>> destination)... *is* heavily blacklisted. Often, the first page is
>>> hosted at a legit site that was hacked into by criminal spammers -
>>> and is HARDER for blacklists to list due to their good reputation.
>>
>> isn't this thread and the plugin discussed about shorteners?
>> I am aware of other possibilities to do redirects and about
>> consequencies of
>> following them.
>> note that for following the redirect, the destination must be
>> configured via
>> url_shortener directive.
>> what I wonder is, if there's real value in following the redirects.
>> (and if the following stops when the URL is blacklisted, since we're done
>> here).
>>
>
> The URL shortner follower plugin that Steve Freegard wrote... ALREADY
> follows my suggestions about following non-shortner redirects (after the
> initial shortner redirect). (except I'm not sure it already does my
> https suggestion?) ...and for good reason. You're tremendously
> undervaluing or just not understanding my last post. I suggestion you
> re-read it a couple of times. This tactic I mentioned that spammers
> use... is COMMON, and not following my last suggestion opens up a big
> loophole for spammers. Such spammers would be delighted by your last
> comment... and Steve Freegard went a different route for good reason.
> Keep in mind, I haven't veered off-topic because we're STILL talking
> about a possible chain of redirects that was still STARTED by a URL
> shortner.
>
I have Steve Freegard's DecodeShortURLs.pm installed but didn't get any
HAS_SHORT_URL hits on this one:
https://pastebin.com/t85b0Bns
I don't see much that can be done other than training Bayes which will
probably not help the next variation of this junk. I have reported to
Spamcop and Microsoft -- they MUST do a better job of outbound mail
filtering!
--
David Jones
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by Rob McEwen <ro...@invaluement.com>.
On 3/10/2018 11:43 AM, Matus UHLAR - fantomas wrote:
>> On 3/10/2018 11:22 AM, Matus UHLAR - fantomas wrote:
>>> this is apparently not the case of one url redirector (shortener)
>>> points to
>>> another shortener.
>>>
>>> I really hope that the DecodeShortURLs only checks fopr redirection
>>> at those
>>> known redirectors (shorteners), not each http->https shortener and only
>>> evaluates redirection between them, ignoring http->https redirects
>
> On 10.03.18 11:32, Rob McEwen wrote:
>> But also keep in mind that it is NOT rare for the initial shortner
>> found in a spam... to redirect to a spammer's page (that isn't a URL
>> shortner), then THAT page then redirects to the spammer's OTHER page
>> (that isn't a URL shortner)... where the FIRST one is NOT blacklisted
>> very many places... but the second page (that is often the final
>> destination)... *is* heavily blacklisted. Often, the first page is
>> hosted at a legit site that was hacked into by criminal spammers -
>> and is HARDER for blacklists to list due to their good reputation.
>
> isn't this thread and the plugin discussed about shorteners?
> I am aware of other possibilities to do redirects and about
> consequencies of
> following them.
> note that for following the redirect, the destination must be
> configured via
> url_shortener directive.
> what I wonder is, if there's real value in following the redirects.
> (and if the following stops when the URL is blacklisted, since we're done
> here).
>
The URL shortner follower plugin that Steve Freegard wrote... ALREADY
follows my suggestions about following non-shortner redirects (after the
initial shortner redirect). (except I'm not sure it already does my
https suggestion?) ...and for good reason. You're tremendously
undervaluing or just not understanding my last post. I suggestion you
re-read it a couple of times. This tactic I mentioned that spammers
use... is COMMON, and not following my last suggestion opens up a big
loophole for spammers. Such spammers would be delighted by your last
comment... and Steve Freegard went a different route for good reason.
Keep in mind, I haven't veered off-topic because we're STILL talking
about a possible chain of redirects that was still STARTED by a URL
shortner.
--
Rob McEwen
https://www.invaluement.com
+1 (478) 475-9032
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On 3/10/2018 11:22 AM, Matus UHLAR - fantomas wrote:
>>this is apparently not the case of one url redirector (shortener)
>>points to
>>another shortener.
>>
>>I really hope that the DecodeShortURLs only checks fopr redirection
>>at those
>>known redirectors (shorteners), not each http->https shortener and only
>>evaluates redirection between them, ignoring http->https redirects
On 10.03.18 11:32, Rob McEwen wrote:
>But also keep in mind that it is NOT rare for the initial shortner
>found in a spam... to redirect to a spammer's page (that isn't a URL
>shortner), then THAT page then redirects to the spammer's OTHER page
>(that isn't a URL shortner)... where the FIRST one is NOT blacklisted
>very many places... but the second page (that is often the final
>destination)... *is* heavily blacklisted. Often, the first page is
>hosted at a legit site that was hacked into by criminal spammers -
>and is HARDER for blacklists to list due to their good reputation.
isn't this thread and the plugin discussed about shorteners?
I am aware of other possibilities to do redirects and about consequencies of
following them.
note that for following the redirect, the destination must be configured via
url_shortener directive.
what I wonder is, if there's real value in following the redirects.
(and if the following stops when the URL is blacklisted, since we're done
here).
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Posli tento mail 100 svojim znamim - nech vidia aky si idiot
Send this email to 100 your friends - let them see what an idiot you are
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by Rob McEwen <ro...@invaluement.com>.
On 3/10/2018 11:22 AM, Matus UHLAR - fantomas wrote:
> this is apparently not the case of one url redirector (shortener)
> points to
> another shortener.
>
> I really hope that the DecodeShortURLs only checks fopr redirection at
> those
> known redirectors (shorteners), not each http->https shortener and only
> evaluates redirection between them, ignoring http->https redirects
But also keep in mind that it is NOT rare for the initial shortner found
in a spam... to redirect to a spammer's page (that isn't a URL
shortner), then THAT page then redirects to the spammer's OTHER page
(that isn't a URL shortner)... where the FIRST one is NOT blacklisted
very many places... but the second page (that is often the final
destination)... *is* heavily blacklisted. Often, the first page is
hosted at a legit site that was hacked into by criminal spammers - and
is HARDER for blacklists to list due to their good reputation. Then the
2nd final destination page is just a heavily blacklisted spammer's
throwaway domain. Therefore, there is some value to following the
redirects a little further than what you suggest, and then collecting
all of those host names or domains, checking ALL of them against
URI/domain blacklists. (within reason... after too many redirects, it is
better to just stop and add points to the spam score)
--
Rob McEwen
https://www.invaluement.com
+1 (478) 475-9032
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On 3/10/2018 3:20 AM, Matus UHLAR - fantomas wrote:
>>do you have an example of any chained redirection not suspicious?
On 10.03.18 11:04, Rob McEwen wrote:
>I haven't examined the code for that plugin very much (yet!).... but
>one type of very common redirect that is very innocent... is the fact
>that a MASSIVE percentage of web sites have switched to all SSL sites
>in the past few years, due to Google now punishing http and/or
>rewarding https... in the search engine rankings. But there are still
>many links and redirectors pointing to the non-SSL versions of those
>sites, which is then typically redirected to the SSL version.
this is apparently not the case of one url redirector (shortener) points to
another shortener.
I really hope that the DecodeShortURLs only checks fopr redirection at those
known redirectors (shorteners), not each http->https shortener and only
evaluates redirection between them, ignoring http->https redirects
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I don't have lysdexia. The Dog wouldn't allow that.
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by Rob McEwen <ro...@invaluement.com>.
On 3/10/2018 3:20 AM, Matus UHLAR - fantomas wrote:
> do you have an example of any chained redirection not suspicious?
I haven't examined the code for that plugin very much (yet!).... but one
type of very common redirect that is very innocent... is the fact that a
MASSIVE percentage of web sites have switched to all SSL sites in the
past few years, due to Google now punishing http and/or rewarding
https... in the search engine rankings. But there are still many links
and redirectors pointing to the non-SSL versions of those sites, which
is then typically redirected to the SSL version. Therefore, if the code
for this plugin (and others using this tactic) doesn't do this
already... it should probably not count THAT particular redirect as a
spam indicator, when counting the total number of redirects.
--
Rob McEwen
https://www.invaluement.com
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 07.03.18 10:59, shanew@shanew.net wrote:
>Just FYI, it does add 3.0 points as soon as it sees any chaining at
>all. The other 5.0 points get added at 10 redirections. That said,
>I think you're guess is right that redirections start to look really
>suspicious after just 3 or 4.
do you have an example of any chained redirection not suspicious?
>On Sat, 3 Mar 2018, @lbutlr wrote:
>
>>On Feb 26, 2018, at 09:55, shanew@shanew.net wrote:
>>>
>>>This is why the DecodeShortURLs plugin has an explicit limit of 10
>>>lookups (and penalizes such with a total of 8 points).
>>
>>I’d guess more than one redirect is highly suspicious and more than two is probably a waste of time, just score 5.0 and be done with it.
>>
>>Has anyone done any analysis on multi-redirects?
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
How does cat play with mouse? cat /dev/mouse
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by sh...@shanew.net.
Just FYI, it does add 3.0 points as soon as it sees any chaining at
all. The other 5.0 points get added at 10 redirections. That said,
I think you're guess is right that redirections start to look really
suspicious after just 3 or 4.
On Sat, 3 Mar 2018, @lbutlr wrote:
> On Feb 26, 2018, at 09:55, shanew@shanew.net wrote:
>>
>> This is why the DecodeShortURLs plugin has an explicit limit of 10
>> lookups (and penalizes such with a total of 8 points).
>
> I’d guess more than one redirect is highly suspicious and more than two is probably a waste of time, just score 5.0 and be done with it.
>
> Has anyone done any analysis on multi-redirects?
>
>
--
Public key #7BBC68D9 at | Shane Williams
http://pgp.mit.edu/ | System Admin - UT CompSci
=----------------------------------+-------------------------------
All syllogisms contain three lines | shanew@shanew.net
Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by Benny Pedersen <me...@junc.eu>.
John Hardin skrev den 2018-03-03 19:28:
>>> This is why the DecodeShortURLs plugin has an explicit limit of 10
>>> lookups (and penalizes such with a total of 8 points).
>> I’d guess more than one redirect is highly suspicious and more than
>> two is probably a waste of time, just score 5.0 and be done with it.
> +1
add blacklist internaly to DecodeShortURLs plugin, and reduce redirector
list to who support abuse reports only
bit.ly is safe to test
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by John Hardin <jh...@impsec.org>.
On Sat, 3 Mar 2018, @lbutlr wrote:
> On Feb 26, 2018, at 09:55, shanew@shanew.net wrote:
>>
>> This is why the DecodeShortURLs plugin has an explicit limit of 10
>> lookups (and penalizes such with a total of 8 points).
>
> I’d guess more than one redirect is highly suspicious and more than two is probably a waste of time, just score 5.0 and be done with it.
+1
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Back in 1969 the technology to fake a Moon landing didn't exist,
but the technology to actually land there did.
Today, it is the opposite. -- unknown
-----------------------------------------------------------------------
10 days until Albert Einstein's 139th Birthday