Victor Duchovni:
> On Wed, May 27, 2009 at 02:25:24PM -0400, Wietse Venema wrote:
>
> > Victor Duchovni:
> > > the same time. If "postsuper" (which runs durin "reload") is to be
> > > allowed to race against your code, your mode 0700 file names have to
> > > match the usual Postfix hex file names:
> > >
> > > <usec-5-hex-digits><inode-hex-digits>
> > >
> > > this is an undocumented interface, so you have to be willing to review
> > > any Postfix release for compatibility prior to deployment.
> >
> > Sorry, the RELEASE_NOTES don't discuss undocumented behavior.
> >
>
> By "review", I meant "read the code"... Postfix is open-source
> software, if they are willing to take on the burden of supporting local
> "customization" (their injection system can be viewed as a customization),
> and the reasons to do so are sufficiently compelling, they are free to
> customize Postfix, but then they have to "port" their custom feature to
> new releases, which requires going beyond the RELEASE_NOTES, ...
>
> Yes, code that knows the detailed format of queue files is outside the
> normal contract.
>
> They could reduce the likelihood of breakage, by writing to the maildrop
> directory of a dormant queue in the same file-system, and running
> "postsuper -s" to rename the files added to the dormant queue, and then
> rename(2) the resulting files into the non-dormant queue for pickup(8)
> processing. The cost is additional fork/exec of postsuper for each batch
> of injected messages.
That breaks when files are moved across file system boundaries.
The documented safe way to "restore" queue files is to stop Postfix,
dump files into the maildrop directory, and run "postsuper" until
the names stop changing.
Without stopping Postfix, importing files safely could be done with
a new "postdrop" command-line option. This would be a privileged
option, since real queue files contain records that users are not
allowed to provide.
Wietse
