-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of David
MacQuigg
Sent: zaterdag 26 februari 2005 1:50
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Email Forwarder's Protocol ( EFP )
We can then use the Received: headers for the bounce path instead of
bouncing directly to the forged Return-Path:. If the mail is legit,
sending it back along the bounce path will get it to the same
place as the Return-Path. If its a forgery, the bounces will stop where
they should, at the forger's domain, and not bother anyone at the
forged Return-Path.
The "Return-Path:" header is no more, nor less, fake than a "Received:"
header. Sendmail, for instance, has the H_ACHECK flag set for
"Return-Path:". This flag tells sendmail that it should always check the
mailer flags to see if the header should be included. If the mailer does
not include the appropriate flag, then sendmail will delete the header
when it delivers the message. Accordingly, sendmail will also set
"Return-Path:" itself (if the P flags is defined), regardless of what
existing header you feed it. "Return-Path:", holding <$g>, is therefore
exactly as reliable as <$g> found in the latest "Received:" header. They
are both added in H lines.
Bottom-line, if you trust the "Received:" header of your connecting MTA,
then you can also equally trust its "Return-Path:" header, if present.
So to make SPF work with forwarders, we don't need any new
headers, just a few more words in an existing, widely accepted header,
and an agreement on how forwarders should handle bounces.
An existing and widely accepted header is precisely a good reason not to
mess with it. :) Seriously, Received: headers should be left alone.
Forwarders should handle bounces the way they always have: using the MAIL
FROM entity at the SMTP dialogue stage.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx