james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Permanent errors from transient DNS issues?
Date Fri, 24 Nov 2006 22:43:11 GMT
Vincenzo Gianferrari Pini wrote:
> Norman Maurer wrote:
> > 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 consider that an overly callous attitude, and unnecessary.

> > I think most admins and users want to get the error as soon
> > as possible.

They want their mail delivered (I'll address your use case in a moment).  And Delivery Notices
are getting a worse reputation all the time.  If you cannot reject the message during the
protocol exchange, most users want a notice to be an absolute last resort.  And, importantly,
automated processes such as mailing lists servers do not want a bounce unless it really is

  q.v. http://community.kavi.com/khelp/kmlm/user_help/html/bounces.html

> > 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.

> 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.

This is a fine use case, but the solution is still wrong because of the other problems it
creates.  There are multiple things that we can do to address this use case, which I consider
valid and worth addressing.  For example, I have worked with mail servers that will provide
interim status information.  I'm not sure where Stefano is with respect to the DSN work that
he worked on, but with or without it we could allow the admin to configure JAMES to provide
early notice of temporary failures.  That is the same as:

> 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.

and I would be fine with such a thing.

> 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.

There may be problems at the far end, including THEIR DNS server being down or temporarily
mis-configured.  Again, consider the reality:


And since RFC 2821 strongly encourages the schedule that we use by default, administrators
may count on the described behavior as providing a safety margin.

> 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

> What do you think?

If you recall my proposal for replacing the scheduler, which is the very next thing that I
plan to work on after the hassle of dealing with I/O handling, that was actually a related
use-case.  I described having a schedule for retrying because of DNS failure, e.g., with the
IsSpammerInBlacklist matcher.  So, yes, we could have multiple schedules configured for different

The SMTP specifications are biased towards reliability at the expense of other tradeoffs,
and we should do likewise.

	--- Noel

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message