Tom Allison 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.
By the fact that you state each of three Postfix listeners writes its
own queue entry I take this to mean (in postfix terminology) that you
are actually running a post-queue content_filter and more specifically
you are running several of them that loop from one set of
ports/sockets/pipes back into postfix and into another content_filter.
No, we are running a (compound) pre-queue content filter with three
smtpd listeners and two content filter componentsthat does not
relinquish control of an smtp transaction until the last component of
the filter has given an OK to each step of the transaction. Each of
three Postfix listeners/qmgr writes a queue entry for its part of the
smtp data component of the transaction and deletes it when the next
listener/qmgr takes over. If the dspam daemon(for any reason) doesn't
happen to be up, the message is queued on disk by the penultimate
listener/qmgr until it does come up. I've initiated/instigated this by
stopping the dspam daemon and seen it happen. If it does happen, and the
client smtp conversation times out, and for some reason or another (an
example would be that the dkim-milter called by the last smtpd listener
would fail the message on account of a bad signature, another would be
that our MySQL service has failed), then the filter would become a
post-queue filter and Postfix would bounce the mail. When the dspam
daemon finally does come up and the last component is satisfied, then
the mail goes to the user as usual.
My definition of a pre-queue filter is one that does not relinquish an
smtp conversation with any client until the entire mail system,
including each component of the filter, has oked the transaction. That
is what we run. Nobody loses mail at any stage (even spam), unless
they're over quota as determined by maildrop.
An aside is, that this whole concept to my mind is utterly elegant and
practical. I can't think of a single other MTA that can run the two
content filters that we do in the way that we do - amavisd-new plays an
important part of this.
--Tonni
--
Tony Earnshaw
Email: [EMAIL PROTECTED]
