Norman Maurer ha scritto:
Stefano Bagnara schrieb:
Norman,
this is v2.3, a branch in RC state!!
bugfixes should be applied to trunk and *then* we should discuss
wether to backport to v2.3, IMHO.
Ups... You 100 % right... shame on me. For sure i should commit to trunk
first. I will revert it in branch and start apply the changes in trunk
again, after we discuss it!
Thank you :-)
About the issue and the patch, looking at the code it seems that it
should have already worked, so probably if we have a bug it is related
to DNS and not to fetchmail. In the current fetchmail code there are
almost 30 lines of code to manage the -1 scenario, so it seems a bit
weird to simply add a couple of lines to avoid their execution.
Maybe Steve can help understanding what's going on...
Have you debugged the problem? Where exactly the unkownhost happens?
Well, I think its unneeded to parse the the header and try to resolve
the ip/domain if index -1 is used. Its a waste of ressource. The
problem appeared here with exchange server message which not had an ip
address in the Received header. For me it should not fail to fetch this
emails if index -1 is used because the comment tells me that it will use
127.0.0.1 and localhost everytime. So why parse it ?
See https://issues.apache.org/jira/browse/JAMES-787
Well, I understood the problem you described and your concern, but also
in JAMES-787 there is no stacktrace or other debugging information I can
use to understand that we don't break anything with this fix.
If you look at the computeRemoteAddress and computeRemoteDomain I
previously quoted you will see that computeRemoteDomain if
getRemoteReceivedHeaderIndex is -1 does not do computation but simply as
k to the host what is localhost or the localhost address.
I guess this is because Steve didn't want to add "127.0.0.1" or
"localhost" *magic* words to the code but preferred to rely on
underlying OS informations.
I would like to know what this code returned on your machine:
-----
try
{
InetAddress addr1 = java.net.InetAddress.getLocalHost();
// These shenanigans are required to get the fully qualified
// hostname prior to JDK 1.4 in which getCanonicalHostName()
// does the job for us
InetAddress addr2 =
java.net.InetAddress.getByName(addr1.getHostAddress());
InetAddress addr3 =
java.net.InetAddress.getByName(addr2.getHostName());
domainBuffer.append(addr3.getHostName());
}
catch (UnknownHostException ue)
{
domainBuffer.append("[127.0.0.1]");
}
-----
the computeRemoteAddress gives a result based on the code above.. so if
we understand what's wrong there we may probably fix the issue.
and remember we have an open bug overlapping this code:
https://issues.apache.org/jira/browse/JAMES-302
Maybe that you are simply hitting JAMES-302 again (does your host file
contains 127.0.0.1 <-> localhost mapping ?).
About JAMES-302 we decided to move that out from v2.3 roadmap a while
ago, but if we find a correct and simple fix we could evaluate
reinclusion in v2.3 (even if I'm not sure we should delay 2.3.1 for this).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
