Thanks Curtis, I didn't think about what would happen if Sendmail tries to attach a new message to the bottom of the mbox at the exact same time that Dovecot goes to rewrite an attachment to the middle of the mbox. We are using fcntl() over NFS for both Sendmail and Dovecot. The mail server is the only NFS client that accesses the mail spools on the fileserver, so there's no chance of another NFS client causing issues. The only real reason we're using NFS is because the fileserver gets backed up on a regular basis but the mail server doesn't. The backups happen at night and this phenomena was happening in the middle of the day, so it's not a conflict with the backup software.
At first I thought the last four characters of every line were getting cut off, but it turns out that the characters I thought were missing were pushed to the next line. It appears that Dovecot is shifting the position of the CRLF by four characters
- not necessary a problem or related to the corruption issue.
I have a "before" and "after" document in base64 format that I wish I could post to the list, but the content of the decoded document is somewhat confidential (it's a vendor quote).
The total number of characters in the good document is 7,006 and the total number of characters in the corrupt document is 6,308. If it's a locking issue, I'd imagine that as Dovecot is writing the attachment, it would get interrupted and cut off, leaving only the first portion of the attachment written and the corrupted (missing) portion would be the tail end of the attachment.
In this case, comparing the two files visually character by character, the missing characters are a solid chunk right out of the middle. The beginning and end of the attachment are correct. Sort of odd...
-Brian
Curtis Maloney wrote:
Just to check:
it sounds like you're both using mbox format... have you verified that Dovecot, your LDA, and anything else accessing the mailboxes is using exactly the same locking, _in the same order_ ?
-- Curtis Maloney cmaloney@cardgate.net