You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by James Butler <ja...@musicforhumans.com> on 2009/04/16 23:25:04 UTC

spamc: oops! message_dump

System: Fedora 10, Spamassassin 3.2.5, Perl 5.10.0

The following error is preceded by log entry:
spamc[PID]: skipped message, greater than max message size (512000 bytes)

Error: spamc[PID]: oops! message_dump of 8192 returned different
(there are as many of those errors as it takes to reach the file size of
the attachment, with the final error indicating a bytecount <8192 to
complete the sequence. i.e. if filesize = 517000 bytes, then I will get
63 entries with "8192" and the last one with "904".)

When: Message attachment > 512kb
(message body is simply the word "test")

I get the same log entries when testing with:
/usr/bin/spamc < BigFile.pdf
(where BigFile.pdf > 512000 bytes)

I do NOT get the entries when testing with size limit set in MTA:
/usr/bin/spamc -s 10240000 < BigFile.pdf

When sent as a normal message, the message gets delivered, but the
attachment is truncated at somewhere between 128kb-132kb, rendering it
useless.

1) Is spamc trying to check the >512kb attachment?
2) If so, why would spamc be trying to check the >512kb attachment?
3) How do I correct this?
4) What more can I provide to help troubleshoot this?

(I understand the error is related to spamc reading in one size and
writing out another. What I don't understand is why it is trying to
check the >512kb attachment after it claims to be skipping it.)

Thank you.

James


Re: spamc: oops! message_dump

Posted by James Butler <ja...@musicforhumans.com>.
James Butler wrote:
> System: Fedora 10, Spamassassin 3.2.5, Perl 5.10.0
>
> The following error is preceded by log entry:
> spamc[PID]: skipped message, greater than max message size (512000 bytes)
>
> Error: spamc[PID]: oops! message_dump of 8192 returned different
> (there are as many of those errors as it takes to reach the file size of
> the attachment, with the final error indicating a bytecount <8192 to
> complete the sequence. i.e. if filesize = 517000 bytes, then I will get
> 63 entries with "8192" and the last one with "904".)
>
> When: Message attachment > 512kb
> (message body is simply the word "test")
>
> I get the same log entries when testing with:
> /usr/bin/spamc < BigFile.pdf
> (where BigFile.pdf > 512000 bytes)
>
> I do NOT get the entries when testing with size limit set in MTA:
> /usr/bin/spamc -s 10240000 < BigFile.pdf
>
> When sent as a normal message, the message gets delivered, but the
> attachment is truncated at somewhere between 128kb-132kb, rendering it
> useless.
>
> 1) Is spamc trying to check the >512kb attachment?
> 2) If so, why would spamc be trying to check the >512kb attachment?
> 3) How do I correct this?
> 4) What more can I provide to help troubleshoot this?
>
> (I understand the error is related to spamc reading in one size and
> writing out another. What I don't understand is why it is trying to
> check the >512kb attachment after it claims to be skipping it.)
>
> Thank you.
>
> James
>
>   

Weirdly enough, I upgraded my Dovecot installation to v.1.2.rc2 and the
issue has gone away.

Postfix 2.5.5
Spamassassin 3.2.5 (under Perl 5.10.0)
ClamAV 0.95.1
Dovecot 1.2.rc2
Fedora 10

Installed Dovecot and ClamAV from source, and everything else using yum.

I'm using ClamAV plugin for Spamassassin:
 http://wiki.apache.org/spamassassin/ClamAVPlugin

I'm calling Spamassassin with:

/etc/postfix/main.cf:
 maillbox_command = /usr/bin/spamc -f -e /usr/local/libexec/dovecot/deliver

Postfix hands off to Spamassassin, which processes ALL mail (not just
attachments) through the ClamAV plugin before parsing the message (only)
for spam, and then hands the whole mess off to Dovecot for 'deliver' to
handle.

How simple is that?

Since ClamAV scans all mail, it might be too processor-intensive for
really large mail systems, but it is working great for our 120+ user
system with lots of spam coming in. If you're using Procmail or some
other preprocessor that can hand off to a pipe, then you could skip the
plugin and pipe messages over a certain size (i.e. >1024) to clamd, instead.

James