On Tue, 22 Feb 2005, David MacQuigg wrote:
This will work, but perhaps with some difficulty. As long as you pass on
the essential information in a header ( protocol, IP address, domain-name,
result ), the receiver can figure out where to send the bounce, the
forwarder that gets the bounce can dig deeper into the headers and figure
out where to forward the bounce, etc. The difficulty comes when your
receiver does not understand the Received-SPF header, because it doesn't
implement SPF. A header with the items essential for any protocol in a
standard format would allow any receiver that follows the standard to
generate a bounce.
Checking SPF doesn't have any effect on bouncing (by which I assume
you mean DSN via the null sender aka MAIL FROM <>). Neither does adding a
Received-SPF header. Any recipients down the line bounce just the way they
always have using the return path. SPF does not alter the return path,
it just validates it when an SPF record for the domain is present.
Are we in agreement that bounces may come *after* a forwarder's SMTP
session is closed? To repeat my earlier statement: A bounce might come as
late as several hours, when the recipient hits a "Reject as Spam"
button. That reject should be treated as a "bounce" and follow
authenticated addresses all the way back to its source.
Sure, but what does this have to do with SPF? Are you thinking of SRS?
Again, with SRS, recipients down the line bounce just the way they always have
using the return path.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.