Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.3.0
    • Fix Version/s: 2.3.0
    • Component/s: FetchMail
    • Labels:
      None

      Description

      While trying to implement the new James 2.2.0
      I discovering a bug in the MessageProcessor.java
      causing it not to fetch mails.

      Here is the patch

      — c:\james-2.2.0-src-original\src\java\org\apache\james\fetchmail\MessageProcessor.java 2004-05-01 23:47:22.000000000 +0200
      +++ c:\james-2.2.0-src\src\java\org\apache\james\fetchmail\MessageProcessor.java 2004-06-24 13:33:28.578125000 +0200
      @@ -683,11 +683,11 @@
      protected String computeRemoteDomain() throws MessagingException
      {
      StringBuffer domainBuffer = new StringBuffer();
      String[] headers = null;
      if (getRemoteReceivedHeaderIndex() > -1)

      • getMessageIn().getHeader(RFC2822Headers.RECEIVED);
        + headers = getMessageIn().getHeader(RFC2822Headers.RECEIVED);

      if (null != headers)
      {
      // If there are RECEIVED headers and the index to begin at is greater
      // than -1, try and extract the domain

      1. diff.txt
        0.8 kB
        Steen Jansdal

        Activity

        Hide
        sbrewin@apache.org Steve Brewin added a comment -

        Thanks, I'll sort it ASAP (if no one else gets there first).

        Looking at the code I am unclear why this is "causing it [fetchmail] not to fetch mails". Looks like the remote domain will always be set to "localhost". That should not stop mail being fetched and would explain why no one else has picked this up.

        It will cause the RBL Mailet to always pass the domain as valid. Custom mailets, who knows?

        – Steve

        Show
        sbrewin@apache.org Steve Brewin added a comment - Thanks, I'll sort it ASAP (if no one else gets there first). Looking at the code I am unclear why this is "causing it [fetchmail] not to fetch mails". Looks like the remote domain will always be set to "localhost". That should not stop mail being fetched and would explain why no one else has picked this up. It will cause the RBL Mailet to always pass the domain as valid. Custom mailets, who knows? – Steve
        Hide
        steen Steen Jansdal added a comment -

        Sorry for not giving a detailed description of the problem. I was in a hurry. The reason it stopped fetching mails was because since the specified <remotereceivedheader/> was not read "localhost" was used instead and "localhost" could not be resolved.

        Our dns is configured:

        <dnsserver>
        <servers>
        <server>194.239.134.83</server>
        <server>193.162.153.164</server>
        </servers>
        <autodiscover>false</autodiscover>
        <authoritative>false</authoritative>
        </dnsserver>

        This is from the fetchmail.log:

        24/06/04 13:04:15 DEBUG fetchmail.fetched_from_external: UNDELIVERABLE Message ID: <40DAA920.4030309@jansdal.dk>
        java.net.UnknownHostException: unknown host
        at org.xbill.DNS.Address.lookupHostName(Address.java:106)
        at org.xbill.DNS.Address.getByName(Address.java:124)
        at org.apache.james.dnsserver.DNSServer.getByName(DNSServer.java:463)
        at org.apache.james.fetchmail.MessageProcessor.computeRemoteAddress(MessageProcessor.java:1367)
        at org.apache.james.fetchmail.MessageProcessor.updateRemoteAddress(MessageProcessor.java:1455)
        at org.apache.james.fetchmail.MessageProcessor.getRemoteAddress(MessageProcessor.java:1400)
        at org.apache.james.fetchmail.MessageProcessor.createMail(MessageProcessor.java:601)
        at org.apache.james.fetchmail.MessageProcessor.process(MessageProcessor.java:357)
        at org.apache.james.fetchmail.FolderProcessor.process(FolderProcessor.java:94)
        at org.apache.james.fetchmail.StoreProcessor.process(StoreProcessor.java:83)
        at org.apache.james.fetchmail.FetchMail.targetTriggered(FetchMail.java:529)
        at org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler.doRunEntry(DefaultTimeScheduler.java:240)
        at org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler.access$000(DefaultTimeScheduler.java:36)
        at org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler$1.run(DefaultTimeScheduler.java:216)
        at org.apache.james.util.thread.ExecutableRunnable.execute(ExecutableRunnable.java:55)
        at org.apache.james.util.thread.WorkerThread.run(WorkerThread.java:90)

        Show
        steen Steen Jansdal added a comment - Sorry for not giving a detailed description of the problem. I was in a hurry. The reason it stopped fetching mails was because since the specified <remotereceivedheader/> was not read "localhost" was used instead and "localhost" could not be resolved. Our dns is configured: <dnsserver> <servers> <server>194.239.134.83</server> <server>193.162.153.164</server> </servers> <autodiscover>false</autodiscover> <authoritative>false</authoritative> </dnsserver> This is from the fetchmail.log: 24/06/04 13:04:15 DEBUG fetchmail.fetched_from_external: UNDELIVERABLE Message ID: <40DAA920.4030309@jansdal.dk> java.net.UnknownHostException: unknown host at org.xbill.DNS.Address.lookupHostName(Address.java:106) at org.xbill.DNS.Address.getByName(Address.java:124) at org.apache.james.dnsserver.DNSServer.getByName(DNSServer.java:463) at org.apache.james.fetchmail.MessageProcessor.computeRemoteAddress(MessageProcessor.java:1367) at org.apache.james.fetchmail.MessageProcessor.updateRemoteAddress(MessageProcessor.java:1455) at org.apache.james.fetchmail.MessageProcessor.getRemoteAddress(MessageProcessor.java:1400) at org.apache.james.fetchmail.MessageProcessor.createMail(MessageProcessor.java:601) at org.apache.james.fetchmail.MessageProcessor.process(MessageProcessor.java:357) at org.apache.james.fetchmail.FolderProcessor.process(FolderProcessor.java:94) at org.apache.james.fetchmail.StoreProcessor.process(StoreProcessor.java:83) at org.apache.james.fetchmail.FetchMail.targetTriggered(FetchMail.java:529) at org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler.doRunEntry(DefaultTimeScheduler.java:240) at org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler.access$000(DefaultTimeScheduler.java:36) at org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler$1.run(DefaultTimeScheduler.java:216) at org.apache.james.util.thread.ExecutableRunnable.execute(ExecutableRunnable.java:55) at org.apache.james.util.thread.WorkerThread.run(WorkerThread.java:90)
        Hide
        sbrewin@apache.org Steve Brewin added a comment -

        There appears to be two issues. The first is the missing assignment, which is fixed by the patch. The second is that when the domain is defaulted to 'localhost', 'localhost' is not being resolved.

        Show
        sbrewin@apache.org Steve Brewin added a comment - There appears to be two issues. The first is the missing assignment, which is fixed by the patch. The second is that when the domain is defaulted to 'localhost', 'localhost' is not being resolved.
        Hide
        sbrewin@apache.org Steve Brewin added a comment -

        There is a general issue with the way that 'localhost' is being resolved in this release, as per the link.

        Show
        sbrewin@apache.org Steve Brewin added a comment - There is a general issue with the way that 'localhost' is being resolved in this release, as per the link.
        Hide
        sbrewin@apache.org Steve Brewin added a comment -

        JAMES-300: Fixed missing assignment of headers value.
        JAMES-302: Replaced use of the literal 'localhost' with the canonical name of the local machine and if this cannot be deduced, with the loopback address 127.0.0.1.
        Also fixed up linefeeds in the source. Should now all be Unix format.

        Show
        sbrewin@apache.org Steve Brewin added a comment - JAMES-300 : Fixed missing assignment of headers value. JAMES-302 : Replaced use of the literal 'localhost' with the canonical name of the local machine and if this cannot be deduced, with the loopback address 127.0.0.1. Also fixed up linefeeds in the source. Should now all be Unix format.
        Hide
        danny@apache.org Danny Angus added a comment -

        Closing issue fixed in released version.

        Show
        danny@apache.org Danny Angus added a comment - Closing issue fixed in released version.

          People

          • Assignee:
            sbrewin@apache.org Steve Brewin
            Reporter:
            steen Steen Jansdal
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development