Bug 5838

are you sure it was spamassassin that lost the original copies of the mail,
replacing them with a zero-length file?  as far as I know, SA should be keeping
the original mail in RAM.

I have arround 100 identical messages in my spam folder. They all contain the 
following spam scoring table, and an attached original message which is zero 
bytes in size:

Content analysis details:   (6.7 points, 4.5 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 0.0 MISSING_MID            Missing Message-Id: header
 0.0 MISSING_DATE           Missing Date: header
-0.0 NO_RELAYS              Informational: message was not relayed via SMTP
 1.3 MISSING_HEADERS        Missing To: header
 2.2 TVD_SPACE_RATIO        BODY: TVD_SPACE_RATIO
 1.8 MISSING_SUBJECT        Missing Subject: header
 1.4 EMPTY_MESSAGE          Message appears to have no textual parts and no
                            Subject: text
-0.0 NO_RECEIVED            Informational: message has no Received headers
 0.0 NO_HEADERS_MESSAGE     Message appears to be missing most RFC-822 headers

-----
I have confirmed that the zero byte messages where as a result of external mail 
receved by sending myself some test messages via google mail, and observing the 
message arriving via the exim main log.

When I suspected that spamassassin might be to blame, I commented out the 
spamassassin lines in my .procmailrc file. After that further test mails (and 
spam) where delevered intact.

After that I noticed that the /tmp volume had filled up, and I suspected that 
it was related to the lost mail. I stopped the errant process, and deleted some 
files in /tmp to free up space, and then uncommented the spamassassin lines in 
my .procmailrc file. Further test mails where then deleverd OK, and spam 
filtering resumed working.

A possible factor is that I have configured spamassassin to check mails against 
Razor2 and to run Baysen scoring on messages. Is it possible that these run as 
subprocesses which fail when the temp disc space is exhusted?

 0.0 MISSING_MID            Missing Message-Id: header
 0.0 MISSING_DATE           Missing Date: header
-0.0 NO_RELAYS              Informational: message was not relayed via SMTP
 1.3 MISSING_HEADERS        Missing To: header

these all indicate that the "message" was 0 bytes when scanned.  It could be
procmail which is storing the message incorrectly in /tmp, resulting in the
zero-length input message... "strace -f" of the delivery process would traack
that down.


I don't think razor2/bayes are at fault btw.

> Also, as anyone can write files in /tmp there
> might be a risk that a local user could deliberately
> fill it up, in order to deny mail to other users,
> making this a potential security issue

If the system is set up in a way that allows any user to fill up the /tmp disk
isn't that the security issue?

Also, a more typical configuration would use spamc/spamd, and spamc will return
the original email if there is an error in spamd. Also, procmail will deliver
the unfiltered email if a filter process fails. So if spamassassin failed
because of running out of some system resource that should not cause this to
happen. As Justin points out it looks like procmail lost the mail before it sent
it to spamassassin.

This does not look to me like a spamassassin bug or a spamassassin security issue.

reassigning, too

Closing old bugs. I don't see how SpamAssassin would be responsible, since it never writes files, only prints STDOUT.