On Fri, 6 Apr 2007, Scott Kitterman wrote:
Because it can be validated out of band via SPF by comparing the connect
IP to the SPF record for the alleged domain in AUTH=. Without AUTH=,
you have to consult a list of possible forwarders, validating each one
(or compiling to IP sets with TTL). AUTH= just saves time by telling
you which forwarder domain to validate. Note that you would *still*
check that the domain is in the list of authorized forwarders.
This of this application of AUTH= as providing the real MAIL FROM
to validate instead of the forged MAIL FROM. This is similar
to SRS, except that bounces go to the original sender instead of
the forwarder.
But then it still comes down to reputation. Unless I have a whitelist of
forwarders that I trust, it could be any random forger using this protocol.
While I can see that this might save overhead for the receiver (it's a
smaller lookup list), I don't see how it fundamentally changes anything?
I don't think receiver table lookup efficiency is enough to drive a new
protocol deployment.
In my small office deployments, I can get by with 2 or 3 forwarders
in a list, and check SPF (the "pretend" domain approach) for each one for every
connection (stuff will be cached, so it's not that bad). However, a large ISP
with millions of users and tens of thousands of forwarders can hardly
use this approach. Having a specific domain to validate is essential
for forwarder whitelisting.
However, there could also be a small list for each user, with SPF checks
delayed until RCPT TO.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735