You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Jason Haar <Ja...@trimble.co.nz> on 2010/01/11 11:22:11 UTC
pill image spam learns to walk
Hi there
We've been getting a few of these leaking through in the past couple of
weeks.
http://pastebin.com/m574da717
They aren't triggering (enough) network rule matches, contain a
bayes-killer, and even FuzzyOCR can't manage the swirly image trick they
pull. Has anyone come up with a way to fight these? (I've actually added
all the phrases that occur in this image to FuzzyOCR - didn't help)
Thanks
--
Cheers
Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Re: pill image spam learns to walk
Posted by Terry Carmen <te...@cnysupport.com>.
On 01/11/2010 12:57 PM, Terry Carmen wrote:
> exactly every (or any) domain
Should be "exactly *matches* every (or any) domain"
--
Terry Carmen
CNY Support, LLC
315.382.3939
http://cnysupport.com
Re: pill image spam learns to walk
Posted by Terry Carmen <te...@cnysupport.com>.
On 01/11/2010 12:42 PM, Ted Mittelstaedt wrote:
> Terry Carmen wrote:
>> On 01/11/2010 05:22 AM, Jason Haar wrote:
>>> Hi there
>>>
>>> We've been getting a few of these leaking through in the past couple of
>>> weeks.
>>>
>>> http://pastebin.com/m574da717
>>>
>>> They aren't triggering (enough) network rule matches, contain a
>>> bayes-killer, and even FuzzyOCR can't manage the swirly image trick
>>> they
>>> pull. Has anyone come up with a way to fight these? (I've actually
>>> added
>>> all the phrases that occur in this image to FuzzyOCR - didn't help)
>> Unless you changed the headers, it looks like it came from an IP with
>> no reverse DNS entry.
>>
>> This is easy enough to stop dead in it's tracks at your MTA. If there
>> isn't any reverse DNS, the chances of it being a legitimate mail
>> server are pretty slim.
>>
>
> This is the WRONG way to do this - it amazes me that in 2010 on an
> anti-spam mailing list that we have people making such statements.
>
> The SMTP RFC 2821 does NOT mandate the existence of a PTR record for
> an SMTP sender. The DNS RFC 1912 also does not mandate a
> corresponding PTR
> for a mailserver hostname. Implies, yes, but there's no requirement.
> There is a very good reason for this.* Blocking at the MTA based on
> the lack of a PTR record is incorrect. The correct way is to assign a
> spam score in SA to hosts lacking a PTR, the same way you do to mail
> that contains HTML, etc.
SA is great software, but scanning is not a lightweight process. If I
can ditch millions of spams before they ever hit SA, and need to
manually whitelist a couple of IPs, that's a great deal as far as I'm
concerned.
Every reasonable ISP I've seen has managed to assign a PTR record for
their mail server. I don't care if it exactly every (or any) domain they
transport mail for, as long as it exists. Sure, it's possible to break
things if you work at it hard enough, but generally speaking, I don't care.
Terry
Re: pill image spam learns to walk
Posted by Kai Schaetzl <ma...@conactive.com>.
Ted, sorry, but your case is lost (since long, look around) and I won't
bite in such an off-topic discussion here. Please stop telling others that
refusing to accept mail from non-rDNS machines is "incorrect". If you
*prefer* to handle this at SA level, that's your choice and you can tell
that. But stop saying in this authoritative way that it is the only
reputable (="correct") way. It is definitely not.
My last bits on this topic.
Kai
--
Get your web at Conactive Internet Services: http://www.conactive.com
Re: pill image spam learns to walk
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>> Ted Mittelstaedt wrote on Mon, 11 Jan 2010 15:27:07 -0800:
>>> It simply means that sites WITHOUT a PTR are still fully compliant mailers.
> Kai Schaetzl wrote:
>> This has nothing to do with RFC-compliance, but with policy, well
>> accepted policy.
On 11.01.10 20:42, Ted Mittelstaedt wrote:
> Policy that should be handled in SA and not the MTA, which I've said
> twice now.
It would not be a policy then. There are sites/admins who enforce this
policy at SMTP level. And it's their decision.
If you don't have any, better do not complain to those policy makers but to
your ISP.
--
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.
Windows 2000: 640 MB ought to be enough for anybody
Re: pill image spam learns to walk
Posted by Ted Mittelstaedt <te...@ipinc.net>.
Kai Schaetzl wrote:
> Ted Mittelstaedt wrote on Mon, 11 Jan 2010 15:27:07 -0800:
>
>> It simply means that sites WITHOUT a PTR are still fully compliant mailers.
>
> This has nothing to do with RFC-compliance, but with policy, well accepted
> policy.
Policy that should be handled in SA and not the MTA, which I've said
twice now.
> If you can't understand that I can't help.
You cannot help someone when you have no real grasp of the topic
under discussion.
> No need to shoot this out.
>
Well, let's see. I say it is wrong to tell people to make PTR
checks in the MTA when they have SA running, and to make them in
SA. Then I explain why you shouldn't do them in the MTA and cite
facts to back up my statements.
You know you can't argue against facts, and you know your wrong,
and rather than just man up and admit it, you try to cover it
up by making the false claim that I am advising to not make PTR
checks at all. You repeat this false claim multiple times to make
yourself believe it, and maybe to attempt to get me to forget what I
said, and adopt your false claim and start arguing for it.
No wonder you don't want to get into a shooting match. You know
you were caught, and your outgunned.
Ted
> Kai
>
Re: pill image spam learns to walk
Posted by Kai Schaetzl <ma...@conactive.com>.
Ted Mittelstaedt wrote on Mon, 11 Jan 2010 15:27:07 -0800:
> It simply means that sites WITHOUT a PTR are still fully compliant mailers.
This has nothing to do with RFC-compliance, but with policy, well accepted
policy. If you can't understand that I can't help. No need to shoot this out.
Kai
--
Get your web at Conactive Internet Services: http://www.conactive.com
Re: pill image spam learns to walk - best way to block it - hostkarma
Posted by Marc Perkel <ma...@perkel.com>.
For what it's worth my Lunk Email Filter service block 100% of virus
generated spam such as this pill image spam. But anyone can tap into
this for free by doing 2 things.
First - add tarbaby.junkemailfilter.com as you highest numbered MX record.
Second - use the hostkarma.junkemailfilter.com black list.
To be really effective you need to do both. Bot spam tends to spam all
MX records and focuses on the highest MX. So using us as the highest MX
lets us harvest your spam bot info. Then when you use our black list -
it's tuned to the spambots that are spamming you. So it becomes even
more effective.
And spam attempts to our tarbaby server is a spam that you're not
getting not need to use your resources to block. So a significant amount
of your spam will just go away.
We catch spam bots on the first attempt and within 2 minutes they are
listed in our black list.
Here's the info on these lists:
http://wiki.junkemailfilter.com/index.php/Spam_DNS_Lists
Feel free to use it.
Re: pill image spam learns to walk
Posted by Ted Mittelstaedt <te...@ipinc.net>.
Kai Schaetzl wrote:
> Ted Mittelstaedt wrote on Mon, 11 Jan 2010 09:42:25 -0800:
>
>> This is the WRONG way to do this
>
> It's the right way. The FP rate is almost zero and it encourages the few
> offending ones to quickly add rDNS, really quick.
>
>> * The reason this is NOT mandated anywhere is because if it was then
>> sites running multiple mailing domains on a single server could easily
>> overflow the DNS UDP packet space with a list of PTR's for the server -
>
> We are not talking about adding PTR for all domains, just for exactly
> *one*. And that doesn't even need to resolve back and forth.
>
Clearly you fail to understand anything, here.
PTR's are not mandated because the standard has to apply to all sites,
both sites with multiple domains and sites without. It does not mean
that because it's not mandated that it's a bad idea to add a PTR record.
It simply means that sites WITHOUT a PTR are still fully compliant mailers.
The entire point of SA is to filter based on "fuzzy" logic, meaning
that the sender's mail is only wrong based on an arbitrary standard that
the person running SA pulls out of their ass. A "no PTR" rule is
EXACTLY the kind of fuzzy decision that SA is designed to make decisions
on. That is where that kind of rule belongs.
Your advice is kind of like the guy who puts a spoiler on a sports
car that is never driven faster than 100mph. The spoiler, Spamassassin
in this case, is an expensive, gas-mileage sucking "dunsel" that is only
there because of the bragging rights the guy gets by having it there,
it does absolutely nothing to help the car. In fact, anyone who knows
anything about fast cars, looks at the thing and thinks "how gay is
that?" and what a moron the idiot driving it is.
If you want to build a mailserver WITHOUT SA, then sure, go ahead and
add in rules like "no PTR" to the MTA - because you cannot do it any
other way.
But don't spend the money and CPU cycles putting SA on a mailserver
and then have it sit there doing nothing, like that spoiler on the
ass-end of a trans-am.
In other words, be a professional not a bozo!
Ted
Re: pill image spam learns to walk
Posted by Kai Schaetzl <ma...@conactive.com>.
Ted Mittelstaedt wrote on Mon, 11 Jan 2010 09:42:25 -0800:
> This is the WRONG way to do this
It's the right way. The FP rate is almost zero and it encourages the few
offending ones to quickly add rDNS, really quick.
> * The reason this is NOT mandated anywhere is because if it was then
> sites running multiple mailing domains on a single server could easily
> overflow the DNS UDP packet space with a list of PTR's for the server -
We are not talking about adding PTR for all domains, just for exactly
*one*. And that doesn't even need to resolve back and forth.
Kai
--
Get your web at Conactive Internet Services: http://www.conactive.com
Re: pill image spam learns to walk
Posted by Ted Mittelstaedt <te...@ipinc.net>.
Terry Carmen wrote:
> On 01/11/2010 05:22 AM, Jason Haar wrote:
>> Hi there
>>
>> We've been getting a few of these leaking through in the past couple of
>> weeks.
>>
>> http://pastebin.com/m574da717
>>
>> They aren't triggering (enough) network rule matches, contain a
>> bayes-killer, and even FuzzyOCR can't manage the swirly image trick they
>> pull. Has anyone come up with a way to fight these? (I've actually added
>> all the phrases that occur in this image to FuzzyOCR - didn't help)
> Unless you changed the headers, it looks like it came from an IP with no
> reverse DNS entry.
>
> This is easy enough to stop dead in it's tracks at your MTA. If there
> isn't any reverse DNS, the chances of it being a legitimate mail server
> are pretty slim.
>
This is the WRONG way to do this - it amazes me that in 2010 on an
anti-spam mailing list that we have people making such statements.
The SMTP RFC 2821 does NOT mandate the existence of a PTR record for an
SMTP sender. The DNS RFC 1912 also does not mandate a corresponding PTR
for a mailserver hostname. Implies, yes, but there's no requirement.
There is a very good reason for this.* Blocking at the MTA based on the
lack of a PTR record is incorrect. The correct way is to assign a spam
score in SA to hosts lacking a PTR, the same way you do to mail that
contains HTML, etc.
Ted
* The reason this is NOT mandated anywhere is because if it was then
sites running multiple mailing domains on a single server could easily
overflow the DNS UDP packet space with a list of PTR's for the server -
causing the resolver to exceed 512 bytes on the DNS UDP response, or
causing a switch to TCP - either of which can break some firewalls.
For example the Cisco PIX came standard out-of-the-box with a DNS
filter that blocked DNS UDP packets larger than 512.
Re: pill image spam learns to walk
Posted by Alex <my...@gmail.com>.
Hi,
> Unless you changed the headers, it looks like it came from an IP with no
> reverse DNS entry.
>
> This is easy enough to stop dead in it's tracks at your MTA. If there isn't
> any reverse DNS, the chances of it being a legitimate mail server are pretty
> slim.
Yes, but not enough to categorically block all incoming mail based on
that, though. At least in my environment, all it would take is one
customer to call and complain, and force me to have to do even more
work to make them an exception and exclude them from this filter.
Thanks,
Alex
Re: pill image spam learns to walk
Posted by Kai Schaetzl <ma...@conactive.com>.
Terry Carmen wrote on Mon, 11 Jan 2010 12:08:16 -0500:
> Unless you changed the headers, it looks like it came from an IP with no
> reverse DNS entry.
Yeah, his own delivery chain. Not really a candidate for blocking ;-)
Kai
--
Get your web at Conactive Internet Services: http://www.conactive.com
Re: pill image spam learns to walk
Posted by Terry Carmen <te...@cnysupport.com>.
On 01/11/2010 05:22 AM, Jason Haar wrote:
> Hi there
>
> We've been getting a few of these leaking through in the past couple of
> weeks.
>
> http://pastebin.com/m574da717
>
> They aren't triggering (enough) network rule matches, contain a
> bayes-killer, and even FuzzyOCR can't manage the swirly image trick they
> pull. Has anyone come up with a way to fight these? (I've actually added
> all the phrases that occur in this image to FuzzyOCR - didn't help)
Unless you changed the headers, it looks like it came from an IP with no
reverse DNS entry.
This is easy enough to stop dead in it's tracks at your MTA. If there
isn't any reverse DNS, the chances of it being a legitimate mail server
are pretty slim.
Terry
Re: pill image spam learns to walk
Posted by Mike Cardwell <sp...@lists.grepular.com>.
On 11/01/2010 14:55, Charles Gregory wrote:
> On Mon, 11 Jan 2010, Mike Cardwell wrote:
> : I just copied and pasted that out of pastebin into a little project I've
> : been working on. Here's the result:
> : http://spamalyser.com/v/6xnb26gp/mime
>
> Question: What does spamalyzer do with an HTML message part?
> It is of concern (naturally) that implanted malicious scripts not be
> rendered whole and complete....
Presently it renders them as plain text. I'm fully aware of the
potential problems with it. Ideally I'd like to be able to render those
parts as HTML, but I need to be 100% sure that I've stripped out
anything dangerous (including embedded remote content by default) first.
It's on the "ToDo List" page.
I'm also aware of the issues surrounding people potentially uploading
images and then linking to them from spam websites or spam. That's why
I've put http referer restrictions in place.
--
Mike Cardwell : UK based IT Consultant, LAMP developer, Linux admin
Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226
Technical Blog : Tech Blog - https://secure.grepular.com/blog/
Spamalyser : Spam Tool - http://spamalyser.com/
Re: pill image spam learns to walk
Posted by Charles Gregory <cg...@hwcn.org>.
On Mon, 11 Jan 2010, Mike Cardwell wrote:
: I just copied and pasted that out of pastebin into a little project I've
: been working on. Here's the result:
: http://spamalyser.com/v/6xnb26gp/mime
Question: What does spamalyzer do with an HTML message part?
It is of concern (naturally) that implanted malicious scripts not be
rendered whole and complete....
- C
Re: pill image spam learns to walk
Posted by Mike Cardwell <sp...@lists.grepular.com>.
On 11/01/2010 10:22, Jason Haar wrote:
> Hi there
>
> We've been getting a few of these leaking through in the past couple of
> weeks.
>
> http://pastebin.com/m574da717
>
> They aren't triggering (enough) network rule matches, contain a
> bayes-killer, and even FuzzyOCR can't manage the swirly image trick they
> pull. Has anyone come up with a way to fight these? (I've actually added
> all the phrases that occur in this image to FuzzyOCR - didn't help)
I just copied and pasted that out of pastebin into a little project I've
been working on. Here's the result:
http://spamalyser.com/v/6xnb26gp/mime
Unlike with pastebin, it mime decodes emails and you can see the decoded
image at the bottom of that page.
Just thought some of you might be interested. It's quite new and
requires some work but the basic functionality is there.
--
Mike Cardwell : UK based IT Consultant, LAMP developer, Linux admin
Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226
Technical Blog : Tech Blog - https://secure.grepular.com/blog/
Spamalyser : Spam Tool - http://spamalyser.com/
Re: pill image spam learns to walk
Posted by Kai Schaetzl <ma...@conactive.com>.
Alex wrote on Mon, 11 Jan 2010 12:38:29 -0500:
> Just to clarify, you're referring to this, right:
>
> Received: from mx.sourceforge.net by mailsrv1.trimble.co.nz
> (envelope-from <from@ef-
>
> How would add the rule you are suggesting? It would be specific to
> sourceforge.net, and have a table where its authoritative IP and MX
> are stored, right?
I would rather look for To: *@users.sourceforge.net and score if the From
is not from sourceforge.net (meta-rule). This indicates that it is an
external mail that was sent to an SF users alias. I've personally not ever
gotten a legitimate mail to this alias from outside of SF (and I think SF
admin/dev/news mail uses the target address directly, anyway, and not the
alias). So, depending on what you get over this route you may either score
or drop completely.
Kai
--
Get your web at Conactive Internet Services: http://www.conactive.com
Re: pill image spam learns to walk
Posted by Alex <my...@gmail.com>.
HI,
> * 1.0 FORGED_TBIRD_IMG_SIZE Likely forged Thunderbird image spam
> * 1.0 FORGED_TBIRD_IMG_ARROW Likely forged Thunderbird image spam
>
> and you could add, say 4.0, for each mail coming thru your SF.net alias
> and not coming from SF.
Just to clarify, you're referring to this, right:
Received: from mx.sourceforge.net by mailsrv1.trimble.co.nz
(envelope-from <from@ef-
How would add the rule you are suggesting? It would be specific to
sourceforge.net, and have a table where its authoritative IP and MX
are stored, right?
Thanks,
Alex
Re: pill image spam learns to walk
Posted by Kai Schaetzl <ma...@conactive.com>.
scores these new tests on 3.3.0
* 1.0 FORGED_TBIRD_IMG_SIZE Likely forged Thunderbird image spam
* 1.0 FORGED_TBIRD_IMG_ARROW Likely forged Thunderbird image spam
and you could add, say 4.0, for each mail coming thru your SF.net alias
and not coming from SF.
Kai
--
Get your web at Conactive Internet Services: http://www.conactive.com