-00-00 "Dale Welch" <procmail(_at_)netw(_dot_)com> list.procmail
| I am running procmail 3.11pre7
| i keep getting: out memory as i tried to allocate 8xxxxxx bytes.
|
| I have over 100 meg available swap space so i have a difficult time
| understanding this.
Yes; this is known problem. And no, there is no development going on,
you have the latest version. Stephen is on a long vacacation...
Here is recollection from pm-tips.txt. Jari
.[phil] Philip Guenther <guenther(_at_)gac(_dot_)edu>
19.2 Procmail reads entire 90Mb message into memory
...last week my workstation grind to a halt when procmail received a
90Mb Email message (ran out of memory). The point is, such
message sizes are fine by me, as long as the system can handle
it. Is there any way I could make procmail only read the headers
of that message before scanning /etc/procmailrc/ ~/.procmailrc and
acting on it? That way it wouldn't need to read the entire
message into memory.
...Recently, I modified the sendmail.cf file to pipe messages
through procmail before sending them to deliver, so that I can
use system-wide procmail recipes for spam filtering. However,
yesterday we had a client send a 22 megabyte e-mail message (on
purpose, no less) and the system just came to its knees trying to
deliver it to the user's mailbox.
[phil] Btw, All the versions of /bin/mail (or mail.local) that
I've seen the source for either read the entire message into memory
first or use a temp file. Depending on where temp files are
located, a 90MB temp file may be just as bad as holding it in
memory.
And, No, there isn't. Hacking it in would not be non-trivial, mainly
because the current code runs with the assumption that the entire
message is there, and determining when it actually needs to see the
entire body (to do demand loading) would not be easy. Remember
that a condition on the size of the message, ala
:0
* > 10000000
/dev/null
would require the body to be read... It really is just better to
simply have sendmail enfore the limit. You should be doing it
there anyway to cut down on the totally trivial denial-of-service
attacks and because it's more efficient.
Procmail's memory allocation technique appears to non-optimal for
some OS/libc combos (FreeBSD has been reported). It's conceivable
that the configuration process could be enhanced to detect this
system limitation to use a strategy more efficient on them. Don't
hold your breath.