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 "Ralph B Holland (JIRA)" <se...@james.apache.org> on 2010/01/01 05:00:29 UTC
[jira] Issue Comment Edited: (JAMES-344) FetchMail cannot parse
particular format of "Received" header
[ https://issues.apache.org/jira/browse/JAMES-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795730#action_12795730 ]
Ralph B Holland edited comment on JAMES-344 at 1/1/10 4:00 AM:
---------------------------------------------------------------
THis parsing issue is also causing problems for me from my POP3 server.
I found RFC 5321 which states that the Received: field is a TRACE field. It was added for debugging, the standard goes on to say that the field may not conform and that NO mail server should alter the format. I.e. expect it to differ from the standards.
That comment aside though, I notice in RFC5321 that an IP address is actually specified inside ( ) and not [ ].
I attach an example email header extracted by James fetchmail from my POP3 server, which is running windoze software at my ISP (who hosts my domain). Note the second header put on by my provider's email server canberranet.com.au. It is my belief that the ( IP address ) is a commonly found in the Received: field.
Return-Path: <qd...@palace-furniture.co.uk>
Delivered-To: ralph@localhost
Received: from canberranet.com.au (unverified [202.168.8.70])
by canberranet.com.au (SurgeMail 3.7b8) with ESMTP id 76651460
for <xx...@arising.com.au>; Fri, 01 Jan 2010 14:28:16 +1100
Received: from unknown (HELO canberranet.com.au) (202.168.8.8)
by Mail-SeCure (envelope-from qdyunjbeea@palace-furniture.co.uk)
with SMTP; 1 Jan 2010 12:32:36 +1100
Received: from ll62-72-188-251-62.ll62.iam.net.ma (unverified [62.251.188.72])
by canberranet.com.au (SurgeMail 3.7b8) with ESMTP id 76642457
for multiple; Fri, 01 Jan 2010 12:36:46 +1100
X-Verify-SMTP: Host 62.251.188.72 sending to us was not listening
Date: Fri, 01 Jan 2010 01:34:55 +0100
Message-ID: <00...@ocutnqtp>
From: "Ruby Royale Online Games" <qd...@palace-furniture.co.uk>
To: <xx...@arising.com.au>
Subject: Great pokies and offers [spam]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Server: High Performance Mail Server - http://surgemail.com r=1325883893
X-Rcpt-To: <xx...@arising.com.au>
X-IP-stats: Incoming Outgoing Last 0, First 762, in=2251436, out=27829717, spam=0 Known=true
X-External-IP: 202.168.8.70
Status: U
X-UIDL: 1262316496.856_419757.mrmail2
X-fetched-from: mail.arising.com.au
was (Author: vh-ums):
THis parsing issue is also causing problems for me from my POP3 server.
I actually looked up the RFCs and found RFC 5321 which states that the Received: field is a TRACE field. It was added for debugging, the standard goes on to say that the field may not conform and that NO mail server should alter the format.
Further, the original RFC5321 permits an IP address to be contained within ( ). There is no mention of [ ] despite many headers containing the square brackets. So I probably need to search for a subsequent RFC to find where this [ .. ] comes from, but from my observations so far, the fetchmail parsing should also handle the round brackets.
I attach an example email header extracted by James fetchmail from my POP3 server, which is running windoze software at my ISP (who hosts my domain). Note the second header put on by my provider's email server canberranet.com.au
Return-Path: <qd...@palace-furniture.co.uk>
Delivered-To: ralph@localhost
Received: from canberranet.com.au (unverified [202.168.8.70])
by canberranet.com.au (SurgeMail 3.7b8) with ESMTP id 76651460
for <xx...@arising.com.au>; Fri, 01 Jan 2010 14:28:16 +1100
Received: from unknown (HELO canberranet.com.au) (202.168.8.8)
by Mail-SeCure (envelope-from qdyunjbeea@palace-furniture.co.uk)
with SMTP; 1 Jan 2010 12:32:36 +1100
Received: from ll62-72-188-251-62.ll62.iam.net.ma (unverified [62.251.188.72])
by canberranet.com.au (SurgeMail 3.7b8) with ESMTP id 76642457
for multiple; Fri, 01 Jan 2010 12:36:46 +1100
X-Verify-SMTP: Host 62.251.188.72 sending to us was not listening
Date: Fri, 01 Jan 2010 01:34:55 +0100
Message-ID: <00...@ocutnqtp>
From: "Ruby Royale Online Games" <qd...@palace-furniture.co.uk>
To: <xx...@arising.com.au>
Subject: Great pokies and offers [spam]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Server: High Performance Mail Server - http://surgemail.com r=1325883893
X-Rcpt-To: <xx...@arising.com.au>
X-IP-stats: Incoming Outgoing Last 0, First 762, in=2251436, out=27829717, spam=0 Known=true
X-External-IP: 202.168.8.70
Status: U
X-UIDL: 1262316496.856_419757.mrmail2
X-fetched-from: mail.arising.com.au
> FetchMail cannot parse particular format of "Received" header
> -------------------------------------------------------------
>
> Key: JAMES-344
> URL: https://issues.apache.org/jira/browse/JAMES-344
> Project: JAMES Server
> Issue Type: Bug
> Components: FetchMail
> Affects Versions: 2.3.0
> 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.
-
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