[EMAIL PROTECTED] wrote:
> Dave Evans replied:
>
>>> It's greylisting without database. I'm rewriting it from Perl
>>> http://wiki.exim.org/DbLessGreyListing to C (using ${dlfunc )
>>> and intend to publish it there, but may be I should describe also
>>> the ${run variant? Because compiling for ${dlfunc looks not too trivial,
>>> and I enough well know only my OS (FreeBSD).
>
>>> How do you think, what is more expensive: one ${perl call
>>> or three ${run calls (find -exec mv, find -delete, touch)?
>> More expensive it terms of what?
>
> For me memory is more important because I run Exim on VPS/VDS with
> 64M RAM (not counting kernel) and 128M swap along with BIND,
> a web-server with Perl CGI and inetd (sshd, popa3d).
I thought that trick with one live-round in a revolver was called
*Russian* roulette.
Did it actually originate in Ukrainaya?
;-)
> But my question is more general/vague because I'll need
> to explain for other users who can have other priorities.
>
>> For CPU and elapsed run-time, ${run is almost certainly more expensive (three
>> forks, three "exec"s, plus the work to actually manipulate the files).
>> However, ${perl will be more expensive in terms of persistent memory usage.
>
> In both cases the processing (one ${perl or three ${run )
> happens at first RCPT, i.e. soon after beginning of some
> "handling incoming connection" Exim processes once per connection.
> The work to actually manipulate the files is the same in both cases.
> So, each ${perl call means Perl initialization and
> compilation of modules (IO::File, File::Path, Data::Dumper, Time::HiRes).
>
> I think that Perl initialized in the parent (daemon, listening) Exim process
> (by means of perl_at_start) cannot be used without initialization again
> in child (handling incoming connections) processes. Or am I wrong?
>
Not 'wrong' - and it might not at first seem to matter if your expected
message traffic load is low.
But low-traffic domains see a far higher amount of spam and malicious
connections *as a percentage* of connections than high traffic MTA do.
Ergo, the later you can run any resource-intensive process, the better
you can protect yourself against resource exhaustion.
To the extent you use all of the more efficient tools to shed bad-stuff
as early as possible, and run custom scripts only on the probable-good
traffic, you can cut the load by - just in our experience - 85% to 90%.
That said, acl_smtp_recpt is pretty early to have shed the majority of
potentially 'sheddable' message traffic w/o false-positives.
And greylisting, unfortunately, is a double-edged tool. Even with a fast
compiled-C binary, there is still fs I/O & storage to manage [1], so in
some circumstances and implementations, it can consume as much as it saves.
Personally, I wouldn't want the burden of greylisting *at all* on such
light resources (least RAM I've ever used for an MTA was 128M, most of
my old ones were 512M or 1GB, currently 1GB, 2GB, even 4GB).
But I know nothing about your server's workload... so 'best of luck'.
Bill
[1] a file system *is* a DB of sorts, so 'DB-less' is a relative term..
--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
