james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: svn commit: r451636 - /james/server/trunk/src/java/org/apache/james/core/AbstractJamesHandler.java
Date Sun, 01 Oct 2006 13:24:28 GMT
Stefano Bagnara wrote:

> Noel J. Bergman wrote:
>>> mmm... "unknown", [IP] or null (compatibility)? I do not see it very clear 
>>> in http://java.sun.com/j2se/1.5.0/docs/api/java/net/InetAddress.html#getHostName()
>> As I said, InetAddress and dnsjava do not always exhibit the same behavior.
> That's one reason why we only changed JAMES to use dnsjava where proper TTL
> handling was important.  Otherwise, we left it using the standard Java API.
> If we are going to use dnsjava more broadly (and *not* directly in Matchers
> and Mailets), we'll likely encounter additional nuances.

> The problem is that if we use 2 services we'll have 2 caches to monitor 
> and manage and this does not make so much sense.

Agreed.  I'm just pointing out that this isn't as trivial an exercise at would appear.

> We should probably expose more used parameters (hostname/address of the 
> sender) via mailetContext so we can serve them via our DNSService.

That's two separate issues.  One: modifying MailetContext for the common needs, and then how
a MailetContext is implemented.  PLEASE remember that we intend for MailetContext to not be
JAMES only.

I'm hoping that an enhanced MailetContext for most things, and dnsjava via JNDI for any odd
cases, will suffice for portable code, and dnsjava directly for the rest.

> > To answer the question asked by you, Norman and Stefano, see
> >getHostFromNameService in InetAddress.

> Yes, they never return exceptions but catch them and return the hostaddress


> PS: the java.net class also checks for spoofing running a getAllByName0 
> on the resulting host to check that the IP address is in the list of the 
> forward conversion.

Yes, it does.  The only thing really wrong with the java.net code is the fatally flawed cache
handling that renders it useless for our needs.  One of the things I want to check is whether
or not the JNDI codepath (calling dnsjava via JNDI) has the same flaw.  I suspect not, which
would be good.

	--- Noel

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

View raw message