Stefan Foerster:
> * Wietse Venema <wie...@porcupine.org>:
> > Stefan Foerster:
> > > It was followed by what seemed the normal delivery of a single mail:
> > >
> > > postfix-hub/smtpd[27112]: 1E0DE10003:
> > > client=edge.kvm.incertum.net[192.168.122.13]
> >
> > Right, this is a new message that has claimed the name 1E0DE10003,
> > Postfix must not append mail delivery errors to a file that contains
> > the errors for the deleted 1E0DE10003 message.
>
> I see.
>
> Indeed, 1E0DE10003 was from April 6th, 2006, around noon. The
> long term storage logs don't contain any sender/recipient/relay
> information, only anonymized data, but I can see that the deferral was
> the result of a connection timeout. Apart from that one message and a
> lot of hostname verification failures, the logs for that day don't
> show any signs of trouble (as per the DEBUG_README).
>
> I guess there's not really a viable way of discovering what happend
> that day, even with the logs, is there? Do I need to investigate this
> further?
I just looked at some code that I wrote in 1997 so.
Normally the queue manager deletes a defer logfile when it brings
a message into the active queue, and the bounce daemon deletes the
defer logfile after sending a "mail too old" bounce message.
If the defer file still exists without the message file, some of
the following happened:
- The queue file was deleted by hand without deleting the bounce/defer
logfile for that message. In this case, nothing is list since the
message would not be delivered.
- After restoring a mail queue from elsewhere, postsuper was renaming
files to make the 'queue id' match the message file inode number,
and was interrupted before it got to rename the defer file. In this
case nothing is lost, because at least one more mail delivery attempt
will be made.
- The message was renamed with "postsuper -r". Again, nothing lost
since there will be at last one more delivery attempt.
- It it's none of the above, someone lost mail.
Postfix is as careful about not losing mail, as it is about not
losing information about delivery errors. Losing a delivery error
is like losing the message itself - in both cases the recipient
does not receive the message, and the sender is not notified.
Wietse
