-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,505
  • 2
  • 11
  • 14
  • server's breaking on a Friday night, and the admin not getting to work to start fixing it until Monday morning, and then needing a day or 2 to fix it. Then when it is all fixed all the queued mail is delivered successfully. Then there is an extra day or so as a safety buffer. – BeowulfNode42 Nov 04 '16 at 01:55
  • Also, most mail servers send a report back to the user to say an email has been delayed, starting at about the 4 hour point. – BeowulfNode42 Nov 04 '16 at 01:55
  • @BeowulfNode42 But if the Web server breaks, we're fine with the browser giving up in a minute or two at the most. :) Shouldn't someone be on call for stuff like this? How would it take them two days to fix something that critical? And, why not just bounce at the 4 hour point? – Azendale Nov 04 '16 at 01:59
  • @Azendale What if the outage is with the internet circuit or power to the building? That's completely out of the email administrator's control, and no amount of on-call response will help. Your question seems mostly like a rant rather than being something constructive. – EEAA Nov 04 '16 at 02:39
  • @Azendale different organisations have different amounts of resources to allocate to IT, with no amount of pleading from IT will have management spend more money. Also, there are these things called floods, power/internet outages, etc that the organisation may not have a big enough budget for their business continuity plan to cover those events so their email server is down for the duration of the event. Meanwhile the sender should receive a message saying their email has not been delivered yet but it will keep trying. Then another if it gives up. – BeowulfNode42 Nov 04 '16 at 05:58

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
  • 97,248
  • 13
  • 177
  • 225