You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Bob McClure Jr <ro...@earthlink.net> on 2005/03/23 16:34:30 UTC
a more effective spam defense
Two of the great things I have gleaned from this list are:
1. Greylisting is reported to stop upwards of 80-90% of the spam from
even coming in the door. The downside is the likely delays imposed
on the rest of the mail, maybe in terms of hours.
2. Spammers seem to be attracted to secondary MXs.
This morning, in the shower (where many great ideas are born), it
occurred to me that if one combined the two concepts, i.e. implement
greylisting on (only) the secondary MX server, one might get all the
benefits with no downside.
Have I missed something?
Cheers,
--
Bob McClure, Jr. Bobcat Open Systems, Inc.
robertmcclure@earthlink.net http://www.bobcatos.com
Worry is a waste of the imagination.
Re: question about greylisting
Posted by "Eric A. Hall" <eh...@ehsco.com>.
alan premselaar wrote:
> Rob McEwen wrote:
>
>>I have a question about greylisting.
>>
>>Does greylisting **always** involve blocking upon receipt of the SMTP
>>envelope and not accepting the rest of the message?
>>
>>Or, can greylisting alternatively work where it **does** accept the
>>**entire** message (for auditing purposes, for example) and THEN returns the
>>temporary rejection code?
> however, temporarily rejecting the message after fully receiving it and
> processing it kind of defeats the purpose of greylisting. (or at least
> one major purpose of it)
Yeah, it would still require CPU processing, which is one of the
advantages of refusing to accept the mail in the first place. OTOH, it
would still have value in terms of keeping spam away from the end-users,
which is its own reward sometimes.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: question about greylisting
Posted by alan premselaar <al...@12inch.com>.
Rob McEwen wrote:
> I have a question about greylisting.
>
> Does greylisting **always** involve blocking upon receipt of the SMTP
> envelope and not accepting the rest of the message?
>
> Or, can greylisting alternatively work where it **does** accept the
> **entire** message (for auditing purposes, for example) and THEN returns the
> temporary rejection code?
>
> Thanks,
>
> Rob McEwen
> PowerView Systems
>
>
Rob,
That depends on how you implement it. Certainly if you're running
Sendmail, a tool like MIMEDefang would allow you to implement
greylisting in any manner you saw fit for your installation.
however, temporarily rejecting the message after fully receiving it and
processing it kind of defeats the purpose of greylisting. (or at least
one major purpose of it)
hth
alan
RE: question about greylisting
Posted by Bret Miller <br...@wcg.org>.
> I have a question about greylisting.
>
> Does greylisting **always** involve blocking upon receipt of
> the SMTP envelope and not accepting the rest of the message?
>
> Or, can greylisting alternatively work where it **does** accept the
> **entire** message (for auditing purposes, for example) and
> THEN returns the temporary rejection code?
The concept is generally that you want to reduce the load on your own
server, so you wouldn't want the overhead of receiving the entire message
first. However, in some environments like Merak server where greylisting
isn't implemented in the SMTP protocol handler, I can see it as effective to
receive the entire message, and add delays and/or temporary rejections from
the static filter application. I would think the effect on the sending
server would be the same or even worse than rejection or delay earlier in
the protocol. However, there would be more overhead on your own server too.
Bret
question about greylisting
Posted by Rob McEwen <ro...@powerviewsystems.com>.
I have a question about greylisting.
Does greylisting **always** involve blocking upon receipt of the SMTP
envelope and not accepting the rest of the message?
Or, can greylisting alternatively work where it **does** accept the
**entire** message (for auditing purposes, for example) and THEN returns the
temporary rejection code?
Thanks,
Rob McEwen
PowerView Systems
Re: a more effective spam defense
Posted by Matt Kettler <mk...@comcast.net>.
At 07:59 AM 3/24/2005, Kevin Peuhkurinen wrote:
>It certainly sounds like a good idea. I guess the real question is: if
>the spamming software in use is given a temporary failure when trying to
>send to the secondary MX server, will it immediately try to send to the
>primary server? If so, your idea will have no impact. If you could set
>this up as a test, it would be most interesting to hear the results.
It's possible, but it seems a lot of spamming software is completely
stateless. It doesn't retry at all, which is why greylisting is effective.
In my network, only 8% of the hosts ever given a 4xx by my greylist attempt
to deliver again within 5 days. My Greylist is very short (1 minute), so
pretty much any retry at all will get past it. Given that a lot of spam
can't even leap over this short hurdle, I doubt they try the primary MX
unless the secondary is completely unavailable.
I'd definitely love to hear what the results are. Theoreticaly they should
be good.
Re: a more effective spam defense
Posted by Kevin Peuhkurinen <ke...@hepcoe.com>.
Bob McClure Jr wrote:
>Two of the great things I have gleaned from this list are:
>
>1. Greylisting is reported to stop upwards of 80-90% of the spam from
> even coming in the door. The downside is the likely delays imposed
> on the rest of the mail, maybe in terms of hours.
>
>2. Spammers seem to be attracted to secondary MXs.
>
>This morning, in the shower (where many great ideas are born), it
>occurred to me that if one combined the two concepts, i.e. implement
>greylisting on (only) the secondary MX server, one might get all the
>benefits with no downside.
>
>Have I missed something?
>
>Cheers,
>
>
It certainly sounds like a good idea. I guess the real question is: if
the spamming software in use is given a temporary failure when trying to
send to the secondary MX server, will it immediately try to send to the
primary server? If so, your idea will have no impact. If you could
set this up as a test, it would be most interesting to hear the results.
Kevin
Re: a more effective spam defense
Posted by Matt Kettler <mk...@evi-inc.com>.
Bob McClure Jr wrote:
>Two of the great things I have gleaned from this list are:
>
>1. Greylisting is reported to stop upwards of 80-90% of the spam from
> even coming in the door. The downside is the likely delays imposed
> on the rest of the mail, maybe in terms of hours.
>
>2. Spammers seem to be attracted to secondary MXs.
>
>This morning, in the shower (where many great ideas are born), it
>occurred to me that if one combined the two concepts, i.e. implement
>greylisting on (only) the secondary MX server, one might get all the
>benefits with no downside.
>
>Have I missed something?
>
That sounds like a very effective tactic.
Another tactic, one I use, is to greylist only certain hosts on your
primary MX. I use milter-greylist 2.0 (beta) and it's ability to use
ACLs to greylist a variety of hosts:
APNIC
LACNIC
Hosts with no reverse DNS (milter-greylist will see these as
having a "domain" that's a bracketed IP.)
#requires 2.0b3 or higher with the extendedregex setting
enabled:
acl greylist domain
/\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\]/
Hosts which reverse DNS to well-known home-user patterns. such as:
acl greylist domain /pcp.*\..*\.comcast\.net/
This enables me to greylist away about 50% of spam, with very little
legitimate mail getting delayed. Sure I do get the occasional legitimate
mail from APNIC/LACNIC or with no RDNS, which is why blacklisting it
would be foolish in my situation. However, I can fairly safely greylist
them to help weed out the few good mails from the tons of garbage.
I kind of like this approach because it allows you to be more aggressive
than you otherwise could be with a blacklist. There's plenty of sites
out there that I'm sure outright blacklist everything in my greylist
ACL. Unfortunately, I can't be that aggressive here. Greylists make a
good compromise, as any false positives result in delayed mail, not
failed mail.
Also, any spam messages which do get past the greylist are more likely
to be in the RBLs, so it improves SA's hit rate too.
Re: a more effective spam defense
Posted by ga...@netrox.net.
This reminded me of this page I read the other day. ;-) (no offense)
http://www.rhyolite.com/anti-spam/you-might-be.html
It's an amusing read if anyone hasn't seen it yet.
> Two of the great things I have gleaned from this list are:
>
> 1. Greylisting is reported to stop upwards of 80-90% of the spam from
> even coming in the door. The downside is the likely delays imposed
> on the rest of the mail, maybe in terms of hours.
>
> 2. Spammers seem to be attracted to secondary MXs.
>
> This morning, in the shower (where many great ideas are born), it
> occurred to me that if one combined the two concepts, i.e. implement
> greylisting on (only) the secondary MX server, one might get all the
> benefits with no downside.
>
> Have I missed something?
>
> Cheers,
> --
> Bob McClure, Jr. Bobcat Open Systems, Inc.
> robertmcclure@earthlink.net http://www.bobcatos.com
> Worry is a waste of the imagination.
>
Re: a more effective spam defense
Posted by Robert Brooks <ro...@hyperlink-interactive.co.uk>.
Bob McClure Jr wrote:
> Two of the great things I have gleaned from this list are:
>
> 1. Greylisting is reported to stop upwards of 80-90% of the spam from
> even coming in the door. The downside is the likely delays imposed
> on the rest of the mail, maybe in terms of hours.
>
> 2. Spammers seem to be attracted to secondary MXs.
>
> This morning, in the shower (where many great ideas are born), it
> occurred to me that if one combined the two concepts, i.e. implement
> greylisting on (only) the secondary MX server, one might get all the
> benefits with no downside.
>
> Have I missed something?
works well for me, I also have greylisting and (postfix) sender address
verification on the secondary mx. I may start adding points in SA for
email arriving through the secondary.
--
Robert Brooks, Network Manager, Cable & Wireless UK
<ro...@hyperlink-interactive.co.uk> http://hyperlink-interactive.co.uk/
Tel: +44 (0)20 7339 8600 Fax: +44 (0)20 7339 8601
- Help Microsoft stamp out piracy. Give Linux to a friend today! -