Hi Steve, the discussion was just held alive because of my understandings of how this should be done. BUT I also think, that the solution at hand is perfectly fine with me.
Kind regards Juergen -----Ursprüngliche Nachricht----- Von: Steve Brewin [mailto:[EMAIL PROTECTED] Gesendet: Montag, 27. November 2006 21:31 An: 'James Developers List' Betreff: RE: AW: AW: Permanent errors from transient DNS issues? Jürgen Hoffmann wrote: > > > Hi Vincenzo, > > even if it is a local problem. Do you really want to loose a > week to find out > about it? I think this discussion has already illustrated valid use-cases for both sides of the argument. This is why I suggested we make the behaviour configurable. If we wanted to be real smart we might add adaptive behavior depending on the mail classification, with high priority mail using a very short schedule (one try and fail) and bulk mail using a long schedule. But this is an evolution for another day. Right now, with Norman's changes, a deployer can configure the behaviour to one or the other use-cases. This seems an excellent fine first step. One we can refine in the future. I'm unsure why this is unacceptable. Am I overlooking something? Cheers -- Steve > > Kind regards > > Juergen > > > -----Ursprüngliche Nachricht----- > Von: Vincenzo Gianferrari Pini > [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 27. November 2006 16:08 > An: James Developers List > Betreff: Re: AW: AW: Permanent errors from transient DNS issues? > > Hi Jürgen, > > if the target (destination) is wrong surely it's its administrator > problem, but if it is a problem with my servers (either James > or all my > nameservers or the ones I query) or a network problem > isolating me, then > I don't want *all* my sending users get back immediate bounces and I > want instead to try to fix the things, so it's my problem. > > I sure may be wrong, but as I said before I'm making a > difference here > between *my* nameservers and the *target domain* nameservers. > > Vincenzo > > Jürgen Hoffmann wrote: > > Hi Vincenzo, > > > > seriously, if another mailserver is delivering a "552 No > such user" Can we > > really be sure that there really is no such user, or that > the administrator > > may have mis-configured his Mailserver. ;) > > > > Kind regards > > > > Juergen > > > > -----Ursprüngliche Nachricht----- > > Von: Vincenzo Gianferrari Pini > [mailto:[EMAIL PROTECTED] > > Gesendet: Montag, 27. November 2006 15:29 > > An: James Developers List > > Betreff: Re: AW: Permanent errors from transient DNS issues? > > > > Hi Norman, > > > > IMHO the point is: are we sure of that? Will dnsjava return > > Lookup.TRY_AGAIN even if all *my nameservers* are reachable > but they are > > isolated from the rest of the world? > > And do you agree that the above is the right discriminator? > > > > Ciao, > > > > Vincenzo > > > > > > Norman Maurer wrote: > > > >> Hi Vincenzo, > >> > >> i whould asspect that dnsjava will return Lookup.TRY_AGAIN > on such cases. > >> And thats what i check for ;-) > >> > >> bye > >> Norman > >> > >> > >> > >>> Hi Jürgen and Norman, > >>> > >>> I agree with you *if* I can be sure that at least one of *my* > >>> nameservers (the ones queried by my James server) is able > to reach the > >>> net and doesn't resolve the target domain (no target > nameservers found), > >>> and anwers NXDOMAIN. But is it possible to figure it out? And does > >>> Norman's fix take in account that? > >>> > >>> In other words, if all *my* nameservers are either > unreachable, or are > >>> themselves unable to forward the query, it means that there are > >>> connection problems "on my side" and we can not "be > pretty sure, that > >>> there is no such Domain/MX Entry", and we should keep retrying. If > >>> instead "an outer world" query is done then your > reasoning is correct. > >>> > >>> I'm making a difference here between *my* nameservers and > the *target > >>> domain* nameservers. > >>> > >>> Am I right or I'm missing something here :-) ? > >>> > >>> Anyway, it is unacceptable to have a message bounce back > only after one > >>> week because there is a typo in the domain part of an address. > >>> > >>> Vincenzo > >>> > >>> Norman Maurer wrote: > >>> > >>> > >>>> Hi Jürgen, > >>>> > >>>> that was exactly what i did. But then they all start > complaining. Thats > >>>> why i changed it to be configurable. > >>>> > >>>> bye > >>>> Norman > >>>> > >>>> > >>>> > >>>> > >>>>> Hi All, > >>>>> > >>>>> seriously, I disagree with how you expect DNS to work. > A Domain has > >>>>> configured "n" Nameservers that are responsible for > Name resolution. So > >>>>> I > >>>>> would expect James to use all of them in a loop fashion. > >>>>> > >>>>> If all Nameservers fail with "NXDOMAIN", or we cannot > even determine, > >>>>> that > >>>>> there is not even one Nameserver for a given Domainname > available, we > >>>>> can > >>>>> be pretty sure, that there is no such Domain/MX Entry. > >>>>> > >>>>> So I would really like to handle this differently. > >>>>> > >>>>> - If it is not possible to determine nameservers, > bounce with perm > >>>>> error > >>>>> - If there are nameservers available, but not > reachable, queue the > >>>>> Mail. > >>>>> > >>>>> Does this make sense? > >>>>> > >>>>> Kind Regards > >>>>> > >>>>> Juergen > >>>>> > >>>>> > >>>>> > >>>>> -----Ursprüngliche Nachricht----- > >>>>> Von: Steve Brewin [mailto:[EMAIL PROTECTED] > >>>>> Gesendet: Sonntag, 26. November 2006 18:39 > >>>>> An: 'James Developers List' > >>>>> Betreff: RE: Permanent errors from transient DNS issues? > >>>>> > >>>>> 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 > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>> > --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> !EXCUBATOR:1,456ae2fb53071335268197! > >>> > >>> > >>> > >> > >> > >> > --------------------------------------------------------------------- > >> 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] > > > > !EXCUBATOR:1,456af64f53071672013762! > > > > > > > > > --------------------------------------------------------------------- > > 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] > > !EXCUBATOR:1,456aff6b53071348279085! > > > > --------------------------------------------------------------------- > 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] !EXCUBATOR:1,456b4bd353071272017908! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
