Re: modifing PEAR Mail so we can use return paths

From: Date: Tue, 27 May 2003 08:00:19 +0000
Subject: Re: modifing PEAR Mail so we can use return paths
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-16742@lists.php.net to get a copy of this message
On Tue, May 27, 2003 at 11:39:23AM +1000, Alex Hayes wrote: > Perhaps this has already been suggested (or perhaps im going down the wrong > path.....?), however I couldnt find anything on the dev mailing list.. > > I think that there can be changes made to the PEAR's Mail class(s) that > would allow people to define the Return-Path properly without it being > overwritten as the From path as currently happens. > > The Return-Path doesnt get used properly. This is because the implementation > of the mail classes IE. Mail/sendmail.php overwrite the return path by using > the -f argument, as follows... And this is the right behaviour IMHO. If you want people to reply to another address than specified in From: header, then use Reply-To:. If you want receive error messages under different location - use -f$different_email According to RFC 2076 (section 3.2): Used to convey the information Return-Path: RFC 821, from the MAIL FROM envelope RFC 1123: 5.2.13. attribute in final delivery, when the message leaves the SMTP environment in which "MAIL FROM" is used. According to RFC 2821 you even SHOULD NOT add any Return-Path header, and even if you do - SMTP server can overwrite it with MAIL FROM address. 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. Best regards, -- Piotr Klaban

« previous php.pear.dev (#16742) next »