You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by mouss <us...@free.fr> on 2006/04/11 19:32:41 UTC
xxxl spam
since most filters skip large messages, it may be tempting for spammers
to send large messagess:
- using a large but "invisible" part (either by using mime and putting a
large text part in an alternative mime, or using "invisible" chars
before their own text).
- using a large image
- large "tail" (spammers can append anything....).
- "unused" attachments
questions:
- has this already been seen?
- how can we mitigate this?
my first thought would be to "process" the message before passing it to
the filter. In particular, are there drawbacks/benefits if I remove
attachments before passing them to SA (or any other filter)?
Re: greetpause was Re: xxxl spam
Posted by mouss <us...@free.fr>.
Mike Jackson wrote:
>>> You can also impose this cost on spammers by enabling the GreetPause
>>> feature in the more recent versions of sendmail. This tells sendmail not
>>> to answer right away when receiving a connection, and to drop the
>>> connection if anything is received before the greeting is sent out. This
>>> punishes "slammer" spammers who push the whole SMTP conversation through
>>> and then disconnect. It also ensures that every connection from an
>>> unknown sender takes a minimum amount of time. You can add exceptions in
>>> your access database for your customers and frequent correspondents. For
>>> example, this exception drops the GreetPause to zero for my LAN (example
>>> is for 10.123/16):
>>>
>>> GreetPause:10.123 0
>>
>>
>> Is this as effective as greylisting?
>
> Perhaps not, but it also doesn't have any of the drawbacks (ie, delayed
> mail, need to whitelist non-behaving servers, etc.). I recently enabled
> it on my servers, and it's been stopping a ton of mail without any
> complaints from legitimate senders.
>
>
greetpause only blocks some ratware spam. If I was to write spam and/or
viruses, I would just add a sleep(x):
given N victims, choose M among them:
for i=0; i<M; i++
time(i) = connect to server(i)
for i=0; i<M; i++
t = now - time(i) + min_sleep
sleep(t)
send_junk()
(can be tuned if using multiple threads/processes).
so greetpause will certainly stop some ratware spam, but is not a "full"
solution.
also, if your greetpause requires sleep()-ing on every connection, then
it's not acceptable (for me) as this is a call for DoS. I am not aware
of any async MTA [read: one that will not sleep, but will handle other
connections in the meantime], at least in the open source world.
If you are after "miscreants", then partial-greylisting is probably more
effective (I mean greylisting some of the connections, based on the
client name, ip, behaviour, ... etc).
Re: greetpause was Re: xxxl spam
Posted by Mike Jackson <mj...@barking-dog.net>.
>> You can also impose this cost on spammers by enabling the GreetPause
>> feature in the more recent versions of sendmail. This tells sendmail not
>> to answer right away when receiving a connection, and to drop the
>> connection if anything is received before the greeting is sent out. This
>> punishes "slammer" spammers who push the whole SMTP conversation through
>> and then disconnect. It also ensures that every connection from an
>> unknown sender takes a minimum amount of time. You can add exceptions in
>> your access database for your customers and frequent correspondents. For
>> example, this exception drops the GreetPause to zero for my LAN (example
>> is for 10.123/16):
>>
>> GreetPause:10.123 0
>
>
> Is this as effective as greylisting?
Perhaps not, but it also doesn't have any of the drawbacks (ie, delayed
mail, need to whitelist non-behaving servers, etc.). I recently enabled it
on my servers, and it's been stopping a ton of mail without any complaints
from legitimate senders.
greetpause was Re: xxxl spam
Posted by "Michele Neylon:: Blacknight.ie" <mi...@blacknight.ie>.
Kenneth Porter wrote:
> You can also impose this cost on spammers by enabling the GreetPause
> feature in the more recent versions of sendmail. This tells sendmail not
> to answer right away when receiving a connection, and to drop the
> connection if anything is received before the greeting is sent out. This
> punishes "slammer" spammers who push the whole SMTP conversation through
> and then disconnect. It also ensures that every connection from an
> unknown sender takes a minimum amount of time. You can add exceptions in
> your access database for your customers and frequent correspondents. For
> example, this exception drops the GreetPause to zero for my LAN (example
> is for 10.123/16):
>
> GreetPause:10.123 0
Is this as effective as greylisting?
--
Mr Michele Neylon
Blacknight Solutions
Quality Business Hosting & Colocation
http://www.blacknight.ie/
Tel. 1850 927 280
Intl. +353 (0) 59 9183072
Direct Dial: +353 (0)59 9183090
Fax. +353 (0) 59 9164239
Re: xxxl spam
Posted by Kenneth Porter <sh...@sewingwitch.com>.
On Tuesday, April 11, 2006 2:14 PM -0400 Matt Kettler
<mk...@evi-inc.com> wrote:
> I've not seen it with dummy text, but I have seen the large image spam.
> However, it's very rare. The problem being that if you're a large-volume
> spammer, large messages take a longer time to send, and thus reduce your
> spams/minute.
You can also impose this cost on spammers by enabling the GreetPause
feature in the more recent versions of sendmail. This tells sendmail not to
answer right away when receiving a connection, and to drop the connection
if anything is received before the greeting is sent out. This punishes
"slammer" spammers who push the whole SMTP conversation through and then
disconnect. It also ensures that every connection from an unknown sender
takes a minimum amount of time. You can add exceptions in your access
database for your customers and frequent correspondents. For example, this
exception drops the GreetPause to zero for my LAN (example is for
10.123/16):
GreetPause:10.123 0
Re: relay distance and spam [was xxxl spam]
Posted by Mark Martinec <Ma...@ijs.si>.
On Tuesday April 11 2006 23:17, Kelson wrote:
> mouss wrote:
> > - multiple "internal" hops at either sender or receiver (I have N
> > Received headers added by my own MTA. and for mail fetched from an MSP,
> > there are still more....).
>
> Actually, if I'm reading this right, it's the number of IP hops between
> the sending server and the receiving server -- in other words, how many
> lines you'd see if you were on the receiving server and ran traceroute
> to the sending MTA.
Exactly. It is usually the number of hops a traceroute running on MTA
would show when tracing route to the host from which it is receiving a
message. (I say usually, because routes can be asymmetric, and we are
actually observing a remaining TTL field value in the IP packet, taking
into account an educated guess on the initial setting, based on detected
OS type).
Btw, a horizontal spread of 1 unit (in fig1) is an artificial white noise
added to spread numerous dots somewhat for a better view.
I guess we are somewhat lucky seeing a rather clearcut separation of
nearby friendly and distant wild-world hosts, and can use IP distance to
contribute a little score weight on distant hosts and subtract a little
for nearby hosts.
Mark
Re: relay distance and spam [was xxxl spam]
Posted by Kelson <ke...@speed.net>.
mouss wrote:
> - multiple "internal" hops at either sender or receiver (I have N Received
> headers added by my own MTA. and for mail fetched from an MSP, there are
> still more....).
Actually, if I'm reading this right, it's the number of IP hops between
the sending server and the receiving server -- in other words, how many
lines you'd see if you were on the receiving server and ran traceroute
to the sending MTA.
I've rarely seen any messages that passed through more than 5 MTAs --
certainly not enough to account for the graph. But 10 routers between
me and the sender? That doesn't seem unreasonable at all.
--
Kelson Vibber
SpeedGate Communications <www.speed.net>
relay distance and spam [was xxxl spam]
Posted by mouss <us...@free.fr>.
Mark Martinec wrote:
> http://www.ijs.si/software/amavisd/fig1.gif
> Spam score vs. IP distance in hops (our server is
> in European academic network Geant)
>
This one is amazing. there seems to be an empty space (most mail has
nhops <= 10 or => 14). I would "guess" that most ham wih large nhops is
from mailing lists. so the question is what would be the graphic if you
take into account:
- mailing lists forwarding
- multiple "internal" hops at either sender or receiver (I have N
Received headers added by my own MTA. and for mail fetched from an MSP,
there are still more....).
I would conjecture that most legitimate mail has two "real" hops (the
sending MTA and the receiving MTA).
Re: xxxl spam
Posted by Mark Martinec <Ma...@ijs.si>.
mouss wrote:
> since most filters skip large messages, it may be tempting for spammers
> to send large messagess:
I did some statistical analysis few weeks ago with SA 3.1.1
(SA called from amavisd-new, but that is beside the point).
Please see:
http://www.ijs.si/software/amavisd/fig4.gif
Shows spam score vs. mail size as a scattergram
http://www.ijs.si/software/amavisd/fig5.gif
Shows elapsed time for mail checking vs. mail size
(shown is total time, but >90% of it reflects processing
within SA and its plugins)
As a curiosity (but off topic), harvesting results from p0f
(passive operating system fingerprinting), here are two more:
http://www.ijs.si/software/amavisd/fig1.gif
Spam score vs. IP distance in hops (our server is
in European academic network Geant)
And perhaps most interesting of all (by again OT):
http://www.ijs.si/software/amavisd/fig2.gif
Spam score distribution as a percentage of all mail,
separate by each sending mail client's operating system.
Mark
Re: xxxl spam
Posted by Matt Kettler <mk...@evi-inc.com>.
Theo Van Dinter wrote:
> On Tue, Apr 11, 2006 at 02:46:41PM -0400, Matt Kettler wrote:
>> Of course, this can't work if you're using any kind of encapsulation options in
>> report_safe, but since MailScanner does all the markup itself, it doesn't hurt
>> it to send Mail::SpamAssassin a truncated version. Converting this to the
>> spamc/spamd model might be kind of difficult due to this, but it's worth
>> considering for spamc -c.
>
> It's been suggested before, but it doesn't quite work for SA
> unfortunately. SA is designed to be a generic mail filter, and some
> rules/plugins/etc expect to be able to see the entire original contents
> of the message, so we can't really trim off pieces. Also, things like
> spamc have no concept of what a message actually is, they just read in
> a bunch of data and send it somewhere, so the full message would have to
> be read in by spamd before anything could be trimmed off of it. At that
> point there's not a lot of savings in trimming off attachments (though the
> raw versions could potentially be stored in temp files instead of memory).
>
> And then, as you said, with encapsulation and such, we'd need the whole of the
> message anyway.
Agreed.. the only part of sa that this would be straightforward for would be
spamc -c.
At that point, spamc isn't piping the message back out, and isn't doing
encapsulation, so truncation would be irrelevant.
Re: xxxl spam
Posted by Theo Van Dinter <fe...@apache.org>.
On Tue, Apr 11, 2006 at 02:46:41PM -0400, Matt Kettler wrote:
> Of course, this can't work if you're using any kind of encapsulation options in
> report_safe, but since MailScanner does all the markup itself, it doesn't hurt
> it to send Mail::SpamAssassin a truncated version. Converting this to the
> spamc/spamd model might be kind of difficult due to this, but it's worth
> considering for spamc -c.
It's been suggested before, but it doesn't quite work for SA
unfortunately. SA is designed to be a generic mail filter, and some
rules/plugins/etc expect to be able to see the entire original contents
of the message, so we can't really trim off pieces. Also, things like
spamc have no concept of what a message actually is, they just read in
a bunch of data and send it somewhere, so the full message would have to
be read in by spamd before anything could be trimmed off of it. At that
point there's not a lot of savings in trimming off attachments (though the
raw versions could potentially be stored in temp files instead of memory).
And then, as you said, with encapsulation and such, we'd need the whole of the
message anyway.
--
Randomly Generated Tagline:
"NT is secure.... as long as you don't remove the shrink wrap." - G. Myers
Re: xxxl spam
Posted by Matt Kettler <mk...@evi-inc.com>.
Theo Van Dinter wrote:
> On Tue, Apr 11, 2006 at 02:14:26PM -0400, Matt Kettler wrote:
>> Well, SA automatically ignores attachments in recent versions. However,
>> hash-based plugins like razor, dcc, and pyzor work best when seeing all the
>> attachments.
>
> For completeness, the first sentence isn't exactly true.
> SA "automatically ignores attachments" for the standard set of body,
> header, and uri rules, but it still has to read in the data, store it in
> the message tree internally, and make the entire message text available
> for full rules.
Fair enough...
> There are also things like the AntiVirus plugin, etc, which may go ahead
> and decode attachments and do things with the data. I could easily see
> a plugin for ClamAV, or something scanning image files, etc.
>
> I think that at some point, the default size could go up, but I wouldn't
> try it for now.
FWIW, it might be worth considering the approach used by MailScanner.
MailScanner still scans large messages, but truncates messages over "Max
SpamAssassin Size". Presumably it does in a manner that still has the correct
mime boundaries, because I don't get any kind of superflous rule hits regarding
mime boundaries on large messages.
I've currently got this set to 60k, but MailScanner defaults to 30k.
Of course, this can't work if you're using any kind of encapsulation options in
report_safe, but since MailScanner does all the markup itself, it doesn't hurt
it to send Mail::SpamAssassin a truncated version. Converting this to the
spamc/spamd model might be kind of difficult due to this, but it's worth
considering for spamc -c.
Re: xxxl spam
Posted by Theo Van Dinter <fe...@apache.org>.
On Tue, Apr 11, 2006 at 02:14:26PM -0400, Matt Kettler wrote:
> Well, SA automatically ignores attachments in recent versions. However,
> hash-based plugins like razor, dcc, and pyzor work best when seeing all the
> attachments.
For completeness, the first sentence isn't exactly true.
SA "automatically ignores attachments" for the standard set of body,
header, and uri rules, but it still has to read in the data, store it in
the message tree internally, and make the entire message text available
for full rules.
There are also things like the AntiVirus plugin, etc, which may go ahead
and decode attachments and do things with the data. I could easily see
a plugin for ClamAV, or something scanning image files, etc.
I think that at some point, the default size could go up, but I wouldn't
try it for now.
--
Randomly Generated Tagline:
Zoidberg: That's where I'm meeting Uncle Zoid for lunch to
discuss my Hollywood dream. The next time you see me, don't
be surprised if I've eaten.
Re: Spam and the Internet [Was: xxxl spam]
Posted by Alan Premselaar <al...@12inch.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matt Kettler wrote:
...snip...
> Here's one, if you want to see it:
>
> http://mywebpages.comcast.net/mkettler/spam.jpg
>
>
> There's pretty close to zero chance that anyone in the US is going to hop on a
> plane and fly to Guatemala to buy ordinary lawn care products from a small
> store. But that's the kind of ads I'm getting.
but they've got heart-shaped pancake molds... you wouldn't fly to
guatamala for that? and at Q.29?! what a bargain!
(heh, i couldn't resist)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEQ0keE2gsBSKjZHQRAjkKAJ9AnC7vS409cSYvoyczXPpK9NNa9QCgtZsb
68xY13eQIvXXLSrkT996/hM=
=rejD
-----END PGP SIGNATURE-----
Re: Spam and the Internet [Was: xxxl spam]
Posted by Matt Kettler <mk...@evi-inc.com>.
mouss wrote:
> Matt Kettler wrote:
>>
>> Why anyone in Guatemala thinks I'll visit their store to spend "Q. 22"
>> on a
>> patio log fake fire log or "Q. 85" on a generic brand weed and feed
>> fertilizer
>> is beyond me.
>>
>
> dunno, but I can tell you that the net if full of people who love me and
> want me good. I keep winning all the lotteries. I can buy software at
> cheap prices (if someone can tell these guys that I have nor the time
> nor the need to use photoshop, that I already have windows+office, ...
> etc, that may save them some time/resources they can spend helping me in
> other areas:). others seems to need an urgent contact for an important
> relationship. I'm feeling like the ceo of a large company. Some even
> seem to know private infos about me. It seems I need some special pills.
> but for now, the names of the pills seem to change all the time. I'll
> wait until they get an agreement on how to name them:). They also keep
> talking about inches. if someone can tell them that we use the metric
> system here, I would be grateful...
Yeah, but all those actually have some chance of financial gain from someone
located in another country. You'd have to be stupid, but it's possible, because
all of those can close an electronic transaction with you.
These spams I get from .gt don't offer any kind of online ordering. They are ads
that you'd have to physically travel to the store in Guatemala to take advantage
of them. They're ordinary weekly sales fliers for an ordinary local store that's
so small that only 6 cars can park in front of it. (They have pictures of the
store in some of them). Delivered to my mailbox as 1/2 meg .jpg files. It's
really quite bizarre, and amusing.
Here's one, if you want to see it:
http://mywebpages.comcast.net/mkettler/spam.jpg
There's pretty close to zero chance that anyone in the US is going to hop on a
plane and fly to Guatemala to buy ordinary lawn care products from a small
store. But that's the kind of ads I'm getting.
Spam and the Internet [Was: xxxl spam]
Posted by mouss <us...@free.fr>.
Matt Kettler wrote:
> There's only one spammer that's done this to me. There's some group of stores in
> Guatemala that sends me high-res scans of their newspaper.
>
> Consejeros en Finanzas Empresariales, some kind of bank
> La Cuacao - some kind of electronics shop? or an eye doctor?
> cefesa hardware - a True Value hardware store.
>
>
> Why anyone in Guatemala thinks I'll visit their store to spend "Q. 22" on a
> patio log fake fire log or "Q. 85" on a generic brand weed and feed fertilizer
> is beyond me.
>
dunno, but I can tell you that the net if full of people who love me and
want me good. I keep winning all the lotteries. I can buy software at
cheap prices (if someone can tell these guys that I have nor the time
nor the need to use photoshop, that I already have windows+office, ...
etc, that may save them some time/resources they can spend helping me in
other areas:). others seems to need an urgent contact for an important
relationship. I'm feeling like the ceo of a large company. Some even
seem to know private infos about me. It seems I need some special pills.
but for now, the names of the pills seem to change all the time. I'll
wait until they get an agreement on how to name them:). They also keep
talking about inches. if someone can tell them that we use the metric
system here, I would be grateful...
Re: xxxl spam
Posted by Matt Kettler <mk...@evi-inc.com>.
mouss wrote:
> since most filters skip large messages, it may be tempting for spammers
> to send large messagess:
>
> - using a large but "invisible" part (either by using mime and putting a
> large text part in an alternative mime, or using "invisible" chars
> before their own text).
>
> - using a large image
>
> - large "tail" (spammers can append anything....).
>
> - "unused" attachments
>
> questions:
> - has this already been seen?
I've not seen it with dummy text, but I have seen the large image spam. However,
it's very rare. The problem being that if you're a large-volume spammer, large
messages take a longer time to send, and thus reduce your spams/minute.
There's only one spammer that's done this to me. There's some group of stores in
Guatemala that sends me high-res scans of their newspaper.
Consejeros en Finanzas Empresariales, some kind of bank
La Cuacao - some kind of electronics shop? or an eye doctor?
cefesa hardware - a True Value hardware store.
Why anyone in Guatemala thinks I'll visit their store to spend "Q. 22" on a
patio log fake fire log or "Q. 85" on a generic brand weed and feed fertilizer
is beyond me.
But other than these guys, I don't get any spams >250kb.
> - how can we mitigate this?
Personally, I think it is largely self-mitigating. Their size greatly limits
their potential distribution.
As I see it, there's very little large-spam out there.
>
>
> my first thought would be to "process" the message before passing it to
> the filter. In particular, are there drawbacks/benefits if I remove
> attachments before passing them to SA (or any other filter)?
Well, SA automatically ignores attachments in recent versions. However,
hash-based plugins like razor, dcc, and pyzor work best when seeing all the
attachments.