Mailing List Archive

"Pill" spams
Getting a bunch of these, and I'm getting very low scores, using the
latest spamassassin rules, and the most common third-party rulesets.

Also using spamhaus, investment and other DNSBLs, but my users seem to
be getting these before the urls are making their way into those
DNSBLs.

The subject is about various types of pills, and I do note that the
Subject line header is often in mixed case - not just the subject
itself, but even the word "subject" - it might be "SubjeCT" or
"subjeCT" or "SUBJect", but I don't see a rule for anything like this.

There's almost always a link and then a bit of random text.

Here are three examples:

http://pastebin.com/ycvfX5Np
http://pastebin.com/ApdN9V0W
http://pastebin.com/bcUggrC6



Can anyone offer any help?
Re: "Pill" spams [ In reply to ]
Hi,

> Getting a bunch of these, and I'm getting very low scores, using the
> latest spamassassin rules, and the most common third-party rulesets.
>
> Also using spamhaus, investment and other DNSBLs, but my users seem to
> be getting these before the urls are making their way into those
> DNSBLs.
>
> The subject is about various types of pills, and I do note that the
> Subject line header is often in mixed case - not just the subject
> itself, but even the word "subject" - it might be "SubjeCT" or
> "subjeCT" or "SUBJect", but I don't see a rule for anything like this.
>
> There's almost always a link and then a bit of random text.
>
> Here are three examples:
>
> http://pastebin.com/ycvfX5Np
> http://pastebin.com/ApdN9V0W
> http://pastebin.com/bcUggrC6

+1 for these. I've seen a ton of these, and the only protection I have
is a local URIBL I've built for the many new domains that haven't yet
been added to the public URIBLs.

Yours don't have any spamassassin/amavisd headers. How are you processing these?

They typically also only BAYES_50 for me.

Thanks,
Alex
Re: "Pill" spams [ In reply to ]
On 4/9/2012 5:39 PM, Thomas Johnson wrote:
> Getting a bunch of these, and I'm getting very low scores, using the
> latest spamassassin rules, and the most common third-party rulesets.
>
> Also using spamhaus, investment and other DNSBLs, but my users seem to
> be getting these before the urls are making their way into those
> DNSBLs.
>
> The subject is about various types of pills, and I do note that the
> Subject line header is often in mixed case - not just the subject
> itself, but even the word "subject" - it might be "SubjeCT" or
> "subjeCT" or "SUBJect", but I don't see a rule for anything like this.

That sounds like it might be good rule-fodder. "subject", "Subject",
and "SUBJECT" are possibly valid, but the other funky capitalizations
might be worth a few points.

--
Bowie
Re: "Pill" spams [ In reply to ]
On Tue, Apr 10, 2012 at 7:08 AM, Bowie Bailey <Bowie_Bailey@buc.com> wrote:
> That sounds like it might be good rule-fodder.  "subject", "Subject",
> and "SUBJECT" are possibly valid, but the other funky capitalizations
> might be worth a few points.


And how would one write a rule for that? It's not a header rule that
matches the content of the Subject header line, but the initial
"SubjeCT" itself. And how to do the proper regex match?

Any other ideas on these pill spams? What are they scoring for anyone else?
Re: "Pill" spams [ In reply to ]
On Mon, Apr 9, 2012 at 3:33 PM, Alex <mysqlstudent@gmail.com> wrote:
> +1 for these. I've seen a ton of these, and the only protection I have
> is a local URIBL I've built for the many new domains that haven't yet
> been added to the public URIBLs.
>
> Yours don't have any spamassassin/amavisd headers. How are you processing these?

I grabbed a few before they are being processed. They're running
through spamassassin.


Anybody got any ideas? These are driving me crazy!
Re: "Pill" spams [ In reply to ]
On 4/10/2012 11:42 AM, Thomas Johnson wrote:
> Any other ideas on these pill spams? What are they scoring for anyone else?

Hi. I've been following this thread. Here are some (random) thoughts &
suggestions:

(1) In some of those examples Thomas provided, at least one of the
assigned name servers had a hostname which contained a domain name...
where that domain name was blacklisted on either multi.surblorg or
dbl.spamhaus.org ...Therefore, an SA rule that grabs the name servers
for the same domains it checked against URI lists, extracts out the
domain names from them (where different from the actual domain you did
the lookup on), and then checks those against URI blacklists--could
possibly have produced a higher score... even where other URI lists had
missed those domains.

NOTES:
(a) BTW, invaluement does NOTHING regarding name servers of
spamvertized domains... and we've never done anything with them in
the past. Eventually, we plan to change that... in a variety of ways...

