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