[
https://issues.apache.org/jira/browse/JAMES-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510381
]
sravan commented on JAMES-795:
------------------------------
Seems this issue is not yet fixed.
I could still replicate this issue. I was able to do a workaround using the
first option suggested by the reporter of issue #345.
> CLONE -If FetchMail cannot parse Received header, it cannot process the
> message even with <remotereceivedheader reject="false".../>
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: JAMES-795
> URL: https://issues.apache.org/jira/browse/JAMES-795
> Project: James
> Issue Type: Bug
> Components: FetchMail
> Affects Versions: 2.3.0
> Reporter: sravan
>
> When FetchMail cannot determine the IP address of the sender of an e-mail
> from the "Received" headers, it fails to process the e-mail even when it is
> told to not reject such errors.
> I have debugged this problem in the code, and it appears that the problem is
> because an UnknownHostException is being thrown in the call to
> getRemoteAddress() within the createMail() method.
> Currently, getRemoteAddress() throws an UnknownHostException for the
> isRemoteReceivedHeaderInvalid() method to work. A "reject" setting of "true"
> allows the code to continue processing after this test. However, it appers
> that createMail() doesn't expect an exception to be thrown, but a null value
> to be returned when the address cannot be parsed.
> One possible solution would be for createMail to explicitly handle
> UnknownHostExceptions and use this to set the values of the address and
> remote host of the e-mail to "localhost" instead of testing for a return
> value of null from these methods.
> Another possible solution would be to explicitly parse the "Received" header
> up front instead of lazily parsing it inside the getRemoteAddress() method.
> If this were done, there would be no reason for getRemoteAddress() to throw
> an UnknownHostException at all, and would also prevent a possible "double
> lazy initialization" that could occur with the first solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