(b) If anyone programs this idea into SA, or anywhere else, then
this should be a separate step AFTER regular URI checking....giving
the message a chance to "short circuit" out of processing if it
already scored high enough after URI checking. Why? Because this
would defeat some of the benefits of fast URI checking if it was
done in tandem with the URI checking. Basically, URI checking can be
lightening fast... especially if you are checking the extracted URIs
against a local rbldnsd server. In contrast, anytime you do a name
server lookup to some stranger's domain, you're subjecting yourself
to the mercy of their reply speed... and many of those spammers use
screwed up and/or overloaded equipment. (even if your DNS timeout
setting becomes a "safety net", that is still order of magnitudes
slower than rbldnsd checking!)

(2) Thomas specifically mentioned that invalument, and other lists he
uses, didn't catch these. There may be a reason invaluement missed some
of these:

(a) In February and early March, we implemented the largest hardware
and software upgrades in the 15-year history of our company. It was
massive (for us). We went "all 64 bit" at the same time. Overall,
the upgrade was a huge success... but even as recently as today...
we're still putting a few things back together and are not quite up
to "full speed". There were intermittent outages and degradation in
effectiveness though large parts of February and March. But we're
almost finished and are now "fine tuning" various things. I wonder
if some of those missed spams came when we were having some of our
worst problems, during the thick of those hardware/software
upgrades? (even last week, we had some disruptions) Hopefully, we'll
do much better from this point forward... certainly, in other ways,
the improves hardware is already speeding things up... we just
needed to work out the kinks... getting all that new 64-bit software
to work together.

(b) Now that we have this upgrade completed... we're trying now to
expand our spam feeds. I think that spammers have often learned not
only how to avoid hitting our traps directly... but may have
discovered (even if just through process of elimination) some of our
external spam sources. (which is not a bad thing as that means that
those providing us spam... are getting less spam). Or, maybe not...
maybe I'm just paranoid! But, the bottom line is that our new
equipment greatly expands our ability to quickly process more spam
sources. If anyone reading this is interested, and can provide one..
let me know (off list!). We could possibly even work out a discount
on invaluement access ...if your feed is VERY prolific. (contact me
off-list for details, if interested) With more spam feeds, we hope
to cast a "wider net" and catch more of those URIs that have eluded
many (and sometimes all!) blacklists!

--
Rob McEwen
http://dnsbl.invaluement.com/
rob@invaluement.com
+1 (478) 475-9032
Re: "Pill" spams [ In reply to ]
On Tue, 10 Apr 2012, Thomas Johnson wrote:

> On Tue, Apr 10, 2012 at 7:08 AM, Bowie Bailey <Bowie_Bailey@buc.com> wrote:
>> That sounds like it might be good rule-fodder.  "subject", "Subject",
>> and "SUBJECT" are possibly valid, but the other funky capitalizations
>> might be worth a few points.
>
> And how would one write a rule for that?

Check the __TO_EQ_FM header rules for ideas.

I'll take a shot at something this weekend if nobody does earlier.

--
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
-----------------------------------------------------------------------
Health Care _is_ a right - the government has no business keeping
you from getting it. But forcing somebody else to pay for your
health care at gunpoint (i.e. through taxation) is _not_ a right.
-----------------------------------------------------------------------
3 days until Thomas Jefferson's 269th Birthday
Re: "Pill" spams [ In reply to ]
On 04/10/2012 08:07 PM, Rob McEwen wrote:

> (b) If anyone programs this idea into SA, or anywhere else, then
> this should be a separate step AFTER regular URI checking....giving
> the message a chance to "short circuit" out of processing if it
> already scored high enough after URI checking. Why? Because this
> would defeat some of the benefits of fast URI checking if it was
> done in tandem with the URI checking. Basically, URI checking can be
> lightening fast... especially if you are checking the extracted URIs
> against a local rbldnsd server. In contrast, anytime you do a name
> server lookup to some stranger's domain, you're subjecting yourself
> to the mercy of their reply speed... and many of those spammers use
> screwed up and/or overloaded equipment. (even if your DNS timeout
> setting becomes a "safety net", that is still order of magnitudes
> slower than rbldnsd checking!)

