> linux is different than Windows.
sure is :-)
> It is looking in the host file for your localhost server, not DNS.
When I configure the nameserver explicitly in James, lookup of remote
hosts succeeds but lookup of configured servernames fails - but these
are also available via dns, so shouldn't this work identically for
remote/local host lookup?
I just took a quick look at the code to see why/how it does the lookup,
and found that the code producing the error uses
InetAddress.getAllByName - shouldn't it be using
org.apache.james.dnsserver.DNSServer.getAllByName which is used
elsewhere successfully? isn't this effectively ignoring the configured
dns server? is this a bug?
Incidentally, a comment in the same code answered my question #2 - it
claims to use the resolved addresses to support delivery to
<user@address-literal> as required by the RFC. But I've never seen
literal addresses used in practice, so I feel somewhat more comfortable
using the workaround for now.
> do a ifconfig to see if you have any DNs Server Assigned.
I don't see anything in ifconfig related to DNS - what should I be
> if you have a firewall make sure that DNS can be received by the server.
> you can also do a
> netstat -an
> and see if your sever is connection to port 53
As a dns client, nslookup works fine, as does the remote delivery in
James when I manually configure the nameserver - so I don't think this
is a firewall problem.
Or do u mean James does in fact try to act as a dns *server*?
Thanks for your help!
> A. Rothman sent the following on 6/29/2009 4:41 AM:
>> I'm migrating JAMES (2.3.1) from Windows to Ubuntu Jaunty, installed as
>> a daemon following the guidelines in the james wiki, and seem to have
>> some DNS problems. If started from the command line, everyting runs
>> fine. But when started by a reboot, the dnsserver* log show that no dns
>> server was auto-detected, as well as java.net.PortUnreachableExceptions
>> when trying to send a message, and the james* log shows the error:
>> "ERROR James: Cannot get IP address(es) for domain.name". I tried to
>> workaround this by explicitly specifying the dns server in the
>> configuration, and now sending messages works ok (no exception), but the
>> latter error remains. So -
>> 1. What reasons might it have to fail at dns autodiscovery only during
>> boot time?
>> 2. Is the error "Cannot get IP address(es) for domain.name" really an
>> error? What implications might this have? Since with the explicitly
>> configured dns server, both sending and receiving messages seem to be ok
>> even with the error shown...
>> 3. Is the dns component really a dns server (as the log name implies)?
>> or a dns client? Should I configure the firewall for a dns server?
>> Any help would be much appreciated :-)
> To unsubscribe, e-mail: server-user-unsubscribe@jame... > For additional commands, e-mail: server-user-help@jame... >