Spamassasin over RBL, was Re: rblsmtpd -t?
Hello!
while not having much experience on this I'd like to comment.
On Wed, May 01, 2002 at 11:39:55PM -0400, cfm@maine.com wrote:
...
>
> Is the load from all those rblsmtpd process bigger than accepting the
> email | procmail | spamassassin? I've no idea how many times
> the typical spam tries to get through before it dies.
>
...
A receiving SMTP server has a number of maximum allowed SMTP sessions.
RBL-lookup can delay each out of these conections, which slows down
total processing time of an Email (if accepted), but as it is in-line
with the incoming mail-flow has a limited resource consumption on your
machine.
procmail/spamassasin process mails yes "inside" the server, I just
give you a made up example:
60 Mails incoming per Minute,
5 seconds average Spamassasin procesing time per Mail
=> 60-12 = 48 Mails per Minute piling up on your incoming mail
queue = 48 new Spamassasin processes per Minute consuming your
resources.
While RBL throttles Mail Flow (and spares Disk space) thus protecting
you in advance, Spamassasin puts the load on your side.
The rblsmtp binary in my ucspi-tcp_0.88-3_i386.deb package has 24284
Bytes, procmail 65500 (and one more library then rblsmtp libm).
Spamassasin needs perl - although spamd/spamc only needs it once.
Seems one has to weigh cost/benefit.
Of course, one could set up two servers - one which only manages the
incoming mail flow and queues it, and a spamfilter server behind,
which filters and does the final delivery. The first could be
low-profile, the second would be HIGH profile :-)
Best Regards,
Jorge-León
--
To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: