james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Keyser (JIRA)" <server-...@james.apache.org>
Subject [jira] Commented: (JAMES-345) If FetchMail cannot parse Received header, it cannot process the message even with <remotereceivedheader reject="false".../>
Date Tue, 04 Jan 2005 13:11:14 GMT
     [ http://issues.apache.org/jira/browse/JAMES-345?page=comments#action_57261 ]
Jeff Keyser commented on JAMES-345:

I'm sorry, but I was using version 2.2.1 RC1 and still saw this issue.

The problem isn't looking up an address, but what it does when it can't look up an address.

> If FetchMail cannot parse Received header, it cannot process the message even with <remotereceivedheader
> ----------------------------------------------------------------------------------------------------------------------------
>          Key: JAMES-345
>          URL: http://issues.apache.org/jira/browse/JAMES-345
>      Project: James
>         Type: Bug
>   Components: FetchMail
>     Versions: 2.2.1
>     Reporter: Jeff Keyser

> 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()
> 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.
If you think it was sent incorrectly contact one of the administrators:
If you want more information on JIRA, or have a bug to report see:

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message