Curtis:
> Wietse:
> > Curtis:
> > > > This is safe only when the maildrop queue is "stopped", that is,
> > > >
> > > > 1) No submissions with the Postfix sendmail command while these
> > > > files are in the maildrop directory, otherwise mail will be
> > > > lost.
>
>
> I'm still trying to understand why mail would be lost. Since it would be
> impossible for the Postfix sendmail command to overwrite one of these files
> due to a filename conflict (we write the files using filenames that would
> never be used by Postfix), are you saying that the risk of mail loss comes
> because Postfix might use the same inode as one of these existing files?
> Doesn't postfix use some type of system call to retrieve an inode number
> that is not already in use?
File names and file permissions are Postfix-private implementation
details that are subject to change without prior notice. The name
of the file is used as the queue ID in logging, but the way that
the name or permissions are chosen is private.
I promise only that Postfix will read queue files that are created
by its own programs, even after files are moved to the maildrop
queue with "postsuper -r".
To inject Postfix queue files from elsewhere, the only safe way is
to do this in a quiescent queue: a queue that has no READ activity
and no WRITE activity.
In addition, think it is a mistake to inject mail from elsewhere
into the maildrop queue. My best bet is that you import files into
a quiescent hold queue (i.e. no other software is doing HOLD actions
in access maps etc.) and that you run "postsuper hold" until the
file names stop changing, then use "postsuper -r" to move the files
to the maildrop queue. This way you don't have to work around
collisions with sendmail/postdrop submissions, or about collisions
with pickup daemons that read files before they are complete.
I must be able to change the private internals or else it will be
impossible to improve Postfix. Software that depends on such
internals is not and will not be covered by my guarantee.
Wietse
