Re: Bouncing an undeliverable message without waiting?
Jeroen Geilman wrote: Bob Proulx wrote: The mail queue has messages addressed to unreachable addresses. I know that if I do nothing that eventually they will expire normally ... Altering the status in-queue will be difficult, so you will have to devise a trick. You can try setting maximal_queue_lifetime to 0, and forcing a queue run. This will immediately bounce any messages already in the deferred queue, and not influence new mail unduly (since one presumes not a lot of messages will have this problem over a short window of time). Remember to set it back to normal after the queues are cleared! I think that is a good trick and experimenting with it I find that it did exactly what I wished to do and exactly answered my question. Within the constraints of this specialized system and other caveats. It worked for me and all of that. Thank you for that suggestion! However on the actual machine I executed Wietse's solution. It executed with more targeted precision. On this system I did reduce the maximal_queue_lifetime to a shorter value to avoid this in the future. Thanks! Bob
Re: Bouncing an undeliverable message without waiting?
Wietse Venema wrote: Bob Proulx: I have been trying to deduce if it is possible to force a message waiting in the mail queue with temporary errors (domain name resolution failures) to bounce right now instead of waiting for the timeout. It would be incorrect to force a message to bounce. Messages can have multiple recipients. It would be more correct to force-bounce a recipient. Sorry for using an imperfect description. I had an imperfect understanding of the problem. I appreciate the education on that point. Using Jeroen's suggestion to reduce the maximal_queue_lifetime to a small value and then flushing the queue had the desired effect due to Postfix itself understanding the difference in the above points. It was sufficient to handle my problem case. However your solution is more surgically precise and since some people here have a habit of making the same typo errors repeatedly it has the convenience of allowing me to target those very common typos specially and handle them in the future without further action on my part. To flag a destination or recipient as undeliverable: /etc/postfix/transport: typodomain.exampleerror:5.1.2 Bad destination system address That is a nice solution to the problem and works very well for me. Thank you for that suggestion. That is the way I went on the system. Flagging one recipient in a queue file as undeliverable requires a lot of code that currently does not exist: 1) a way for postsuper to mark as expired one recipient in the middle of a list of recipients, 2) a way to extract from the defer logfile the record that says why that recipient was not yet delivered for use in the non-delivery notification, and 3) a way to mark that defer logfile record as deleted so that the problem won't be reported again. Thanks for the expanded explanation of the problem. That does sound messy to implement and for only a small return on investment. I don't think it is worth it. And now that I have a better understanding of the problem and two recipes that solve the problem for me it isn't something I require. I knew there would be a method that would enable that operation. I just needed to learn it. Thanks! Bob
Re: Bouncing an undeliverable message without waiting?
On 2011-09-08 22:33, Bob Proulx wrote: I have been trying to deduce if it is possible to force a message waiting in the mail queue with temporary errors (domain name resolution failures) to bounce right now instead of waiting for the timeout. The mail queue has messages addressed to unreachable addresses. I know that if I do nothing that eventually they will expire normally and a delivery status notification will be produced back to the sender. But having investigated them in detail I know that those addresses can never be delivered. I would like them to bounce back to the sender now so that they are notified now of their undeliverability instead of waiting. The sender is a local user. Is it possible to do this such as through using the postsuper command? I know I can delete the messages. But can I cause them to bounce without waiting? I don't want to delete them but want the sender to get a normal bounce back so that they are notified normally that the addresses are undeliverable. I have been reading the man page documentation for postsuper in as much detail as I can muster and if it is in there I do not see it. But it seems like this is something that is very likely to be possible. If so I would love to be educated on how to do it. Altering the status in-queue will be difficult, so you will have to devise a trick. You can try setting maximal_queue_lifetime to 0, and forcing a queue run. This will immediately bounce any messages already in the deferred queue, and not influence new mail unduly (since one presumes not a lot of messages will have this problem over a short window of time). Remember to set it back to normal after the queues are cleared! -- J.
Re: Bouncing an undeliverable message without waiting?
Bob Proulx: I have been trying to deduce if it is possible to force a message waiting in the mail queue with temporary errors (domain name resolution failures) to bounce right now instead of waiting for the timeout. It would be incorrect to force a message to bounce. Messages can have multiple recipients. It would be more correct to force-bounce a recipient. To flag a destination or recipient as undeliverable: /etc/postfix/main.cf: transport_maps = hash:/etc/postfix/transport /etc/postfix/transport: typodomain.example error:5.1.2 Bad destination system address Flagging one recipient in a queue file as undeliverable requires a lot of code that currently does not exist: 1) a way for postsuper to mark as expired one recipient in the middle of a list of recipients, 2) a way to extract from the defer logfile the record that says why that recipient was not yet delivered for use in the non-delivery notification, and 3) a way to mark that defer logfile record as deleted so that the problem won't be reported again. Wietse
