On Thu, 02 Mar 2006 00:14:29 -0700, Tobias Weingartner wrote: >On Thursday, March 2, "Rod.. Whitworth" wrote: >> On Wed, 01 Mar 2006 23:16:59 -0600, Graham Toal wrote: >> > >> >If your DNS is on the same net as the mailer, its down too. Senders >> >soon get no result at all when they look you up, with the result that >> >mail *bounces* (unknown address) rather than requeues. >> >> NO - it does not! Well, not unless the sending MTA is broken. To quote >> from Postfix documentation referring to not getting an MX record from >> DNS: >> " By default, the Postfix SMTP client defers delivery and tries again >> after some delay. This behavior is required by the SMTP standard." > >If the client can't find any DNS information on the destination, it >tends to bounce. At least in all non-broken MTAs. Try it. Send >email to [EMAIL PROTECTED] and see what happens.
Lars answered that with precision. RFC2821 says that a sending MTA MUST retry in cases where the failure is possibly caused by temporary failure. There is a difference between a failure to connect to an authoritative DNS and getting a response that says the domain does not exist. > >> It also neglects the fact that lots of caching nameservers elsewhere >> will have a copy of the records that likely will not expire for quite >> sometime. I know mine are set to 3600 but I have had the sad experience >> of changing a domain from one dns hosting service to another and the >> old one had a TTL good for a week. > >This was 1/2 his argument. No DNS info means no DNS info. Not "somewhere >out there" (sung like the song) we have a cache... > >> >Note that 5 days of pent-up mail arriving at once can kill a >> >machine even if it is normally up to the peak loads you get, >> >so you want a throttling control both on what the backup MX >> >forwards to you when you return, and what you accept from >> >other sources when you return. >> >> 5 days of pent up mail will NOT all arrive at once. Not all of the >> senders will try again simultaneously and it is also likely that each >> of them will also not even flush all of the delayed messages in one >> batch. Rate limiting in decent MTAs mitigates the problem. > >It most certainly will if the backup MTA sends it all at once. And if >you read what you responded to, he said "make sure that the backups >to rate limiting". And you respond with "Rate lmiting in decent MTAs >mitigates the problem". So? Why are you saying what you are saying? Whoops! What I slipped up on there was deleting the line that said: "If you don't use a backup/secondary MX then you will find that " prior to the "5 days........" line. > >> That said, having backup DNS located elsewhere is never harmful as long >> as you can get it updated as fast as your master in house. > >scp, rsync, etc, etc. It will tend to get updated faster than the primary, >considering you've got to edit the primiry's version by hand (usually). It may be <faster> but it won't get done before the end of the hand edit on the master. ~|^ == > >--Toby. > > >From the land "down under": Australia. Do we look <umop apisdn> from up over? Do NOT CC me - I am subscribed to the list. Replies to the sender address will fail except from the list-server.