afaik, SA does async lookups so you have next to no delay - negligible
Re: "Pill" spams [ In reply to ]
On 4/10/2012 3:16 PM, Axb wrote:
> On 04/10/2012 08:07 PM, Rob McEwen wrote:
>
>> (b) If anyone programs this idea into SA, or anywhere else, then
>> this should be a separate step AFTER regular URI checking....giving
>> the message a chance to "short circuit" out of processing if it
>> already scored high enough after URI checking. Why? Because this
>> would defeat some of the benefits of fast URI checking if it was
>> done in tandem with the URI checking. Basically, URI checking
>> can be
>> lightening fast... especially if you are checking the extracted
>> URIs
>> against a local rbldnsd server. In contrast, anytime you do a name
>> server lookup to some stranger's domain, you're subjecting yourself
>> to the mercy of their reply speed... and many of those spammers use
>> screwed up and/or overloaded equipment. (even if your DNS timeout
>> setting becomes a "safety net", that is still order of magnitudes
>> slower than rbldnsd checking!)
>
> afaik, SA does async lookups so you have next to no delay - negligible

sounds good.. except... consider this scenario...

A person uses the system I described above, but where the name server
fetches, & lookups on domains contained within those nameserver hosts...
all happen async. But the domains themselves are HEAVILY blacklisted....
found on SURBL, URIBL, DBL, and ivmURI... and the end users subscribes
to datafeeds from ALL of those... so THOSE lookups are to a local
rbldnsd server running on a dedicated machine.. which means... super
fast queries... as in <1ms. With those domains in that message getting
MANY hits, and with other things already having hit... suddenly... the
spam score jumps super high in extremely little time.

Meanwhile, the snowshoe spammer's DNS server happens to be messed up,
overloaded, and returns answers within about 4 seconds.

in this scenario... which, though rare... might actually be MORE common
percentage-wise than the number of times an actual domain-blacklist
"hit" on a domains' nameserver actually causes a spam to be blocked....
again, in this scenario, async or not... doesn't that whole mail session
then get "bottled up" on waiting on the nameserver lookups?

--
Rob McEwen
http://dnsbl.invaluement.com/
rob@invaluement.com
+1 (478) 475-9032
Re: "Pill" spams [ In reply to ]
On Tue, 10 Apr 2012 17:58:51 -0400
Rob McEwen wrote:


> Meanwhile, the snowshoe spammer's DNS server happens to be messed up,
> overloaded, and returns answers within about 4 seconds.

But unless I'm misunderstanding, the NS lookups would be done on the
TLDs nameservers, rather than the spammer's DNS server.
Re: "Pill" spams [ In reply to ]
On 4/10/2012 6:29 PM, RW wrote:
> On Tue, 10 Apr 2012 17:58:51 -0400
> Rob McEwen wrote:
>> Meanwhile, the snowshoe spammer's DNS server happens to be messed up,
>> overloaded, and returns answers within about 4 seconds.
> But unless I'm misunderstanding, the NS lookups would be done on the
> TLDs nameservers, rather than the spammer's DNS server.

The sneakiest of spammy domains are the ones NOT seen before, and thus
NOT is anyone's cache. Therefore, .../I WAS THINKING THAT... /the lookup
on the domain's NS server would OFTEN have to propagate back to the
authoritative DNS server for that domain.... that being the spammer's
DNS server... at the time the message is evaluated.

But you're right... maybe to get the DNS server assignment for that
domain, it only has to go to the TLD's nameserver, grabbing information
propagated to the TLD from the registrar for that domain. Good point!

(still much slower than DNSBL lookups to an rbldnsd server... but
probably not any slower than DNSBL lookups to a remote 3rd party DNS
blacklist)

--
Rob McEwen
http://dnsbl.invaluement.com/
rob@invaluement.com
+1 (478) 475-9032
Re: "Pill" spams [ In reply to ]
On Tue, 10 Apr 2012, John Hardin wrote:

> On Tue, 10 Apr 2012, Thomas Johnson wrote:
>
>> On Tue, Apr 10, 2012 at 7:08 AM, Bowie Bailey <Bowie_Bailey@buc.com>
>> wrote:
>> > That sounds like it might be good rule-fodder.  "subject", "Subject",
>> > and "SUBJECT" are possibly valid, but the other funky capitalizations
>> > might be worth a few points.
>>
>> And how would one write a rule for that?
>
> Check the __TO_EQ_FM header rules for ideas.
>
> I'll take a shot at something this weekend if nobody does earlier.

I supplied this directly to Thomas earlier in the week, and it's in my
sandbox:

header SUBJ_ODD_CASE ALL =~ /\n(?!(?:Subject:|SUBJECT:|subject:))(?i:subject:)/sm
describe SUBJ_ODD_CASE Oddly mixed-case Subject: header


