Re: MxSorter and changes to DNSServer.java

2004-04-09 Thread Soren Hilmer
Hi Noel,

My concern on this is that InetAddress caches successfull DNS lookups forever 
(at least on default) and this strategy is not very sound for a mailserver, 
as I happened to discover :-( 

A possible (not optimal) solution is to set the security property 
networkaddress.cache.ttl to something less than the maximum retry-time for an 
undelivered mail, somewhere in James (RemoteDelivery ?).

--Soren

On Wednesday 07 April 2004 21:18, Noel J. Bergman wrote:
 I have modified getSMTPHostAddresses to call findMXRecords and then use the
 Iterator from that collection.  We could go back to using MxSorter (the
 comment I just put in about being able to us MxSorter within findMXRecords
 is wrong, since we don't ever see a Collection over which to iterate; we
 get an iterator), if we make some changes to it.

 The more important change in DNSServer was reverting to the previous
 technique of using InetAddress.getAllByName to get the IP addresses for the
 SMTP hosts, rather than the Type.A lookup.  The code was failing to resolve
 hosts that use CNAME on the right hand side of an MX record.  That may be
 an incorrect DNS configuration, but it is all too common as I have noticed
 over the past couple weeks of testing the new code.

 Comments?  Any strong feelings either way about using MxSorter to sort on
 the fly versus pre-sorting, which is what findMXRecords does?  If people
 want to use MxSorter, the fixes should be fairly straightforward.  The
 drawback is having two sections of code doing largely the same thing, but
 if we end up deprecating findMXRecords, that issue goes away.

 I am not sure if MxSorter is faster unless there would be a lot of records.
 Even if you are using the first record, we have already got the records,
 and sorting a small Collection in place is quick.  MxSorter makes a linear
 pass through the entire Collection, engages in object creation (at the
 least, it has to call toString()) for each host matching the then
 leastPriorityFound, and may create and delete entries from its working
 collection depending upon the order in which they are present from the
 lookup call.  At least that's my take on the code.

   --- Noel


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-- 
Søren Hilmer, M.Sc.
RD manager Phone:  +45 70 27 64 00
TietoEnator IT+ A/S Fax:+45 70 27 64 40
Ved Lunden 12   Direct: +45 87 46 64 57
DK-8230 Åbyhøj  Email:  soren.hilmer at tietoenator.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Created: (JAMES-251) ClassCastException

2004-04-09 Thread jira
Message:

  A new issue has been created in JIRA.

-
View the issue:
  http://issues.apache.org/jira/browse/JAMES-251

Here is an overview of the issue:
-
Key: JAMES-251
Summary: ClassCastException
   Type: Bug

 Status: Unassigned
   Priority: Trivial

Project: James
 Components: 
 James Core

   Assignee: 
   Reporter: Vadim Gritsenko

Created: Fri, 9 Apr 2004 5:26 AM
Updated: Fri, 9 Apr 2004 5:26 AM

Description:
Trivial patch for possible ClassCastException in LocalDelivery (HEAD version, not 
present on the branch), attached to:
http://marc.theaimsgroup.com/?l=james-devm=107797809210836w=2



-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: MxSorter and changes to DNSServer.java

2004-04-09 Thread Noel J. Bergman
 My concern on this is that InetAddress caches successfull DNS
 lookups forever (at least on default) and this strategy is not
 very sound for a mailserver

Good point, Søren.  And that happens in InetAddress, but through
contamination with sun.* classes.  It isn't pluggable.  The is a comment in
the code that suggests that the author realizes it is a problem.  Even
replacing the default DNS provider with dnsjava (using
sun.net.spi.nameservice.provider), would not help.

However, since the use of InetAddress within DNSServer is opaque, we could
trivially switch to using org.xbill.DNS.Address, which is a InetAddress
clone that uses dnsjava.  How does that sound?

I haven't checked the rest of the code, but InSpammerBlacklist also has this
problem.  That should probably be changed to use dnsjava, and perhaps JNDI
in the future (portable, but more overhead).  That would also allow us to
get the TXT record, which some DNS RBLs use to provide useful information,
e.g.,

  attrs = dnsContext.getAttributes(rblString, new String[] {A, TXT});

in JNDI-speak.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]