-3

First, I found Outbound mail queue lifetime standard and read https://www.rfc-editor.org/rfc/rfc5321#section-4.5.4

I'm having a hard time understanding why we should queue messages for so long. Doesn't that just confuse the end users when their message disappears into a queue for 4 or 5 or 7 days? Especially when they are expecting the message to get there in 3 minutes (or maybe even "instantly")?

I've tried to come up with "horror story" scenario where having a short queue lifetime could cause problems that end users would blame the SMTP server administrator for. I haven't been very successful. Here's the best I have:

  1. Someone mis-configures their mailserver's DNS with a TTL of 86400.
  2. An account on our server gets compromised and used to send spam. We get blacklisted on a DNSBL. (Would that even be seen as a temporary failure? Or is that seen as a permanent failure?)

It seems like anything I can come up with where a remote server is actually down, one of our users getting a bounce would be happy to blame the remote server admins instead of us. And, it seems like an end user might even appreciate getting a bounce instead of having their message "disappear" for a couple of days.

I have heard of greylisting, but my understanding is that is for a short time, maybe a max of 15 minutes of delay.

What would be the harm of having a queue lifetime of ~ 12 hours? Or even 6 hours? What good reasons are there for 4+ day queue lifetimes? Or is it just Cargo Cult system administration?

Community
  • 1
Azendale
  • 1,585

1 Answers1

3

First, following RFCs is never cargo cult system adminstration. Instead, it's just good practice.

That said, consider the following:

  • The practice is decades old. Yes, most mail servers can be brought up again much faster today then 20 years ago, but this is not guaranteed.
  • Not everyone can or want setup a proper "on call" team. Small companies or private operators exists, worktime laws needs to be taken into account and no, not everyone can or want to use some 3rd party provider doing this for them for various good reasons. The internet (and mail) is designed to work with small, independent systems.
  • Not all mail is human to human communication. Various automatic systems send mail and most can't reasonably deal with mail bounces and they shouldn't need to.

One could argue that it would be a good idea to reduce the time for the initial "message delayed" warning, but the 4-5 day period until a bounce is a time-tested good practice and shouldn't be changed.

Sven
  • 100,763