Michael McCallister:
> Hi,
>
> I like what I see in postscreen and am considering using some of the
> after 220 tests. The issue I have in doing so is that the only
> documented option for sharing postscreen_cache_map across servers is to
> use memcache and memcache over wan will introduce way too much latency
> from the looks of things. So I had an idea to accomplish this that I
> wanted to run by the list to help assess feasibility. I wrote a small
> perl script to read the btree postscreen_cache_map file, from there,
> here is what would happen:
>
> * The script would read new entries (only entries that passed the
> applicable after 220 tests) in on cron (maybe every other minute)
With Berkeley DB, postscreen requires exclusive access to the database.
Other usage is not supported. It may work, or it may not.
With LMDB, postscreen does support shared access, but you can't use
LMDB's built-in locking because that requires a world-writable file.
Postfix uses the locking protocol described in the lmdb_table(5) manpage.
> [distribute via DNS as a whitelist]
> Therefore, once a given client passed these after 220 tests on one
> postfix server, that IP would be in the whitelist within minutes -
> thereby removing the need to retest in the event the client retries on a
> different server.
As required by RFC 5321, a client MTA will not wait minutes before
trying to deliver to the next MX host. So your strategy won't help
as much as may hope.
> The exception would be if the client triggered some
> RBLs but not enough to hit postscreen_dnsbl_threshold - in this case,
> they would be retested again for after 220 tests if the client retried
> on a different server - which may not be so bad if they are listed in a RBL.
>
> General thoughts on this plan as a means to share postscreen cache over
> wan? Any problems that come to mind?
>
> Finally, any comments as to which after 220 tests are most effective
> with least false positives? I assume pipelining and non-smtp commands
> are most effective and have the least false positives compares to
> barenewline?
The after-220 tests are useful mainly because they require that the
SMTP client comes back later. It's a cheap greylist. Compared to
the before-220 pregreet test, the after-220 tests rarely catch a
spambot.
Wietse
