Bill Houle <bhoule(_at_)sandiegoca(_dot_)ncr(_dot_)com> writes:
I notice in my procmail verbose log the following 'transaction':
procmail: [10239] Sat Jan 9 08:49:02 1999
procmail: Out of memory
buffer 0: "formail"
buffer 1: " formail -A "X-Check: List""
Folder: **Bounced** 5744
procmail: Notified comsat: "bhoule@:**Bounced**"
If I act quick enough when this happens, I can look in spool/mqueue
and find a message with a gazillion addresses in the To: line. So it
seems that formail is having trouble adding my X-Check header to an
already large set of headers.
No, it's procmail that's unable to allocate enough memory. The buffer
dumps indicate that procmail was unable to get enough memory somewhere
between parsing the action line and reaching the next recipe -- buffer
0 would not contain the string "formail" if procmail had gotten to
another recipe or variable assignment. What's weird is that the
message is so small (only 5744 bytes according to procmail). Do you
only see this error on this recipe, or at random places in your
.procmailrc? If the later, then I would guess that your mailserver is
running out of memory for some other reason and that procmail happens
to be an innocent bystander. If the former, then, well, I'm not sure.
The message is never delivered to me. Is there anything I can do so
that procmail/formail will act as if it was never there so the
incoming dumps into my inbox rather than returning an error to the
mailer? This "**Bounced**" business is not a very helpful action.
Giving procmail the -t flag will cause fatal internal errors that are
normally returned as permanent errors to be returned as temporary
failures instead. Otherwise there's no way to control that. (Setting
EXITCODE won't work because procmail needs to malloc memory to handle
TRAP and EXITCODE, and it'll refuse to try that when it was malloc that
caused the exit.)
Philip Guenther