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 "Norman Maurer (JIRA)" <se...@james.apache.org> on 2007/04/18 10:35:15 UTC

[jira] Created: (JAMES-787) Fetchmail not use 127.0.0.1 as RemoteAddress when using index=-1

Fetchmail not use 127.0.0.1 as RemoteAddress when using index=-1
----------------------------------------------------------------

                 Key: JAMES-787
                 URL: https://issues.apache.org/jira/browse/JAMES-787
             Project: James
          Issue Type: Bug
          Components: FetchMail
    Affects Versions: 2.3.0, 2.2.0
            Reporter: Norman Maurer
         Assigned To: Norman Maurer
             Fix For: 2.3.1-dev


>From ml:

We tried to fetch emails via POP3 from a Exchange 2003 server which
are sent from one local exchange account to an other local exchange
account. Fetchmail stopped parsing the message because the ip is missing
in the received header of the emails. Even if i use -1 as index the same
happen. That seems to be a bug for me .. Should it not just use
"127.0.0.1" and not try to parse it ? After adding a workarround which
catch the UnknownHostexception and add "127.0.0.1" this is solved.

-- 
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

Re: [jira] Updated: (JAMES-787) Unable to resolv 127.0.0.1/localhost [was: Fetchmail not use 127.0.0.1 as RemoteAddress when using index=-1]

Posted by Stefano Bagnara <ap...@bago.org>.

Norman Maurer ha scritto:
> Stefano Bagnara schrieb:
>> Norman Maurer (JIRA) ha scritto:
>>   
>>> This is the diff for backporting to 2.3 branch . Any thoughts ?
> 
>> Considering this "weird behavior" is there since 2.2.0 and that it was a
>> known issue at release time I'm -0 on backporting this to v2.3 branch.
> 
> Like I said  I'm +1 for backporting the fix even if the solution is not
> such good as in trunk.

You asked for thoughts ;-)
If no one else share my concern you're more than welcome to proceed :-)

Stefano


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

Re: [jira] Updated: (JAMES-787) Unable to resolv 127.0.0.1/localhost [was: Fetchmail not use 127.0.0.1 as RemoteAddress when using index=-1]

Posted by Norman Maurer <no...@apache.org>.

Hi Stefano,

more comments inline ..

Stefano Bagnara schrieb:
> Norman Maurer (JIRA) ha scritto:
>   
>>      [ https://issues.apache.org/jira/browse/JAMES-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>>
>> Norman Maurer updated JAMES-787:
>> --------------------------------
>>
>>     Attachment: localResolv-2.3.diff
>>
>> This is the diff for backporting to 2.3 branch . Any thoughts ?
>>     
>
> I'm not sure this is critical enough to justify a 2.3 backport.
>
> In the old "next-major" roadmap we even excluded the bug from the
> next-major roadmap as a sign we could live with it. Also when planning
> 2.3 release (30/Jun/06) we voted to exclude JAMES-302 from the release.
>   

I know that we exclude it from next-major, but this was only the case (
for me ) because I  wasn't  aware  how  critical this bug is.

> On trunk the fix for this issue is much better (and clean) and I like
> it. I appreciate the choice to use the useLocalResolv configuration
> parameter to enable the fix (this ensure backward compatibility).
>   

I know that in trunk its much better but i can't find any better
solution in 2.3 branch. The biggest problem is that the methods are static..

> Considering this "weird behavior" is there since 2.2.0 and that it was a
> known issue at release time I'm -0 on backporting this to v2.3 branch.
>   

Like I said  I'm +1 for backporting the fix even if the solution is not
such good as in trunk.
> Maybe Noel's next-minor could be a better candidate for a full
> dnsservice backport.
>
> Stefano
>   

I agree that for next-minor a full backport whould be the best, but I
think this will take long time .


bye
Norman


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