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: Permanent errors from transient DNS issues?
Date Mon, 27 Nov 2006 11:00:45 GMT
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
> 
> 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: server-dev-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-dev-help@james.apache.org
> >
> > !EXCUBATOR:1,4568a91953071544892336!
> >   
> 
> 
> 
> ---------------------------------------------------------------------
> 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,4569d20053071059313844!



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