I took the info from RFC2821, which probably overrules 1123; http://rfc.net/rfc2821.html
Im curious how this would be achieved without setting the return-path: header previously: "It is possible for the mailbox in the return path to be different from the actual sender's mailbox, for example, if error responses are to be delivered to a special error handling mailbox rather than to the message sender. When mailing lists are involved, this arrangement is common and useful as a means of directing errors to the list maintainer rather than the message originator." Because setting the header previously is prohibited: "A message-originating SMTP system SHOULD NOT send a message that already contains a Return-path header. SMTP servers performing a relay function MUST NOT inspect the message data, and especially not to the extent needed to determine if Return-path headers are present. SMTP servers making final delivery MAY remove Return-path headers before adding their own. The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. For this to be unambiguous, exactly one return path SHOULD be present when the message is delivered. Systems using RFC 822 syntax with non-SMTP transports SHOULD designate an unambiguous address, associated with the transport envelope, to which error reports (e.g., non-delivery messages) should be sent." And then there's this which notes an error in RFC 822: "Historical note: Text in RFC 822 that appears to contradict the use of the Return-path header (or the envelope reverse path address from the MAIL command) as the destination for error messages is not applicable on the Internet. The reverse path address (as copied into the Return-path) MUST be used as the target of any mail containing delivery error messages." Count to that that imail doesn't handle return-path: headers as required by the RFC and I know for sure that I myself won't be messing with these headers. -- Regards, Terrence Koeman Technical Director/Administrator MediaMonks B.V. (www.mediamonks.nl) Please quote all replies in correspondence. - -----Original Message----- - From: [EMAIL PROTECTED] - [mailto:[EMAIL PROTECTED]] On Behalf Of Andy Schmidt - Sent: Friday, February 15, 2002 18:30 - To: [EMAIL PROTECTED] - Subject: RE: [Declude.JunkMail] Return-Path - proper use? - - - RFC 1123 (http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1123.html) - - "IMPLEMENTATION: The MAIL FROM: information may be passed as - a parameter or in a Return-Path: line inserted at the - beginning of the message." - - >> Allthough I don't see how the last server should acquire - the address - >> for - the return-path: << - - Well - it seems to me as if the last server has - responsibility to report back to the relaying server that it - was contacted from? So taking it from the MAIL FROM makes - sense. That's the SAME information the SMTP server would - use, if it needs to send a bounce message, such as "Mailbox Full". - - >> if it i desired that this address is different than the - Envelope from - >> or - the From: header. << - - But isn't the Envelope FROM supposed to be the "return path". - If we already have a header FROM: and header "REPLY-TO" for - client replies, and the Envelop FROM for server replies - why - do we need a forth? - - Best Regards - Andy Schmidt - - Phone: +1 201 934-3414 x20 (Business) - Fax: +1 201 934-9206 - - --- - [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". You can E-mail [EMAIL PROTECTED] for assistance. You can visit our web site at http://www.declude.com . --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". You can E-mail [EMAIL PROTECTED] for assistance. You can visit our web site at http://www.declude.com .
