[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tmda-users
Subject:    Re: TMDA, getmail, qmail-inject => wrong return-path
From:       James Thornton <james () jamesthornton ! com>
Date:       2004-02-29 3:44:21
Message-ID: 40416015.1060209 () jamesthornton ! com
[Download RAW message or body]

Jason R. Mastaler wrote:

> The getmail FAQ has an entry discussing this.  See 
> ``How do I use TMDA with getmail?'' at
> http://www.qcc.ca/~charlesc/software/getmail-3.0/faq.html

TMDA requires that the remote SMTP server inserts a Return-Path: header,
as per the SMTP standard, RFC 821 (http://www.ietf.org/rfc/rfc0821.txt
pp. 21/22), and clarified in RFC 2821
(http://www.ietf.org/rfc/rfc2821.txt), section 4.4, Trace Information.
Unfortunately, not all SMTP servers do this.

How are others dealing with this problem?

Here is are example headers from an e-mail from an IMail server after it
had been retrieved with getmail, and its void of the Envelope-Sender in
the header:

Delivered-To: postmaster@squish
Received: from mail.cfpros.com (65.218.70.100) by squish with POP3 for
<postmaster@squish>; 26 Feb 2004 23:38:12 -0000
Received: from roam.unifiedmind.com [209.164.72.58] by wwip1
(SMTPD32-8.04) id A31185022E; Thu, 26 Feb 2004 17:36:49 -0600
Received: (qmail 21744 invoked from network); 26 Feb 2004 23:45:57 -0000
Received: from unknown (HELO jamesthornton.com) (james@66.143.167.86)
by 0 with SMTP; 26 Feb 2004 23:45:57 -0000
Message-ID: <403E82C5.806@jamesthornton.com>
Date: Thu, 26 Feb 2004 17:35:33 -0600
From: James Thornton <james@jamesthornton.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4)
Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: test@cfpros.com
Subject: test return path
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-RCPT-TO: <test@cfpros.com>
Status: R
X-UIDL: 377596421

--

I asked the IMail forum about this, and they replied:

"This was discussed briefly about two years ago on this list, and the
upshot was thus:

- IMail's SMTPD does indeed preserve the envelope sender (RFC
<reverse-path>) after the messages leave the SMTP world, in the From
delimiter in the mbox file. It is not necessary to reflect the info in
a Return-Path: _header_, so IMail is thus RFC-compliant.

- The <reverse-path> so provided is viewable in any mail client that
can read the mbox files natively. The <reverse-path> is, however, no
longer viewable when the messages are downloaded using POP3D.

So the answer is that Imail is not, strictly speaking, RFC-wrong, but
does not go out of its way to be right."

I persisted citing RFC 2821, "This use of return-path is required; mail
systems MUST support it", but it appears that IMail isn't going to fix
it. They are saying that RFC 2821 is not a standard, SMTP RFCs have
nothing to do with POP3, and do not dictate client behaviors.

What's the best workaround?

Thanks.


-- 

  James Thornton
_____________________________________________
Internet Consultant, http://jamesthornton.com

_____________________________________________
tmda-users mailing list (tmda-users@tmda.net)
http://tmda.net/lists/listinfo/tmda-users
[prev in list] [next in list] [prev in thread] [next in thread]