Re: Corrupted messages...

[Chuck Yerkes]

Quoting Dan Nelson (address@hidden):
> In the last episode (Jun 09), Chuck Yerkes said:
> > We're testing out spamass (2.54 right now) with a group of users. 
> > We're starting to see problems and I've turned logging way up to try
> > to guess where it's coming from.
> > 
> > We're marking up Subjects ("Subject: SPAM: orig subj here") and
> > including the report in the body of the message.  It's done the MIME
> > stuff just fine so far.
> > 
> > The first symptom was that spams came through with no subject at all
> > and the spam was reported within as normal.
> > 
> > Then we got reports that the attachments within were 'corrupted.'
...
> I have not seen this particular corruption myself.  Sendmail should do
> a good job of locking the mail spool files to prevent multiple writes,
> and even if it fails, what you usually wil end up seeing is part of
> message A, then the entirety of message B after it.  I don't think
> you'd see interleaving like you have.

Sorry, there is ZERO local delivery on this machine.  Mail for certain
(test) users is directed to it, scanned and passed on (to an icky mail
system that's proprietary and difficult to look at headers with).

> > So memory is corrupted somewhere.  spamd?  spamass-milter?
> > The milter code from sendmail?  I dunno.
> 
> Most likely the problem is either spamass-milter or libmilter.  both
> spamd and sendmail should fork new copies of themselves for each
> message, so they shouldn't cause parts of one message to end up in
> another one.
...
> If you can stand it, try running spamass-milter with watchmalloc, using
> either MALLOC_DEBUG=WATCH (slow) or MALLOC_DEBUG=RW (very slow), which
> should cause a coredump on bad memory accesses.  I've run
> spamass-milter under dmalloc and valgrind on my systems with no
> problems, so if there is a problem it may be OS-dependant.

Speed isn't the problem as much as watching logs of maybe 500 msgs/hr.

This is a build option for gcc?