Re: Email Forwarder's Protocol ( EFP )

At 01:52 PM 2/27/2005 -0600, you wrote:

> It's a catch-22. MTAs send DSNs to the envelope sender, but SPF mandates 
> that the envelope sender change.
> Four solutions (from easiest to most difficult):
>
> 1. SRS.
> 2. Store instead of forward.
> 3. Forwarder whitelisting.
> 4. Alter DSN/return-path behavior.
>
> RFC 2821 really botches up this whole return-path business.
I agree that section 4.4 of RFC 2821 is confusing on the handling of 
Return-Path information.  As I understand it, and as I think most SMTP 
agents do now, the MailFrom address ( for receipt of DSNs ) is set by the 
Source into the MAIL FROM command, and passed unchanged at each Relay using 
its own MAIL FROM command, until it gets to the Destination, where the 
original MailFrom address is copied into a Return-Path header.  Only one 
Return-Path header is allowed, and it should be added only by the SMTP 
server making the "final delivery".  If a message arrives at the final 
delivery server with a mistakenly added Return-Path header, that server MAY 
remove the header and add its own, with information from the last hop MAIL 
command.
> RFC 2821 return-path behavior:
>
> 1. Delete return-path headers.
> 2. Create a return-path header if you think you should.
> 3. Delete return-path headers.
> 4. Create a return-path header.
According to RFC 2821, "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 already present."  So a Return-path 
header might be added at some point in the mistaken belief that final 
delivery had been done, then removed and replaced when the message gets to 
its true final destination.
>  This makes no sense to me, whatever. It's like you put a letter in the 
> mailbox and when the mailman picks it up, he erases the return address. 
> Then, an intermediate post office writes a return address. Then, the 
> destination post office erases the return address and then writes one. 
> Then, when a delivery failure occurs, the letter is sent back to an 
> intermediate post office instead of the original sender.
> I think fixing this behavior is the best solution, albeit most difficult. 
> MTAs should send DSNs to the return-path and the return-path header should 
> be created by the originating MUA. The MSA may alter the return-path 
> according to local policy. Subsequent MTAs/MDAs should preserve the 
> return-path header already in place. Wow, that'll never happen.
SMTP was designed at a time when addresses weren't forged in 80% of 
email.  We probably need to keep things as is for DSNs, ( unless somehow 
they become a serious problem ).  What I would suggest is stating some 
different requirements for handling Bounces ( spam and backscatter 
).  Bounces should be considered a separate class from normal DSNs, and 
follow a "Bounce-path", authenticated at each hop, back to the responsible 
party.  Defining a new Bounce-path will not break existing systems, because 
bouncing spam to the Return-path has never been legitimate.
-- Dave


*************************************************************     *
* David MacQuigg, PhD              * email:  dmq'at'gci-net.com   *  *
* IC Design Engineer               * phone:  USA 520-721-4583  *  *  *
* Analog Design Methodologies                                  *  *  *
*                                  * 9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.             * Tucson, Arizona 85710        *
*************************************************************     *

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription, 
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com