From: Michael Tokarev (no email)
Date: Fri Jul 01 2005 - 18:20:23 EDT
When there's a pre-queue content filter configured in
Postfix smtpd (smtpd_proxy_filter), and that filter is
catching DATA command to perform content checks, saving
the incoming message in a temp file, this filter, at
least in current architecture, is responsible to enforce
(initial) message_size_limit by its own.
I've seen people used amavis (different variations of it)
as a pre-queue content filter to reject spam/viruses right
at SMTP stage (which is good thing to do, but amavis
together with spamassassin and clamav are probably too
heavy for that), and has biten by this message size
limit checking (or lack thereof).
Note also that such a content filter, when used to submit
mail to another smtpd, and when just proxying the whole
transaction up to the DATA command, should be configured
with more parameters. In particular, receiving smtpd
should have much larger, I'd say indefinite timeout
value (the sending side may be transmitting message
byte at a time, slow, this will not trigger timeout
on the front-end smtpd, but second smtpd will see
huge timeout after RCPT (or DATA) command. (Ofcourse
such a weird case is just that - weird, but it's still
something to think about).
Following this, there are several corner cases possible
when one of the smtpds disconnected prematurely. But
it looks like the most problematic case which may happen
here is the mail sent more than once (probably very large
number of times) - when the filtering proxy sends everything
to the second smtpd and only after that replies to the
frontend smtpd which has already given up at that time
(which is probably the most common scenario for large
emails which takes significant time to process). In
such a cases, the sending side (after receiving 4xx error)
will retry, possible causing the same behaviour.
This is just a reminder: writing good smtpd_proxy_filter
isn't really trivial... ;)
/mjt
|
|
|