By default, Postfix (like most mailservers) will keep trying to deliver mail for unconscionably long periods of time – 5 days. Most users do NOT expect mail that isn’t getting delivered to just sorta hang out for 5 days before they find out it didn’t go through – the typical scenario is that a mistyped email address (or a receiving mailserver that decides to SMTP 4xx you instead of SMTP 5xx you when it really doesn’t want that email, ever) means that three or four days later, the message still hasn’t gotten there, the user has no idea anything went wrong, and then there’s a giant kerfuffle “but I sent that to you days ago!”
If you want to reconfigure Postfix to something a little more in tune with modern sensibilities, add the following to /etc/postfix/main.cf near the top:
# if you can't deliver it in an hour - it can't be delivered! maximal_queue_lifetime = 1h maximal_backoff_time = 15m minimal_backoff_time = 5m queue_run_delay = 5m
Note that this will cause you problems if you need to deliver to someone who has a particularly aggressive graylisting setup in place that would require retries at or near a full hour later from the original bounce that it sends you. But that’s okay – greylisting is bad, and the remote admin should FEEL bad for doing it. (Alternately – adjust the numbers above as desired to 2h, 4h, whatever will allow you to pass the greylisting on the remote end. Ultimately, you’re the one who has to answer to your users about a balance between “knowing right away that the mail didn’t go through” vs “managing to survive dumb things the other mail admin may have done on his end”.)
2 thoughts on “Configuring retry duration in Postfix”
I received a “warning: bounce_queue_lifetime is larger than maximal_queue_lifetime – adjusting bounce_queue_lifetime”, so I setted up
bounce_queue_lifetime = 2h
maximal_queue_lifetime = 3h
queue_run_delay = 3m
#The minimal time between attempts to deliver a deferred message;(default: 300s)
# minimal_backoff_time = 6m
#The maximal time between attempts to deliver a deferred message.(default: 4000$
maximal_backoff_time = 10m
Thank You for Your suggestion!
Why is greylisting bad? I’d like to know more. So far, I have only seen it suggested as something I want to do, or as a “feature” in “turn-key” (ish) setups. I have stood up an email server using Modoboa and therefore I am pretty sure I have postgrey running. What should I be doing differently, and why?
skimable: there maybe some gushing toward the end
I might be kind of “new” at this. But I’m not dumb. Just inexperienced at running my own email server. I’ve been doing IT since the 90’s, though largely in application support roles for in-house developed applications. And I’ve done lots corporate IT from first through third tier, both internal and externally facing. At home, I’ve been using strictly Linux on my computers since 2004.
I came to know of you, and this blog (via link) through Jupiter Broadcasting’s Tech Snap podcast, which I love. In fact, I’ve been a fan of Jupiter Broadcasting for a few years since I first stumbled on one of their shows (alas, oh LAS…), and have been a regular and happy listener of multiple shows on JB. I’m really super happy for them in their transition to being a part of Linux Academy. The content really deserves the sort of unbiased support that a company like Linux Academy can offer. LA’s interests seem to be aligned with promoting the health of the Linux community as a whole, and don’t seem to support any reasons to pick favorites. And, of course, my esteem for Linux Academy was already pretty high. So “giving back” in this way just shoots it through the roof. My general emotional feeling toward Linux Academy is gratitude. I appreciate LA, JB, and all the people (like you!) so much, on more levels than you really probably care for me to go on about. And now I know about your blog here, which is great! So Thanks!
Back to mail servers:
I am using Modoboa as as a starting point, to get me up and running. But I want to learn the wise ways. My goal is to pick apart the pieces and understand them better over time. Then I can have confidence in my understanding of how it works and how it is configured, and of course “make it my own”. For now, I have it running inside of an LXD container on a Digital Ocean VPS. The droplet is configured via Ansible (which I am also learning), but the mail server I deployed using their installer-scripts within the container “vm”. Ultimately I’d like to get to the point where I can (re)deploy the whole thing with Ansible, creating any LXD and/or Docker-style containers needed to isolate the individual service components where it makes sense. And I’d like to understand not just how the components interact, but how to segregate out each component’s configuration and state so that I can do proper backups that I am confident in, and have the ability to scale the server if and when needed. Obviously, I am using this project as a means of sharpening and expanding my skills in a few different areas at once. And I also seriously intend to offer hosted email, as well as other IT services as an independent consultant to some of the businesses around town where I live (“in the boonies”, as they say). Oh… and I am also going to set up a backup email server for this project in the near future.
Understanding a bit more about where I’m coming from and my goals with this, do you have any suggestions or guidance to offer? Or general advice? Are there some particular areas I should focus on first? Do you know of any good resources online, such as blogs I should be following, articles I should be reading, or online communities I should be engaging? Any suggestions you have along these lines would be greatly appreciated. Feel free to share more general thoughts about starting an independent IT consultancy if you have advice you’d like to share in that regard as well. I don’t mean to ask too much. A good tip or reference would be received gratefully. But I respect your time and energy, and understand if you don’t have a whole lot of “extra cycles” to spend on a reply to a comment on a 6yr old blog post.
Thank you so much, Jim. I appreciate your time. And I appreciate all your efforts to share your experience with others, here on your blog as well as your work with JB. Be well, my friend.