procmail by design pulls the entire message into virtual memory, which means
it can wreck the machine if you try and use it to pass gigantic messages.
Solutions divide into three categories that I can think of:
1) Ameliorate the problem --- buy loads of RAM, allocate huge tracts of VM
(i.e. swap), then raise the per-process memory allocation limits. Also go
for later versions of procmail, one thing they've tried to work on is a
category of bad interaction with certain malloc implementations that could
double memory requirements. None of these will solve your problem, they'll
just make it harder to hit. Some clever bastard decides to email a zip of
their entire hard drive as an attachment (backups are easy!) and you're
still gonna be hurting.
2) Fix the problem _Completely_ --- configure your MTA (sendmail, qmail,
Postfix, whatever) to discard messages greater than some reasonable size. I
recommend 64KB.
3) Ameliorate the problem a lot better than the choices in (1) --- if you were
to switch to Maildrop[1], then your message size limit would be determined
by available tmp file space, rather than by available VM, and with careful
filesystem layout this can be made equivalent to available local delivery
space, which means the problem goes away altogether. Maildrop is not
compatible with procmail; you'll have to rewrite your .procmailrc files to
a new language. Some people might even call that a defect:-).
-Bennett
[1] <URL:http://www.geocities.com/SiliconValley/Peaks/5799/maildrop.README.html>