email - delivery retry timeouts

Aaron aaron at
Thu Mar 29 17:24:04 PST 2001

After Network Operations stops laughing ;), you can turn your browser
to RFC 1123, which specifies the MUSTs and SHOULDs for sending
electronic mail:

In a typical system, the program that composes a message has some
method for requesting immediate attention for a new piece of outgoing
mail, while mail that cannot be transmitted immediately MUST be queued
and periodically retried by the sender. A mail queue entry will
include not only the message itself but also the envelope information.

The sender MUST delay retrying a particular destination after one
attempt has failed. In general, the retry interval SHOULD be at least
30 minutes; however, more sophisticated and variable strategies will
be beneficial when the sender-SMTP can determine the reason for non-

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. The
parameters to the retry algorithm MUST be configurable.

A sender SHOULD keep a list of hosts it cannot reach and corresponding
timeouts, rather than just retrying queued mail items.

I think you'll be okay without power for 8 hours. If you don't feel
comfortable with that, the ttl for the zone is one hour, so
you should have plenty of time to add an additional MX record.


On 01.03.29 at 14:36, R. David Whitlock wrote:

# I'm not sure about the timeouts on the mailers, because I'm assuming that
# there's not really any set standard, but you might have one problem
# already: If you haven't already turned down the TTL for your zonefile to
# some more frequent value, you may not have time to propogate a new MX
# record before the power cuts out...
# Of course, you could start with one broad assumption that might help:
# the most important mailer that needs to know the change is the UW's, so if
# you make a change and then nicely ask the kind netops folk to manually do
# a zone transfer, the UW's nameservers and thus mailers will have the
# correct info asap.
# -D
# "What you hear isn't necessarily what was said,
# what you read isn't necessarily what was written."
# -Dostoevsky
# On Thu, 29 Mar 2001, Mike wrote:
# > This is only related to Linux in that I've got a Linux server running
# > sendmail which will be out of service for about 1 day. The rest of my
# > question is email specific. If this makes you unhappy, stop reading now.
# >
# > Tomorrow the power is going to be out at my apartment for about 8 hours
# > (sh!t, due to construction across the street). Since I receive email via
# > my "server" at home, the server will be unresponsive for that amount of
# > time.
# >
# > I've only got one MX for my domain. My question is whether I should:
# >
# > A) try to put together a secondary (caching) MX for tomorrow's
# > outage?
# > OR
# > B) will other email servers cache messages for me (as in get a bounce and
# > wait to retry delivery) and redeliver them when I'm back online?
# >
# > I'm not sure which RFCs to read about this (if there is in fact a standard
# > for redelivery timeouts), and finding out which one might be a painstaking
# > process. Thanks to those who might offer assistance.
# >
# > ---------------------------
# > -=<(| mike at |)>=-
# >
# >

More information about the Linux mailing list