Norman Maurer wrote: > Ok.. RemoteDelivery now supports to configure a diffrent > retry for such > DNS "issues". Even if i not like it .. Anyway i hope now all > are happy..
:) Thanks Norman. -- Steve > bye > Norman > > Steve Brewin schrieb: > > 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] > > > > !EXCUBATOR:1,4568a91953071544892336! > > > > > > --------------------------------------------------------------------- > 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]
