Bug 5838 - Lost mail if /tmp (or $TMPDIR) fills up
Lost mail if /tmp (or $TMPDIR) fills up
Status: NEW
Product: Spamassassin
Classification: Unclassified
Component: Libraries
3.2.3
Other Linux
: P5 major
: Undefined
Assigned To: SpamAssassin Developer Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2008-02-27 03:54 UTC by David Pottage
Modified: 2010-01-27 03:16 UTC (History)
0 users



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description David Pottage 2008-02-27 03:54:37 UTC
I recently ran out of disc space in my /tmp partition on my Linux box, due to an
errant process filling it up.

I found that for each email I received, all I got was a completely blank message
with no headers or body. Spamassassin then scored the message as spam because it
had not body, subject or sender. All incoming messages where affected, and I
appear to have lost all information about the original messages (other than the
time received).

My mail setup receives mail via exim and fetchmail, then delvers it using
procmail which deliverers mail into maildir folders, (accessed using dovecot IMAP).

My .procmailrc contains a stanza at the top to pipe all mail through spamassassin

:0fw: spamassassin.lock
* < 256000
| spamassassin

-------------
I know that running out of disc space in /tmp is a bad thing, and that as a
system administrator I should prevent it from happening, but IMHO, loosing all
mail is a fairly bad outcome. 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.

I am running Ubuntu gutsy on an AMD-64 box. Using the standard distro versions
of all programs used to handle mail.
Comment 1 Justin Mason 2008-02-27 04:05:33 UTC
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.
Comment 2 David Pottage 2008-02-27 07:10:22 UTC
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?
Comment 3 Justin Mason 2008-02-27 07:26:53 UTC
 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.
Comment 4 Sidney Markowitz 2008-02-27 09:35:38 UTC
> 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.
Comment 5 Justin Mason 2010-01-27 03:16:14 UTC
reassigning, too