At 07:14 PM 2/22/2005 -0500, Stuart Gathman wrote:
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.
Bouncing the way they always have is no good, because return paths can be
forged, Received-SPF headers can be forged, anything can be forged except
the IP address of the immediately previous forwarder. By bouncing only to
that address, we don't need to depend on the headers.
> 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.
We can't continue the way we always have. Too many bounces are going to
forged addresses.
We need forwarders to authenticate their senders, by whatever protocol they
want, but it must be done while they still have the sender's IP
address. Then we need
a simple, non-controversial standard for how forwarders should communicate
the results of their authentication. It looks like SPF/SRS has been
stalled. When Microsoft comes out with SenderID, no doubt there will be
efforts to stall it. Either method will work, but neither will work if
forwarders and receivers using different protocols can't communicate. We
need to find some common ground, some simple format for just the essential
items that are necessary for any method. Then things will start to move again.
I would both sides to review the requirements once more, then look at the
proposed standard and let me know if something is missing, or if something
will make life too difficult for their preferred method.
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmq at gain.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