tom skrev:
We never do lose messages; our pre-queue filter includes first
amavisd-new
with both ClamAV and Sophos as content filter, then dspam as content
filter. Each of three Postfix listeners writes its own queue entry.
I'm taking the term "pre-queue" to be from postfixes point of view.
"pre-queue" would be similar to a milter or some other relay that
accepts the email from port 25 and passes it into postfix and friends.
Sigh. That is what our setup does.
sounds great but I still don't understand how you are doing this with a
queue unless amavisd-new has it's own queueing mechanism.
It does in fact, but that has nothing to do with the Postfix queuing,
amavisd-new's contribution is acting as a transparent proxy between two
postfix smtpd listeners. The first listener won't let go of the client
until amavisd-new has given a 2xx.
the problem I ran into is that mail was delivered to dspam without any
feedback to postfix on the delivery other than it was sent.
It was never send out of dspam to it's destination.
Insufficient logs from dspam to know anything more.
I don't know how you're running dspam. We're running it as a daemon
which is completely transparent to Postfix; the only contribution dspam
makes to the before-queue content filter (apart from doing its own
changes to the headers and DB stuff) is letting everything that Postfix
feeds it of headers and other stuff through without complaining, both
forward and backward, to the last smtpd listener. In our setup it's
important that the dspam daemon is sandwiched between two smtpd listeners.
The concern I have is if you don't accept delivery (thereby queueing the
email in postfix) before you send it to dspam then the any failures
dspam might have will either go unreported to anyone (no logs, which
I've experienced) or go reported to the email client (who is some other
mail server that couldn't care about your email system having an
issue).
That never happens in our setup, since it's the last smtpd listener that
gives the 2xx ok to the entire content filter, including amavisd-new and
the first listener (which will never give a 2xx to the client without
getting a 2xx from the last listener).
Considering the time it takes to filter spam/virii you can
build up quite the queue in the cloud.
Because we run amavisd-new with its temp files in RAM based tmpfs,virus
scan times including both ClamAV and Sophos are mostly below 0.3
seconds depending on the size of the message, and dspam with MySQL
writes and reads are mostly below 0.1 second. We're not a large volume
site, with absolutely max. 5000 inbound messages per day. People have
warned against using our setup on high volume sites ("what's high volume?")
--Tonni
--
Tony Earnshaw
Email: [EMAIL PROTECTED]
