Description of problem:

The amount of spam has increased to the point where the mail logs
fill up the disk.  Here's why:

Spam comes into the box and postfix discovers
that there's no local mailbox, so it generates a bounce message.
The spammer is not receiving mail at the return address, but
does not issue a 5xx error.  Or perhaps the mx doesn't exist,
or whatever.  So the bounce sits in the outbound queue and postfix
periodically tries to deliver it until eventually it times out.
Meanwhile, each delivery attempt generates log messages.  The
maillog gets really big, and can easily fill the partition.
At which point mail, logging, and other things are not likely to
work.

The solution is to ship /etc/postfix/main.cf with the
local_recipient_maps line uncommented.  This causes postfix
to reject incoming mail for which there is no local recipient
with a 5xx SMTP message, and the bounce then becomes the sender's
problem.

This also means that /etc/postfix/master.cf must be shipped with
the smtpd deamon _not_ chrooted.  While this opens up other
potential security holes, it closes an actual denial of service
that is likely, if not inevitable given the incrasing amount of
spam.  (I had this problem on a box supporting 6 users, with
a 4GB /var partition and 3 times the number of old maillogs
than are kept on a stock system.)  The smtpd deamon could go
back to being chrooted if, for example, authentication related
to the mail system was kept in a LDAP database.  But that's
a major change.

I forget whether old maillogs are compressed on a stock redhat
install.  Compressing the logs will help, but will really only
delay the inevitable.  Not to mention, lots of bounces plogging
up the outbound mail queue and generating lots of log entries
makes administering a mail system grody.

You may wish to consider reclassifying the severity of this
problem to "security" as large parts of the system break under
conditions controlled by outside entities.