From: Wietse Venema (wietseporcupine.org)
Date: Fri Jul 01 2005 - 18:05:35 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Michael Tokarev:
[ Charset ISO-8859-1 unsupported, converting... ]
> 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... ;)

There are a few thing that the before-filter smtpd
can do.

Postfix already has code in the smtp client to avoid similar timing
problems; simply flush the stream to the before-queue filter when
it wasn't flushed in N seconds.

And with Cami's policy filter on mail volume I had to add support
to smtpd to count the bytes received, so it is no longer impossible
to have the before-filter smtpd watch the message size.

Fortunately the two scenarios described are somewhat incompatible
(sending a huuuge email one byte at a time).

        Wietse Wietse

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]