Hi all, even the if the descripted solution (diffrent retry count) is better then the old behavoir, me favorit is still the new code which i commit and is now in trunk.
bye Norman Vincenzo Gianferrari Pini schrieb: > Adding my 2c to Norman's example: > > Because of the scenario he described, I changed my config.xml long > time ago to one day instead of 5 days of retry before giving up. > > I was planning to code in RemoteDelivery (and never did it) a kind of > "warning bounce" feature to trigger after a few hours, while retrying > for up to five days. > But it would be much better if we could find a way to check if "my DNS > server" is failing to resolve the domain because the recursed servers > fail to resolve, and not because there is a network problem isolating > my local network. > > Or (a different approach) have a different retry policy (few hours > instead of 5 days) for DNS resolution failures while keeping the > longer 5 days period in case of target SMTP server failures: the > difference is that there is a "world wide" cache system for DNS > resolution, and if a domain name is not found in such cache it is > *much* more probable that the domain is non-existent for real and not > that there are network problems. What do you think? > > Vincenzo > > Norman Maurer wrote: >> Noel J. Bergman schrieb: >> >>> Norman, >>> >>> >>>> Noel J. Bergman schrieb: >>>> >>>>> -1 >>>>> The handling of this condition as temporary was very >>>>> intentional, and >>>>> in no way accidental. This is a not uncommon problem. The DNS >>>>> can be >>>>> wrong, and later corrected. The problem is ascertaining whether a >>>>> domain is non-existent for real (there is no registration record) or >>>>> because of a temporary DNS configuration error. >>>>> >>>>> Consider the debate within the SPF council regarding whether or not >>>>> NXDOMAIN was to be treated as a PermError or TempFail. >>>>> >>> >>>> This was not the final solution. See revision 478589 >>>> >>> I am not happy with the change. As I read it, r478589 is a bit >>> better only if the local DNS server is down. That's only one of >>> several DNS related issues that can result in failure. >>> >>> Consider >>> http://www.mhonarc.org/archive/html/spf-discuss/2005-05/msg00327.html. >>> I do consider the author of that particular e-mail to wrong because >>> the intent of the SMTP specification is to put a very high degree of >>> reliability on the delivery of mail. We bias decisions to ensure >>> delivery. But the point is for you to read the real-world examples >>> of DNS failure given to him as examples. And, FWIW, I have seen >>> similar errors and had mail lost by qmail that would not have been >>> lost by JAMES. >>> >>> I am OK with optional filters for rejecting mail in-protocol if the >>> MAIL FROM or even REPLY-TO domains are invalid (even temporarily), >>> but I am *not* OK with hardcoding the change you are making to >>> bounce mail because there is a transient DNS glitch on the delivery >>> side. >>> >>> Do you understand now? >>> >>> --- Noel >>> >>> >> >> Hi Noel, >> >> i not agree with you. First of all if the nameserver is not configured >> correctly etc we should not try to "take care" and give the admin a >> chance to correct it He should get sure what he do before change the >> config.. I think most admins and users want to get the error as soon as >> possible. Let me give you an example why the old behavoir is bad: >> >> Think about you have a costumer where you installed james. He sended an >> email with an importent text out and not notice that he has a misstyping >> in the domainname. The domain he used as recipient domain does not >> exists. But he not get the bounce back till the configured retry count >> was reached.. (about 5 days). Because of that he not notice that he had >> a misstyping in the domainname, so he lost a job which whould hat >> brought him 1 000 0000 Dollars. How you whould explain him this ? >> >> This is not acceptable for me.. If we have an other DNS error then a >> temporary connection problem we should bounce as soon as possible. >> >> Don't get me wrong.. im not aggressiv.. I only try to explain you why i >> think the old behavoir is really bad! >> >> bye >> Norman >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > !EXCUBATOR:1,45672da653071618711010! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
