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]
