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: [EMAIL PROTECTED] Received: from mail.cfpros.com (65.218.70.100) by squish with POP3 for <[EMAIL PROTECTED]>; 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) ([EMAIL PROTECTED]) by 0 with SMTP; 26 Feb 2004 23:45:57 -0000 Message-ID: <[EMAIL PROTECTED]> Date: Thu, 26 Feb 2004 17:35:33 -0600 From: James Thornton <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] Subject: test return path Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RCPT-TO: <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