--
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
-----------------------------------------------------------------------
Our government should bear in mind the fact that the American
Revolution was touched off by the then-current government
attempting to confiscate firearms from the people.
-----------------------------------------------------------------------
4 days until the 237th anniversary of The Shot Heard 'Round The World
Re: "Pill" spams [ In reply to ]
On 16/04/12 04:56, John Hardin wrote:
> On Tue, 10 Apr 2012, John Hardin wrote:
>
>> On Tue, 10 Apr 2012, Thomas Johnson wrote:
>>
>>> On Tue, Apr 10, 2012 at 7:08 AM, Bowie Bailey <Bowie_Bailey@buc.com>
>>> wrote:
>>> > That sounds like it might be good rule-fodder. "subject", "Subject",
>>> > and "SUBJECT" are possibly valid, but the other funky capitalizations
>>> > might be worth a few points.
>>>
>>> And how would one write a rule for that?
>>
>> Check the __TO_EQ_FM header rules for ideas.
>>
>> I'll take a shot at something this weekend if nobody does earlier.
>
> I supplied this directly to Thomas earlier in the week, and it's in my
> sandbox:
>
> header SUBJ_ODD_CASE ALL =~
> /\n(?!(?:Subject:|SUBJECT:|subject:))(?i:subject:)/sm
> describe SUBJ_ODD_CASE Oddly mixed-case Subject: header
>
>

Hi John,

I have quite a few examples of these in my archives, and I confirm your
rule catches them - nice job :-)

Further, I note that to date the examples I have also appear to be
omitting a space between the end of "Subject:" and the start of the
actual subject text (examples on pastebin below). I wonder if this could
also be leveraged into a rule?

http://pastebin.com/xPf4XgJY

For example, I'd expect to see:

Subject: Re: Some text

and not:

Subject:Re:Some text

I have ~100 further examples of these that do not have mixed case
Subject (pastebin below), mostly pill spams that look like they are sent
by the same broken bot mailer, just with "Subject" in more conventional
case.

http://pastebin.com/Zu0uvViQ

Regards.
Re: "Pill" spams [ In reply to ]
On 20/04/12 20:17, Ned Slider wrote:
> On 16/04/12 04:56, John Hardin wrote:
>> On Tue, 10 Apr 2012, John Hardin wrote:
>>
>>> On Tue, 10 Apr 2012, Thomas Johnson wrote:
>>>
>>>> On Tue, Apr 10, 2012 at 7:08 AM, Bowie Bailey <Bowie_Bailey@buc.com>
>>>> wrote:
>>>> > That sounds like it might be good rule-fodder. "subject", "Subject",
>>>> > and "SUBJECT" are possibly valid, but the other funky capitalizations
>>>> > might be worth a few points.
>>>>
>>>> And how would one write a rule for that?
>>>
>>> Check the __TO_EQ_FM header rules for ideas.
>>>
>>> I'll take a shot at something this weekend if nobody does earlier.
>>
>> I supplied this directly to Thomas earlier in the week, and it's in my
>> sandbox:
>>
>> header SUBJ_ODD_CASE ALL =~
>> /\n(?!(?:Subject:|SUBJECT:|subject:))(?i:subject:)/sm
>> describe SUBJ_ODD_CASE Oddly mixed-case Subject: header
>>
>>
>
> Hi John,
>
> I have quite a few examples of these in my archives, and I confirm your
> rule catches them - nice job :-)
>
> Further, I note that to date the examples I have also appear to be
> omitting a space between the end of "Subject:" and the start of the
> actual subject text (examples on pastebin below). I wonder if this could
> also be leveraged into a rule?
>
> http://pastebin.com/xPf4XgJY
>
> For example, I'd expect to see:
>
> Subject: Re: Some text
>
> and not:
>
> Subject:Re:Some text
>

Hmm, not as easy to write a rule as I first thought as it would appear
that when using the header Subject, SA strips the leading white space
that we are trying to test for.

So I took inspiration from your rule above, and came up with:

header LOCAL_SUBJ_MISSPACED ALL =~ /\n(?i:^Subject:(?!($|\s)))/sm
describe LOCAL_SUBJ_MISSPACED Subject: missing whitespace

which appears to work as expected.

John - please could you explain the closing /sm as I'm unfamiliar with
it's usage?

