Per von Zweigbergk asked:
We run an e-mail server for a few customers, and we’ve recently run into a bit of a conundrum.
We had a user who sent an e-mail to an incorrect e-mail address. The incorrectly specified domain unfortunately existed. It did not have MX records, and the A record of the domain went to a server which did not speak SMTP. Therefore, the e-mail server attempted delivery and did not succeed because no e-mail server was running.
For that reason, our e-mail server, entirely in accordance with the SMTP RFC, attempted re-delivery over the course of five days and finally gave up and sent a notice to the sender after 5 days of unsuccessful delivery.
Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days.
Therefore, the mail server in its default configuration, in this case has operated in accordance with the RFC, meaning that a user specifying the wrong e-mail address in this case would not receive notice of that except five days later.
At this point, my boss has asked whether it would be possible to reduce the give-up time to something shorter, say 1 day. His reasoning is that it is better that the user be notified earlier of non-delivery, and that the user may attempt re-delivery at a later date, or delivery through an alternate channel. It sounds like a reasonable thing to do, but in general I’m wary of performing any kind of configuration changes which contradict what’s in the RFC.
Is there any non-obvious reason why it would be a bad idea to reduce the give-up time to 24 hours, beyond just saying “the RFC says otherwise”?
Also, what do the bigger e-mail providers out there (the Googles, Microsofts, AOLs and Yahoos) do in this scenario?
Why shouldn’t you give up delivering email after one day? One good reason is weekends.
Email is not now, and never was, particularly reliable. In the early days of the Internet, the 1980s, it was entirely possible for email to take a couple of days just to reach its destination, what with some network links not being 24×7, over expensive long distance dialup calls (back then it cost per minute to call two towns away, nevermind the cost of a call from Sydney to Los Angeles), or even over amateur radio. As a result, it could take a while to deliver email, and the protocols had to cope with unreliable and part-time connections. They do this very well, but even then, mail could get delayed or lost.
Certainly today, email has an illusion of reliability, if only because the underlying transports are more reliable, and many uninformed people (like most of our users) have an expectation that it is reliable, but that expectation does not match reality. Without a significant change to email delivery protocols, which will probably never happen, email, like anything built by humans, will always be less than 100% perfect.
Sometimes, we sysadmins take advantage of that.
For instance, in an office where everyone is only there Monday-Friday, I can have an email outage lasting all weekend if necessary. Of course, it virtually never is necessary to be out that long, but I have had to have email down for over 24 hours in rare cases.
In such a case, if you give up after 24 hours, email sent Friday afternoon may not reach its recipient. The sender won’t find out until Monday morning, but if you had kept trying, the recipient would have had it by Monday morning.
Further, it’s very important to set user expectations appropriately. The fact that Internet email is not and never will be 100% reliable needs to be clearly understood, even as we like to think that it is.
The RFC says you should keep trying, precisely because things go wrong, and it’s intended that the mail be delivered eventually, if possible, but at some point you do have to give up. It might be OK to reduce this to three days. I’ve always thought five days was too long to wait for delivery for most messages on a 24×7 Internet.
As for your given mail server:
Postfix can notify senders when an email message has been delayed, but this feature is turned off by default. This warning should be sufficient to let your users know that something might have gone wrong, such as a mistyped email address, and will arrive much sooner than the 24 hours your boss has proposed.
To enable it, set
delayed_warning_time to the desired value in
Beginning with version 3.0, Postfix can also notify those same senders when delayed messages are finally delivered. This is also off by default, as it can result in a lot of notifications. But if you want this, enable
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.