> > > > 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, ...
Thanks for your input on this, Viktor. I should have specified in my posts that I was referring to how to safely do maildrop injections in the current implimentation of Postfix only. We realize that this will put us in the position of always having to review whether it's still safe with newer versions of Postfix. > > 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. For the moment, we are trying to avoid running postsuper -s, as it was suggested that it may be costly to do so. For those wondering why we can't just commit to only using the provided utilities to manipulate queue files, it's because we are giving individual users the ability to view messages that were placed in the hold queue and release them up to 30 days after the messages were originally placed there. While we could do this without moving the files out the hold queue, if we were to leave them there, the number of files in the one directory would cause us to take a performance hit all on it's own. On our test system, that only hosts a few busy domains, the number of queue files that we collected from the hold queue on our test system, after just a few weeks, is over 200,000. On the production systems that will filter for hundreds of domains per machine, I expect that we'll see that many messages being held in the hold queue in a single day. Multiply that times 30 days, and I think it would be trouble. I would be interested in seeing an option in Postfix to have the hold queue support multiple subdirectories where new subdirectories are created every X hours (or perhaps just daily) so that the number of files sitting in the queue do not get unmanagable. Until then, I think we are stuck with having to do some manual manipulation and being very careful that we understand the file management of the version of Postfix that we're running. I think, based on the comments we've received so far, that we're safe doing what we're doing on the current Postfix implimentation. (And again, I appreciate everyone's comments on this... I am not responding to everyone's comments to reduce the footprint I've already made on this list for an issue that is probably pretty unique to our situation.) Curtis > > -- > Viktor. > > Disclaimer: off-list followups get on-list replies or get ignored. > Please do not ignore the "Reply-To" header. > > To unsubscribe from the postfix-users list, visit > http://www.postfix.org/lists.html or click the link below: > <mailto:majord...@postfix.org?body=unsubscribe%20postfix-users> > > If my response solves your problem, the best way to thank me is to not > send an "it worked, thanks" follow-up. If you must respond, please put > "It worked, thanks" in the "Subject" so I can delete these quickly.
