Wietse Venema wrote: > Bob Proulx: > When the delivery fails and the message is too old, the bounce > daemon returns message FOO to the sender using the content of > defer/FOO as evidence, and if successful, deletes defer/FOO.
That is what I would expect too. My server network was fine but a remote network that I had messages to deliver to was down for a long overnight. I think maybe 18 hours. After it came up the messages were delivered as normal. I only find the status files behind because I went looking specifically because I have had them before after long deferred messages were delivered. I will usually delete them using an appropriate find command hitting only older expired files. I only see this once in a long time between. > So, on a normally working Postfix system, defer files go away as > expected. However, some Linux "security" policy may prevent Postfix > from working as expected (especially when they are "trained" under > "ideal" conditions when it never writes or removes defer files). Especially because I didn't say what system and version I was working with I think the SELinux security policies and other similar ones would be top on my mind too. I hadn't said because I am running Debian Stable Wheezy 7 and planning on upgrading to Jessie 8 in two weeks at the next Debian release. I hate going to the upstream and talking about older releases. Upstreams usually don't like that. I can understand. But Debian Stable is really useful to me as a good overall bundle. For the record I am not running SELinux or any other form of enhanced security layer. No immutable files. No ACLs. This is a very traditional system in the style of classic Unix systems. Currently 2.9.6 for another two weeks then upgrading to the next Debian Stable which will be 2.11.3. I have seen this happen to me with previous versions and it didn't seem to be sensitive to a specific version. > postsuper will remove the defer/FOO when removing message FOO. I assume you mean 'postsuper -d QUEUE_ID' does this. I have never had any issues with postsuper -d. If I could ask a second question related to postfix -r ALL that I have run into in the past... Postfix performs a DNS lookup and attempts a message delivery to the remote system. But sometimes I will know that stuff is happening with a remote site. The IP address of the remote system is changing for example. Or other things. But mail will be in the deferred queue because the old address is now unreachable. After the new DNS has propagated with the new address I assume that eventually Postfix will observe the new IP address. (Will it? I have never waited long enough to find out.) I am impatient. I want to force a delivery attempt to the new address without delay. I run 'postfix -r ALL' to force Postfix to requeue all of the messages right now. I assume this is a reasonable thing to do. Is it? You see one of the problems is that Postfix works so well that I never need to really know how all of the modules interact. It just works. > However, some Linux "security" policy may prevent Postfix from doing > that (see my prior comment about "training" under ideal conditions). > The postsuper command will complain if the remove() function reports > an error, but all bets are off once Selinux and its brethren start > to interfere. I can definitely see someone running SELinux rules and never having a deferred message and casting the rules in concrete. Then later having normal situations with network outages causing the message to be deferred and not handling those correctly. I am not a fan of SELinux and don't enable it on my systems. It is off by default in Debian. I realize it is enabled by default in some other systems. I am not stressed about it. I was just hoping to learn more about how things worked. If I have time I will try to set up a victim system for testing and see if I can reliably recreate the problem. Bob
