Steve Brewin wrote: > Brent L Johnson wrote: > > Received: from nobody by kayako.lunarpages.com with local > (Exim 4.30; > > FreeBSD) > > id 1ApAAA-0002xf-Ex > > for [EMAIL PROTECTED]; Fri, 06 Feb 2004 09:53:10 -0800 > and... > > > 05/02/04 20:44:13 WARN fetchmail.bjohnson.net: Message could > > > not be delivered due to an error determining the remote > > > domain. Message ID: > > > <[EMAIL PROTECTED]>. Flags: Seen = > > > false, Delete = false. 05/02/04 20:44:13 DEBUG > > > fetchmail.bjohnson.net: UNDELIVERABLE Message > > > ID: <[EMAIL PROTECTED]> > > > java.net.UnknownHostException: nobody: nobody > > > at java.net.InetAddress.getAllByName0(InetAddress.java:1011) > > > at java.net.InetAddress.getAllByName0(InetAddress.java:981) > > > at java.net.InetAddress.getAllByName(InetAddress.java:975) > > > at java.net.InetAddress.getByName(InetAddress.java:889) > > > at > > > org.apache.james.fetchmail.MessageProcessor.computeRemoteAddre > > > ss(Message > > > Processor.java:1226) > > OK, what's breaking things is the aforementioned 'Received: > from nobody' > header which as reported by the stack trace cannot be > resolved into a valid > host. > > Before I say categorically that this isn't a valid Received: > header and is > correctly rejected, I will check the relevant RFCs. This > isn't going to > happen today as I'm off to destroy a few brain cells in a far more > entertaining way.
My reading of RFC 2821, Section 4.4 indicates the received header in question is syntactically valid, but not recommended. It "SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection". This received header only contains the name of the source host as passed by the EHLO or HELLO command. We have two issues: 1) The name of the source host presented by the client is not resolvable to an Internet Address, which is invalid by my reading. 2) The IP address is not being added by the server kayako.lunarpages.com, which is not helpfull. Fetchmail uses this information to determine the address of the MTA that sent the message to the POP3 servers's MTA. This is used to allow blacklist checking, etc, by the James Mailets. As lying about the name of the source host is a favourite trick of spammers, fetchmail does not let such mail with unresolvable source hosts get through unless: a) The "address literal containing the IP address of the source, determined from the TCP connection" is present. This is always used in preference to "the name of the source host". b) The check is disabled by setting parameter remoteReceivedHeaderIndex to -1. But then all mail will have the source IP set to localhost and blacklist checking is effectively disabled. If fetching all your mail is more important to you than rejecting spam you could disable the check, otherwise you may want to persuade lunarpages.com to reconfigure kayako to add the IP Address to the received header. Is there anything fetchmail can do to handle this better? I'm thinking on this, all ideas welcome! -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
