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 "sravan (JIRA)" <se...@james.apache.org> on 2007/07/05 17:13:04 UTC
[jira] Created: (JAMES-795) CLONE -If FetchMail cannot parse
Received header, it cannot process the message even with
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (JAMES-795) CLONE -If FetchMail cannot parse
Received header, it cannot process the message even with
Posted by "sravan (JIRA)" <se...@james.apache.org>.
[ 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Resolved: (JAMES-795) CLONE -If FetchMail cannot parse
Received header, it cannot process the message even with
Posted by "Norman Maurer (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Norman Maurer resolved JAMES-795.
---------------------------------
Resolution: Fixed
fixed
> 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 Server
> Issue Type: Bug
> Components: FetchMail
> Affects Versions: 2.3.0
> Reporter: sravan
> Assignee: Norman Maurer
> Fix For: 3.0-M2
>
>
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (JAMES-795) CLONE -If FetchMail cannot parse
Received header, it cannot process the message even with
Posted by "Norman Maurer (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/JAMES-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Norman Maurer updated JAMES-795:
--------------------------------
Fix Version/s: 3.0-M2
Assignee: Norman Maurer
Should be fixed for M2
> 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 Server
> Issue Type: Bug
> Components: FetchMail
> Affects Versions: 2.3.0
> Reporter: sravan
> Assignee: Norman Maurer
> Fix For: 3.0-M2
>
>
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org