Thanks.
Re: "Pill" spams [ In reply to ]
On 20/04/12 23:24, Ned Slider wrote:
> On 20/04/12 20:17, Ned Slider wrote:
>> On 16/04/12 04:56, John Hardin wrote:
>>> On Tue, 10 Apr 2012, John Hardin wrote:
>>>
>>>> On Tue, 10 Apr 2012, Thomas Johnson wrote:
>>>>
>>>>> On Tue, Apr 10, 2012 at 7:08 AM, Bowie Bailey <Bowie_Bailey@buc.com>
>>>>> wrote:
>>>>> > That sounds like it might be good rule-fodder. "subject", "Subject",
>>>>> > and "SUBJECT" are possibly valid, but the other funky
>>>>> capitalizations
>>>>> > might be worth a few points.
>>>>>
>>>>> And how would one write a rule for that?
>>>>
>>>> Check the __TO_EQ_FM header rules for ideas.
>>>>
>>>> I'll take a shot at something this weekend if nobody does earlier.
>>>
>>> I supplied this directly to Thomas earlier in the week, and it's in my
>>> sandbox:
>>>
>>> header SUBJ_ODD_CASE ALL =~
>>> /\n(?!(?:Subject:|SUBJECT:|subject:))(?i:subject:)/sm
>>> describe SUBJ_ODD_CASE Oddly mixed-case Subject: header
>>>
>>>
>>
>> Hi John,
>>
>> I have quite a few examples of these in my archives, and I confirm your
>> rule catches them - nice job :-)
>>
>> Further, I note that to date the examples I have also appear to be
>> omitting a space between the end of "Subject:" and the start of the
>> actual subject text (examples on pastebin below). I wonder if this could
>> also be leveraged into a rule?
>>
>> http://pastebin.com/xPf4XgJY
>>
>> For example, I'd expect to see:
>>
>> Subject: Re: Some text
>>
>> and not:
>>
>> Subject:Re:Some text
>>
>
> Hmm, not as easy to write a rule as I first thought as it would appear
> that when using the header Subject, SA strips the leading white space
> that we are trying to test for.
>
> So I took inspiration from your rule above, and came up with:
>
> header LOCAL_SUBJ_MISSPACED ALL =~ /\n(?i:^Subject:(?!($|\s)))/sm
> describe LOCAL_SUBJ_MISSPACED Subject: missing whitespace
>
> which appears to work as expected.
>
> John - please could you explain the closing /sm as I'm unfamiliar with
> it's usage?
>
> Thanks.
>
>

I found the explanation of the sm modifiers in the perlre manual.

Tidying up my rule a little:

header LOCAL_SUBJ_MISSPACED ALL =~ /\nSubject:(?!($|\s))/ism
describe LOCAL_SUBJ_MISSPACED Subject: missing whitespace
Re: "Pill" spams [ In reply to ]
On Fri, 20 Apr 2012, Ned Slider wrote:

> On 16/04/12 04:56, John Hardin wrote:
>>
>> header SUBJ_ODD_CASE ALL =~
>> /\n(?!(?:Subject:|SUBJECT:|subject:))(?i:subject:)/sm
>> describe SUBJ_ODD_CASE Oddly mixed-case Subject: header
>
> I have quite a few examples of these in my archives, and I confirm your rule
> catches them - nice job :-)

Yay. Hopefully those will start showing up in the corpus so that rule will
get promoted out of my sandbox.

> Further, I note that to date the examples I have also appear to be omitting a
> space between the end of "Subject:" and the start of the actual subject text
> (examples on pastebin below). I wonder if this could also be leveraged into a
> rule?

Already there.

http://ruleqa.spamassassin.org/20120420-r1328260-n/T_HDRS_MISSP

It's not doing too well at the moment given corpus starvation. I don't
think it's in the last update either.

Again, having those messages in the spam corpus would help...

--
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
-----------------------------------------------------------------------
Where We Want You To Go Today 09/13/07: Microsoft patents in-OS
adware architecture that incorporates monitoring and analysis of
user actions and interrupting the user to display apparently
relevant advertisements (U.S. Patent #20070214042)
-----------------------------------------------------------------------
3 days until Max Planck's 154th birthday
Re: "Pill" spams [ In reply to ]
On Fri, 20 Apr 2012, Ned Slider wrote:

> John - please could you explain the closing /sm as I'm unfamiliar with it's
> usage?

Multiline matching.

--
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
-----------------------------------------------------------------------
Men by their constitutions are naturally divided in to two parties:
1. Those who fear and distrust the people and wish to draw all
powers from them into the hands of the higher classes. 2. Those who
identify themselves with the people, have confidence in them,
cherish and consider them as the most honest and safe, although not
the most wise, depository of the public interests.
-- Thomas Jefferson
-----------------------------------------------------------------------
3 days until Max Planck's 154th birthday