From: Andy Dills on

I've been investigating postscreen, as we've been address probed/bombed
for years, as we have a few domains that are very old (well, early 90s)
that had a lot of users back in the dialup days. Our approach was to just
throw hardware at the problem, and we've had a whole cluster of servers
just sending out 550s all day long for years now.

We don't do any RBL checks at the postfix level; we have amavisd-new
handle all of that via spamassassin. I'm hesitant to allow a single
blacklist to determine the fate of mail acceptance, especially when we
have a very low false negative rate with amavisd/SA. Essentially, we'd
rather throw hardware at the problem than potentially reject legit mail.

My primary question is, would we see significant improvement by using
postscreen if we don't use RBLs?

Also, would postscreen_cache_map work with a mysql backend?

Thanks,
Andy

---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---

From: Robert Schetterer on
Am 27.05.2010 15:34, schrieb Andy Dills:
>
> I've been investigating postscreen, as we've been address probed/bombed
> for years, as we have a few domains that are very old (well, early 90s)
> that had a lot of users back in the dialup days. Our approach was to just
> throw hardware at the problem, and we've had a whole cluster of servers
> just sending out 550s all day long for years now.

same here, old short domains, openrelays in early times
but checked to handle it with one machine, but of course yours might be
more spammy at all
>
> We don't do any RBL checks at the postfix level;

why do you not use selective rbl checks, only for dynip etc, as well as
greylisting, there are a lot good cheap tricks with restictions that
should help

and/or perhaps use recent with iptables and/or fail2ban

we have amavisd-new
> handle all of that via spamassassin. I'm hesitant to allow a single
> blacklist to determine the fate of mail acceptance, especially when we
> have a very low false negative rate with amavisd/SA. Essentially, we'd
> rather throw hardware at the problem than potentially reject legit mail.

amavis should not gamble a lot with spam/virus until if you have good
checks before it
i have one support ticket a week i.e.
by 3000 Mailboxes, mostly problems of the sender, extrem rare rbl
related, nothing that cant be handeled easy

>
> My primary question is, would we see significant improvement by using
> postscreen if we don't use RBLs?

as far i know postscreen should help anyway
but you should measure aud investigate your logs if a cheap/short 550
is more usefull sometimes

>
> Also, would postscreen_cache_map work with a mysql backend?

dont think so, but gurus should know exactly

>
> Thanks,
> Andy
>
> ---
> Andy Dills
> Xecunet, Inc.
> www.xecu.net
> 301-682-9972
> ---

after all dont expect spammers/bots will give up only
cause you have new antispam features integrated
you may clean up your logs and/or need less resources
but at my spam domains , spam traffic was never
related to what antispam feature i ever integrated
it was always in waves

--
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

From: Wietse Venema on
Andy Dills:
>
> I've been investigating postscreen, as we've been address probed/bombed
> for years, as we have a few domains that are very old (well, early 90s)
> that had a lot of users back in the dialup days. Our approach was to just
> throw hardware at the problem, and we've had a whole cluster of servers
> just sending out 550s all day long for years now.
>
> We don't do any RBL checks at the postfix level; we have amavisd-new
> handle all of that via spamassassin. I'm hesitant to allow a single
> blacklist to determine the fate of mail acceptance, especially when we
> have a very low false negative rate with amavisd/SA. Essentially, we'd
> rather throw hardware at the problem than potentially reject legit mail.
>
> My primary question is, would we see significant improvement by using
> postscreen if we don't use RBLs?

In my experience, the "pregreet" check kills off 50% of the zombies.
Of course malware will "improve" and I expect to add deeper protocol
checks (command pipelining, greylist) in anticipation.

> Also, would postscreen_cache_map work with a mysql backend?

postscreen needs very low latency (I put in explicit tests for
this). Also, postscreen requires read, write, iterate support
which is implemented only for file-based databases.

If table access requires 10ms, then postscreen can handle only 100
connection requests per second. You would be better off not using
postscreen and instead turning up the number of smtpd processes.

Wietse

From: Nataraj on
Andy Dills wrote:
> I've been investigating postscreen, as we've been address probed/bombed
> for years, as we have a few domains that are very old (well, early 90s)
> that had a lot of users back in the dialup days. Our approach was to just
> throw hardware at the problem, and we've had a whole cluster of servers
> just sending out 550s all day long for years now.
>
> We don't do any RBL checks at the postfix level; we have amavisd-new
> handle all of that via spamassassin. I'm hesitant to allow a single
> blacklist to determine the fate of mail acceptance, especially when we
> have a very low false negative rate with amavisd/SA. Essentially, we'd
> rather throw hardware at the problem than potentially reject legit mail.
>
> My primary question is, would we see significant improvement by using
> postscreen if we don't use RBLs?
>
> Also, would postscreen_cache_map work with a mysql backend?
>
> Thanks,
> Andy
>
> ---
> Andy Dills
> Xecunet, Inc.
> www.xecu.net
> 301-682-9972
> ---
>
Using things like amavisd and spamassasin besides being very costly in
terms of performance, is far more vulnerable to security exploits than
rejecting as many connections as possible at an earlier time. I have
used the various checks for valid domain names, helo names, etc, in
conjunction with the RBL's to minimize scanning with spamassasin. I
use restriction classes to define more and less conservative policys for
different domains and even specific users when necessary.

smtpd_restriction_classes = restrictive, permissive

restrictive =
reject_rbl_client zen.spamhaus.org
reject_rbl_client dul.dnsbl.sorbs.net
reject_rbl_client bl.spamcop.net

permissive =
reject_rbl_client pbl.spamhaus.org
reject_rbl_client dul.dnsbl.sorbs.net


check_recipient_access hash:/etc/postfix/smtpd_recipient_access

smtpd_recipient_access contains:
mydomain.com restrictive
# I get the abuse mail and don't want to see alot of spam
abuse(a)otherdomain.com restrictive
otherdomain.org permissive
127.0.0.1 OK


The permissive class is very conservative and should cause practically
no false positives. Even my restrictive class includes rbls known to
have extremely low false positive rates. Spamhaus is known to be one of
the most accurate rbl's with an excellent hit rate and low false
positives. If you have a large site, check their web pages, since they
do charge for high volume query rates and will block your access if you
exceed the free limit.

Nataraj

From: LuKreme on
On 27-May-2010, at 07:34, Andy Dills wrote:
>
> I've been investigating postscreen, as we've been address probed/bombed
> for years, as we have a few domains that are very old (well, early 90s)
> that had a lot of users back in the dialup days. Our approach was to just
> throw hardware at the problem, and we've had a whole cluster of servers
> just sending out 550s all day long for years now.
>
> We don't do any RBL checks at the postfix level;

That's just … silly

> we have amavisd-new
> handle all of that via spamassassin. I'm hesitant to allow a single
> blacklist to determine the fate of mail acceptance, especially when we
> have a very low false negative rate with amavisd/SA. Essentially, we'd
> rather throw hardware at the problem than potentially reject legit mail.

Really? How much legit mail hits zen's rbl (hint, the number rhymes with "hero").


--
'You don't think you've had enough, do you?' he said. I KNOW WHEN I'VE
HAD ENOUGH. 'Everyone says that, though. I KNOW WHEN EVERYONE'S HAD
ENOUGH. --Moving Pictures