james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Hoffmann ...@byteaction.de>
Subject AW: AW: AW: Permanent errors from transient DNS issues?
Date Mon, 27 Nov 2006 21:52:08 GMT
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:sbrewin@synsys.com] 
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:vincenzo.gianferraripini@praxis.it]
> 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:vincenzo.gianferraripini@praxis.it]
> > 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:sbrewin@synsys.com]
> >>>>> 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: server-dev-unsubscribe@james.apache.org
> >>> For additional commands, e-mail: server-dev-help@james.apache.org
> >>>
> >>> !EXCUBATOR:1,456ae2fb53071335268197!
> >>>
> >>>
> >>>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> >> For additional commands, e-mail: server-dev-help@james.apache.org
> >>
> >>
> >>
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-dev-help@james.apache.org
> >
> > !EXCUBATOR:1,456af64f53071672013762!
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-dev-help@james.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
> !EXCUBATOR:1,456aff6b53071348279085!
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>


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

!EXCUBATOR:1,456b4bd353071272017908!



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


Mime
View raw message