From aaron@darklands.org Thu Mar 29 17:01:56 2001 Received: from mxu4.u.washington.edu (mxu4.u.washington.edu [140.142.33.8]) by lists.u.washington.edu (8.11.2+UW01.01/8.11.2+UW01.03) with ESMTP id f2U11r219330 for ; Thu, 29 Mar 2001 17:01:53 -0800 Received: from despair.darklands.org (despair.darklands.org [216.39.163.181]) by mxu4.u.washington.edu (8.11.2+UW01.01/8.11.2+UW01.03) with SMTP id f2U11r700535 for ; Thu, 29 Mar 2001 17:01:53 -0800 Received: (qmail 24063 invoked by uid 1000); 30 Mar 2001 01:24:04 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Mar 2001 01:24:04 -0000 Date: Thu, 29 Mar 2001 17:24:04 -0800 (PST) From: Aaron To: UW Linux Group Subject: Re: email - delivery retry timeouts In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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- 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. 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 boobaz.net zone is one hour, so you should have plenty of time to add an additional MX record. Aaron 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@boobaz.net |)>=- # > # > # # .