Stefano Bagnara schrieb: > 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 Yes i have a localhost mapping... I think the problem is here: try { mail = createMail(createMessage(), intendedRecipient); } catch (ParseException ex) { handleParseException(ex); return; } catch (UnknownHostException ex) { handleUnknownHostException(ex); return; }
The createMail(...) call getAddress(), getAdress() throws the Unknownhostexception because it can't parse the ipaddress. Then we call handleUnknowHostException(..) and just ignore the message. bye Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
