From: Andy Dills on
On Thu, 27 May 2010, Wietse Venema wrote:

> 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.

That seems worth investigating, thank you. I appreciate how you're
evolving postfix to address this (and the improvements to handle content
filtering pre-queue, we will be moving to that once amavisd-new is more
mature with regards to that).

> > 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.

That makes sense. I was just looking for a way to provide some "shared
knowledge" among the servers in the cluster.

Thanks,
Andy

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

From: lst_hoe02 on
Zitat von LuKreme <kremels(a)kreme.com>:

> 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").

Hm. The infamous dispute with the austrian NIC comes to mind...
We have throw out all spamhaus.org related blacklists since then.

Regards

Andreas

From: "Roderick A. Anderson" on
Andy Dills wrote:
> On Thu, 27 May 2010, Wietse Venema wrote:
>
>> 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.
>
> That seems worth investigating, thank you. I appreciate how you're
> evolving postfix to address this (and the improvements to handle content
> filtering pre-queue, we will be moving to that once amavisd-new is more
> mature with regards to that).
>
>>> 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.
>
> That makes sense. I was just looking for a way to provide some "shared
> knowledge" among the servers in the cluster.

Run a cron job that checks for changes in the RDBMS and then rebuilds
the postscreen_cache_map "files" if needed.


\\||/
Rod
--
>
> Thanks,
> Andy
>
> ---
> Andy Dills
> Xecunet, Inc.
> www.xecu.net
> 301-682-9972
> ---

From: Wietse Venema on
Roderick A. Anderson:
> >>> 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.
> >
> > That makes sense. I was just looking for a way to provide some "shared
> > knowledge" among the servers in the cluster.
>
> Run a cron job that checks for changes in the RDBMS and then rebuilds
> the postscreen_cache_map "files" if needed.

That implies shared access to the postscreen_cache_map _file_,
and is not supported.

Wietse

From: Robert Schetterer on
Am 28.05.2010 14:13, schrieb lst_hoe02(a)kwsoft.de:
> Zitat von LuKreme <kremels(a)kreme.com>:
>
>> 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").
>
> Hm. The infamous dispute with the austrian NIC comes to mind...
> We have throw out all spamhaus.org related blacklists since then.
>
> Regards

whatever if you do selective rbl checks, you will nearly never get into
trouble, after all there is a lot checks which you can do before rbls
so not much leaves to spamhouse, not using them in any way is not really
clever, if you like a rbl advanced configurable modus try policy-weight
which you can also use selective and/or with whitelisting etc

by the way its up to what your using, but i would miss rbls
in my antispam chain

>
> Andreas
>
>
>


--
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria