Norman Maurer wrote: > > > Noel J. Bergman schrieb: > > 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 fatal. > > > > q.v. > http://community.kavi.com/khelp/kmlm/user_help/html/bounces.html > > > > Is there anything more fatal as an unexisting domain ? And > again if my > nameserver has problems its not the "task" of the mailserver > take care. > DNS is needed for mailservices.. If there are DNS problems then the > sender should be notified. What james did in his old behavoir > is really > strange and i bet most users and adminstrators never whould expect it. > > Our Company administrate Qmail and Postfix server for long > time and was > really shocked about the behavoir of james. We can't accept > do get the > error bounce of an unexisting domain 1 Week after send the email. > > > >>> 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 think Stefano has finished the DSN stuff long ago. But it > needed many > core changes.. Im not sure if it whould be backward compatible. > > > > >> 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. > > > See my previous email. Its better then the old behavoir but still not > the correct solution (IMHO) > > > >> 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: > > > > > http://www.mhonarc.org/archive/html/spf-discuss/2005-05/msg00315.html > > > > 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. > > > Again.. if its misconfigured its not our task to deal with.. > If someone > misconfigure his mailserver to deliver all email to /dev/null we also > can't take care. Its all about adminstration. If an > admistrator change > something and break it, its not our "problem". > And if the dnsserver is down we will query the secondary. > Every domain > should have at least 2 dns servers.
While it is not our task to deal with the misconfiguration, it is our task to try and get the mail through. This is the spirit which informs the RFCs. To use an analogy, imagine the postman arriving in your area and finding all of the house numbers are unreadable because of dense fog or heavy snow (address is temporarily unresolvable). What would you expect him to do? Try again later or return the mail as undeliverable? > > > >> 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 conditions. This solution deals nicely with all of the use cases presented here. The DNS schedule could be as short as required in Norman's case and as long as required by Noel's mailing list use-case. Each deployment can configure things to work how they wish rather than us forcing them to take the route we deem to be correct. > > Read my comment above > > The SMTP specifications are biased towards reliability at > the expense of other tradeoffs, and we should do likewise. By default yes, but where we can offer configurable and compliant alternatives, we should do so. This is precisely what your proposed solution achieves. > > > > --- Noel > bye > Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
