spamc "Maximum message size" appears to be ignored

I noticed that I have "Unlimited" set on this option, however I have had two messages come in now that both had attachments on them and were not fed through spamd. I can only assume this is due to them exceeding some arbitrary message size limit. Below is logs of one of these messages:

Sep 23 00:17:49 bigbertha postfix/smtpd[3661]: 9D8392AF8233: client=mail-qw0-f52.google.com[209.85.216.52]
Sep 23 00:17:49 bigbertha postfix/cleanup[3665]: 9D8392AF8233: message-id=
Sep 23 00:17:49 bigbertha postfix/cleanup[3665]: 9D8392AF8233: warning: header Subject: Fwd: Stress Management powerpoint from mail-qw0-f52.google.com[209.85.216.52]; from= to= proto=ESMTP helo=
Sep 23 00:17:49 bigbertha postfix/qmgr[2487]: 9D8392AF8233: from=, size=1229310, nrcpt=1 (queue active)
Sep 23 00:18:02 bigbertha postfix/local[3666]: 9D8392AF8233: to=, orig_to=, relay=local, delay=13, delays=0.49/0.01/0/12, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME)
Sep 23 00:18:02 bigbertha postfix/qmgr[2487]: 9D8392AF8233: removed

I am absolutely, 100% positively sure SpamAssassin mail filtering was on at the time this message was received.

I have tried setting spamc's message size limit to some random number and then grepping through /etc/ but the only place this number is set is in virtualmin/webmin configuration files:

webmin/virtual-server/config:spam_size=122223
webmin/virtual-server/procmail/128486841814862:| /usr/bin/spamc -s 122223
webmin/virtual-server/procmail/125548902711700:| /usr/bin/spamc -s 122223
webmin/virtual-server/procmail/12540070557673:| /usr/bin/spamc -s 122223
webmin/virtual-server/procmail/125693127819731:| /usr/bin/spamc -s 122223

Does procmail actually read these files out of those folders before processing the messages it receives or are these supposed to go somewhere else also?

Status: 
Active

Comments

Those files under /etc/webmin/virtual-server/procmail get included from /etc/procmailrc based on the domain a message is for, which is how the spamc message size limit gets applied.

How large were these messages that didn't get spam filtered? According to the spamc man page, it has hard upper limit of 256 MB.

For the message above, the powerpoint file that was attached was 870 KB in size. I understand it couldn't scan the powerpoint file however I would expect it to be able to scan the rest of the message's content. Not sure where to look though on how to troubleshoot this.

If you check the log file /var/log/procmail.log for those messages, do you see any errors related to spamassassin / spamc ?

Also, do those messages have any headers starting with X-Spam ? Checking for those is the best way to determine if a message was processed by spamd or not..

Yeah, I already checked the headers. That's what lead me to open this ticket as they contained no spamassassin messages =D Sorry I didn't include them before. Here's the procmail.log info, and the message's headers. No errors in either:

From Thu Sep 23 00:17:50 2010
Subject: Fwd: Stress Management powerpoint
Folder: /home/redacted/homes/allison/Maildir/new/1285219082.3667_0.b 1213630

Return-Path: <>
X-Original-To: redacted
Delivered-To: redacted
Received: from mail-qw0-f52.google.com (mail-qw0-f52.google.com [209.85.216.52]) by redacted (Postfix) with ESMTP id 9D8392AF8233 for ; Thu, 23 Sep 2010 00:17:49 -0500 (CDT)
Received: by qwf6 with SMTP id 6so1104908qwf.25 for ; Wed, 22 Sep 2010 22:17:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.89.205 with SMTP id f13mr555696vcm.41.1285219068601; Wed, 22 Sep 2010 22:17:48 -0700 (PDT)
Received: by 10.220.85.135 with HTTP; Wed, 22 Sep 2010 22:17:48 -0700 (PDT)
In-Reply-To: <1789897e0910271030s7dbefe4s9075f650cd9be184@mail.gmail.com>
References: <1789897e0910271030s7dbefe4s9075f650cd9be184@mail.gmail.com>
Date: Thu, 23 Sep 2010 01:17:48 -0400
Message-ID:
Subject: Fwd: Stress Management powerpoint
From: Khalila Fordham
To: redacted
Content-Type: multipart/mixed; boundary=0016364edb7a0aed8b0490e66296

--0016364edb7a0aed8b0490e66296
Content-Type: multipart/alternative; boundary=0016364edb7a0aed800490e66294

--0016364edb7a0aed800490e66294
Content-Type: text/plain; charset=ISO-8859-1

If you can't think of anything else to check on why it would be skipped, I will attempt to replicate it when I get home and make sure it wasn't just one of those weird flukes that happen sometimes =)

You might also want to check for lines before those procmail log entries related to spamc or spamassassin - sometimes errors might be logged slightly earlier in the mail deliver process.