Prev: illegal address syntax
Next: recipient_delimiter and check_recipient_access
From: "Roderick A. Anderson" on 28 May 2010 15:11
Wietse Venema wrote:
> 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.

My bad. I was thinking how I keep the relay and transport maps up to
date on MX servers. The data is in a MSSQL table and each spool
rebuilds it's (hashed) maps when told to.


\\||/
Rod
--

From: lst_hoe02 on 28 May 2010 15:49
Zitat von Robert Schetterer <robert(a)schetterer.org>:

> 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

My only intention was to point out that the FP rate is sometimes a
"point of view". We also use RBLs but not Spamhaus any more and for
sure everyone should carefully choose before using one and monitor the
results.

Regards

Andreas

First  |  Prev  | 
Pages: 1 2 3
Prev: illegal address syntax
Next: recipient_delimiter and check_recipient_access