You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2006/10/01 04:30:11 UTC
RE: svn commit: r451636 - /james/server/trunk/src/java/org/apache/james/core/AbstractJamesHandler.java
> 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.
To answer the question asked by you, Norman and Stefano, see getHostFromNameService in InetAddress.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: svn commit: r451636 - /james/server/trunk/src/java/org/apache/james/core/AbstractJamesHandler.java
Posted by "Noel J. Bergman" <no...@devtech.com>.
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
Re: svn commit: r451636 - /james/server/trunk/src/java/org/apache/james/core/AbstractJamesHandler.java
Posted by Stefano Bagnara <ap...@bago.org>.
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.
We should probably expose more used parameters (hostname/address of the
sender) via mailetContext so we can serve them via our DNSService.
> To answer the question asked by you, Norman and Stefano, see getHostFromNameService in InetAddress.
>
> --- Noel
Yes, they never return exceptions but catch them and return the hostaddress:
---
} catch (SecurityException e) {
host = addr.getHostAddress();
} catch (UnknownHostException e) {
host = addr.getHostAddress();
}
----
If we want to replace it with dnsjava we should make sure we do the same
to avoid compatibility problems.
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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r451636 - /james/server/trunk/src/java/org/apache/james/core/AbstractJamesHandler.java
Posted by Norman Maurer <nm...@byteaction.de>.
Stefano Bagnara schrieb:
> 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.
I agree.
>
> We should probably expose more used parameters (hostname/address of
> the sender) via mailetContext so we can serve them via our DNSService.
That make sense. We should also add setter methodes for the DNSService
to it. So we not bind the mailets/matchers to our code.
>
>> To answer the question asked by you, Norman and Stefano, see
>> getHostFromNameService in InetAddress.
>>
>> --- Noel
>
> Yes, they never return exceptions but catch them and return the
> hostaddress:
> ---
> } catch (SecurityException e) {
> host = addr.getHostAddress();
> } catch (UnknownHostException e) {
> host = addr.getHostAddress();
> }
> ----
>
> If we want to replace it with dnsjava we should make sure we do the
> same to avoid compatibility problems.
Ok that should be no problem.. But for me it whould make more sense to
return "unknown" as hostname if the host can not resolved. Anyway im ok
with it.
>
> 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.
>
> Stefano
>
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org