> Say an exim system panics and reboots. Will any mail be lost or damaged?
My assumption has always been that the answer to such questions is "no".
I kind of take it for granted that mail systems "fail safe", i.e. err on the
side of duplicating, rather than loosing email.
The author has written "well used" code before. Though his first MTA, I think
I have alerted him to most of the common concerns ....
Nothing I have seen in the code leads me to assume anything to the contrary.
What in particular lead you to believe from your perusal of the code that such
problems existed ?
> Say an exim system suffers a power outage---the disk doesn't even get
> synced. Will any mail be lost or damaged?
Same as above [[ You mean you trust a system to sync discs ? :-)) ]]
> These events will happen.
Sure.
> They will happen frequently.
Hmmm -- matter of opinion / definition.
> What are you going to say to a user after exim destroys an important piece
> of mail that it accepted responsibility for delivering?
What leads you to believe I'll need to ?
I guess it boils down to probabilities.
Our exim spools are mirrored, but it's possible that both discs could die
before we could fix things up.
Both discs are in the same room, so if there was a fire / flood / ... we could
loose email (only yesterday, our backup mail server decided to destroy totally
one of its ADvFS domains -- we had to restore from tape. First instance of
such a problem. Fortunately that machine had no email at the time, and it was
in a different domain, but ...)
We do what we can to protect things, but one cannot guarentee things won't get
lost.
(I assume) exim does its bit to keep the chance to a minimum.
> There's an extensive literature on crashproof databases. The idea is
> that you start from certain atomic operations---for a typical UNIX
> filesystem, for example, link() is atomic---and you build higher-level
> atomic operations.
Sure -- I've seen nothing to lead me to believe that exim does otherwise.
> Basic example: replacing the contents of a file. If you simply open the
> file O_WRONLY | O_TRUNC and write the new contents, what happens if the
> system goes down in the middle? You get a truncated file. In fact,
> appending isn't atomic, so you could end up with a truncated file
> followed by some empty space.
Sure -- having mailbox files, rather than mailbox directories can lead to
*EXTRA* partial deliveries of email.
However, it is my belief that exim will re-deliver the message, and that the
MUA we use can cope with such corrupt mailbox files.
The fact is that most MUAs expect mailbox files, so that's the norm for exim.
You can make exim deliver to mailbox directories if you so wish.
> Of course. I have no intention of quietly criticizing exim behind your
> back. If I see any problems with exim, I'll let you know.
Ta -- I took your comment "It seems to me, from a quick glance through the
code, that messages can be lost, misdirected, or corrupted" to mean that you
had found some problems of which the author had not been notified.
