Corrupt mail files

[gaf-mNDKBlG2WHs at public.gmane.org (Jerry Feldman)]

What if it is a simple locking problem (eg race condition). You want to
make sure only 1 process is using the mbox at any one time. Both=20
procmail and Dovecot have locking schemes, but you need to make sure=20
they are both using the same locking method.  I had the same issue with=20
my system years ago where I was using MH to read the emails, but=20
procmail to deliver them. MH and Procmail had the capability of=20
selecting the same locking methods. With today's faster Internet and=20
higher volume of SPAMs, locking becomes even more an issue.

On 06/11/2009 04:06 PM, david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org wrote:
>> david-8uUts6sDVDvs2Lz0fTdYFQ at public.gmane.org wrote:
>>    =20
>>> The beginning of the file is a series of zeroes...
>>> ~# od -ch /var/mail/susan | head -10
>>> \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
>>> (StrongMail Ente
>>> rprise 3.2.3.3(3
>>> .00.320)); Thu,
>>> 11 Jun 2009 09:0
>>>      =20
>> It looks like not only is the start of the message overwritten with a
>> string of 16 nulls, but the remainder of the string appears to be a
>> Received line, with no sign of the From_ line (typically longer than 1=
6
>> bytes), so it looks like the message is truncated as well (or the From=
_
>> line was missing).
>>    =20
>
> Yes, a whole lot of the beginning of the got chopped off, much more tha=
n
> the handful of zeros.  I neglected to mention that.  Fortunately, I
> instituted frequent automatic backups of the mail files after the first=

> time.
>
>  =20
>>> - It could be that I'm using ext4, which might not have been a smart
>>> thing.
>>>      =20
>> This, or a hardware problem, seems most likely, given the mail tools a=
re
>> all fairly mature and reliable. You might want to test this out
>> temporarily by symlinking the spool to another file system or an NFS
>> mount.
>>    =20
>
> That's an excellent suggestion. My MythTV recording partitions are stil=
l
> ext3.  I'll look up tonight, but I assume there's a way to convert an e=
xt4
> partition to ext3.
>
>  =20
>> I've been seeing mention of ext4 problems in Ubuntu bug reports. 9.04 =
is
>> shaping up to be rather buggy.
>>    =20
>
> This is really the only problem I've seen.  I've had problems with dual=

> monitors, but I'm guessing that's xorg and not Ubuntu.
>
>  =20
>>> - It could be procmail, but that seems unlikely to me. .procmail does=
n't
>>> even have an explicit thing that writes to /var/mail/susan.
>>>      =20
>> If procmail is being used for local delivery, then it will implicitly
>> write to the spool. Check your postfix master.cf to see what local
>> delivery agent is being used.
>>    =20
>
> I'm relatively sure it's procmail, but I'll check.
>
>  =20
>> I'd hold off on the conversion until you've tracked down the source of=

>> your corruption.  Once that's behind you, consider switching to
>> Dovecot's deliver as your LDA, unless you have a lot of custom procmai=
l
>> filtering you don't want to convert to Seive.
>>    =20
>
> But what if using mbox is the problem?
>
> I have *A LOT* of procmail rules, but I'm willing to use something else=
 if
> it's better.  I'll google tonight, though "deliver" is hard to google o=
n.=20
> How is it better?
>
> Thanks.
>
> _______________________________________________
> Discuss mailing list
> Discuss-mNDKBlG2WHs at public.gmane.org
> http://lists.blu.org/mailman/listinfo/discuss
>
>  =20


--=20
Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846