[ http://issues.apache.org/jira/browse/JAMES-344?page=comments#action_57372 ] Danny Angus commented on JAMES-344: -----------------------------------
The important factor here is that by supporting non-compliance we are eroding the value of the very standards upon which interoperability relies. We are in danger of encouraging a situation in which true interoperability is not only dependant upon clear standard behaviour but also upon undocumented variance from those same standards. The James policy for issues of non-compliance tries to tread the fine line between a pragmatic acceptance of other people's misinterpretation of the RFC's and an evangelical enforcement of "the letter of the law". In practice this policy is that certain well argued of cases of non-compliance which can be *safely* worked around, will be tolerated by James. In cases (like this one) where variance from a published standard is required it is desirable that this functionality is disabled by default, well documented, and only enabled by explicit configuration. In cases where the behaviour is not within the scope of any standard which James claims to support (such as behaviour which is a defacto standard or proposed RFC but not yet subject of an RFC in standards track) it is acceptable to implement the behaviour so long as it is adequately documented and users can be clear about what to expect from James. > FetchMail cannot parse particular format of "Received" header > ------------------------------------------------------------- > > Key: JAMES-344 > URL: http://issues.apache.org/jira/browse/JAMES-344 > Project: James > Type: Bug > Components: FetchMail > Versions: 2.2.1 > Reporter: Jeff Keyser > Priority: Minor > > The mail server I am pulling e-mail from inserts a "Received" header that > looks like the following: > Received: from unknown (HELO host.domain.tld) (192.168.255.254) by ... > BTW - The name "unknown" is always used. I assume they are purposely saving > processing power by not reverse-looking up the host name. > I have debugged this problem in the code, and it appears that because the IP > address is not surrounded by square brackets, computeRemoteAddress is unable > to find the IP address. So the name "unknown" is always used to determine > the address instead, which fails. > FYI - The e-mail I am pulling actually passes through two e-mail servers by > different organizations, and they both use this format. So I assume this > format is common. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
