SUMMARY - Corrupt Mailfile

Carl E. Sloan (ces@rdr.com)
Mon, 26 Jan 1998 21:45:03 -0500

The following outlines my scenario, the error message, my questions,
the answers I received, my actions to correct and last but not least,
the credits:

Scenario:
I had one of my users contact me today with a mailfile problem
on our Sun Sparcstation 5 running Solaris 2.5.

Now, I have saved the mailfile off to a different directory so
that the email will flow once again and I can attempt to
recover the good messages contained within.

I can "vi" the mailfile and see the contents (headers, messages,
etc.).

Error Message:
The user was having trouble pulling email to the desktop
application via PoP. Upon inspection of the users' mailfile
(opening the mailfile with the "mail -f" command), I got the
following Error Message:

**********************************************************************
<path to mailx command>: Your mailfile was found to be corrupted
(Content-length mismatch).
Message #0 may be truncated,
with another message concatenated to it.

**********************************************************************

My question(s) is/are:

Question:
1) Are the good messages in the mailfile salvageable?

Answer:
1) Sometimes mailboxes, which are considered corrupted by some
tools can be safely read by others. Try to read email by mailx,
pine, elm, dtmail. If this does not help, you'll have to edit
your mailbox by hand.

2) Since a mailbox is a text file, assuming that it was not
completely corrupted, you can always retrieve the body of the
messages and save them in some form. For example, send it to
yourself. If the mailbox has attachments, you can find stand
alone converters for uudecode, MIME, binhex.

Question:
2) If so, What if any, is/are the proper tool(s) to use to edit a
mailfile under Solaris 2.5?

Answer:
1) You can use "vi" or the editor of choice to work on
mailfiles.

Question:
3) What do the individual email messages start and end with?

Answer:
1) Each message consists of a header (first line - From, last
line - empty. For exact format you can look at RFC-822). You
can copy a header (or some lines of it, which do not seem to be
correct in a corrupted message) and edit it to put correct
information: sender, date and subject. Recently I fixed a
couple of mailboxes this way.

Question:
4) Are there any sendmail configuration parameters that could filter
out "bad email messages" (by bad, I mean ones that could cause
this problem)?

Answer:
1) It is probably NOT the case that a "bad" message was
received. It was more likely the case that two programs were
writing to the mailfile at the same time. Mbox format mailboxes
are known for this problem where all of the programs that could
write to them do not use the same sort of locking on the mailbox
(or the locking mechanism is buggy - see lockf/flock over NFS
for example).

2) One of the possible reasons for mailfile corruption -
simultaneous access by different mail tools, which do not
understand a lock mechanism of each other. Thus I was watching
how mailtool corrupted my mailbox while I was reading it using
dtmail. I saved a copy of my mailbox before doing that.

3) Not that I'm aware of, but I'm sure someone could write one.
I expect what happened was some mailer software out there
didn't handle a 'from ' where the 'from' was part of the message
properly and there is a 'from ' somewhere in the body of the
message. The other possibility is that the Content-Length line
actually didn't match the length of the body of the message, but
the Content-Length line is actually usually ignored so you
really shouldn't have to worry about that one much.

Actions:
The following were done as "super-user" <root>:
1) I made a copy of the mailfile to a "temporary" area to be
worked on.
2) I used "vi" to edit the mailfile.
3) The offending message was at the beginning of the file, so
I deleted all text from the beginning of the file to the first
instance (but not including) of "From"
4) I tested reading the mailfile using the "mail -f <mailfile>"
command.
5) The mailfile was readable once again so I then placed it back
into the "/var/mail" directory, making sure that the proper
permissions were set:
owner = <username> (chown <mailfile> <username>)
group = mail (chgrp mail <mailfile>)
permission = 660 (chmod 660 <mailfile>)
6) Notified user that mailfile was fixed and the user retrieved
the email successfully!

Credits:
Noli A.
Eugene K.
Thomas G.
Charlie M.
Brian W.
Stephen F.

Thank you all for the prompt responses. I was able to edit the user's
mailfile, deleting the offending message and put the mailfile back in
place for it's retrieval.

The timely responses allowed me to correct the problem during a
critical time and become a "hero" to my users. I did pass on the credit
of those who helped me. Many thanks! I am in debt to you all.

I realize that this summary does not "summarize" too well but given
the subject and the corresponding solutions, I felt that most of the
text should be used.

Thanks again!

-- Carl
======================
Carl E. Sloan
Email: ces@rdr.com
Phone: (703) 591-8713
Fax: (703) 273-8170
======================