Philip Hazel wrote:
> On Mon, 20 May 2002, Hubbard, Matt wrote:
>
> > I was wondering, how much memory is taken up with each
> > "RCPT TO" during an incoming SMTP transaction?
>
> Depends on what you have configured in the way of checking.
Receiver_verify is on, there are some rewriting rules, and a single dbm
lookup on the address. There's a system filter in place which is the stock
filter with a few additions.
> > A daemon process would fork to receive a message and
> > then the memory usage would keep climbing until it
> > used all available memory (~450MB mem + swap) and was
> > killed by the kernel.
>
> > It turned out to be someone trying to send a message
> > to ~ 4500 recipients. I had thought there was a default
> > cap on the number of recipients, but it turned out I'd
> > misread the documentation getting max_rcpt and
> > recipients_max confused.
>
> Which release of Exim? Prior to Release 4.00, the code for handling
> expansions such as $header_xxx: did this kind of thing when there were
> large number of identically-named headers. That's why I asked
> what kind of checking you have enabled.
We're currently running Exim 3.35.
> This is the change that was made for 4.00:
>
> 8. When Exim was building a dynamic string for $header_xxx
> from a number of
> headers of the same name, or for $message_headers, it was
> using the dynamic
> string function which is designed for use with relatively
> short strings. If
> a pathological message had an enormous header, it chewed
> up memory at a
> ridiculous rate. The code has been rewritten so that it
> does not do this.
> With a 64K header string (there's a limit set at 64K) it
> now just gets one
> 64K buffer. Previously it used a large number of
> megabytes to build such a
> string, and some system filter processing ran machines
> into the ground on
> messages with huge headers.
Thankyou, this is a good explanation to where all that memory was going.
Cheers,
Matt.
