Can I do this:

  1. mv an email out of the Postfix hold queue to say, /tmp/foo/.

  2. Keep the email in /tmp/foo/ for an arbitrary period of time (ranging from seconds to days). During this period, Postfix server could even get bounced one or more times.

  3. And, then, at a time of my choosing, mv this email back from /tmp/foo/ to the Postfix hold queue... all without any queue ID clashes and resulting email overwrites?

According to this link, a Queue ID can be guaranteed to be unique only within 1-second intervals! I'm not sure if this is still true.

If I cannot do the above let's say, then can I do this instead:

  1. Generate a new 11-char Queue ID outside of Postfix (say, using mktemp) that is unique within the Postfix hold queue (at the time of its generation), and

  2. mv the message back from /tmp/foo/ to the Postfix hold queue with this new Queue ID?

Essentially, my requirement is to hold certain emails for arbitrary periods of time; only that, instead of holding them in the Postfix hold queue, hold them elsewhere.

Many thanks in advance.

  • Why do you need to hold messages outside postfix's mailqueue?
    – 84104
    Mar 7, 2012 at 0:48
  • I run some scripts on the messages in the hold queue. Messages with content that doesn't meet certain conditions are not to be sent out. I can't delete these messages to allow a sys admin to be later be able to intervene and reschedule their delivery. Now, to be able to distinguish between these messages and messages that could sit in the hold queue indefinitely for other reasons (not controlled by my scripts), I want to keep the former outside of the postfix hold queue. Otherwise, the admin will never know whether it's a postfix problem or a problem with my script.
    – Harry
    Mar 7, 2012 at 6:28

1 Answer 1


My understanding is Postfix Queue ID has two components, a millisecond time counter which repeats every second, and the message file's Inode number.

If so, the probability of time collisions is 1/1000 or 0.1% which I consider unreliable therefore uniqueness must be managed based on Inode number alone.

The Inode number is unique while the file exists in the Postfix queue file system therefore any moves must be within the same file system to preserve Inode number uniqueness. Movement to another file system frees the Inode in the Postix queue file system allowing Inode reuse. Most file systems don't define when Inodes are reused and some do so rapidly since reusing a cached free Inode is much faster than reading from backing storage.

Observing the move only within same file system constraint does guarantee the Queue ID will not be reused while the message file exists.

Whether or not Postfix will process the message when returned to the hold queue is unknown to me. My hope is another might know and between us you will have a complete answer.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .