On Sat, 5 Jan 2008, you wrote:
That's essentially the same as "database-backed SRS" as described in [1],
section 2.10. A "sham SRS" database would merely map origin addresses to
forwarder-domain addresses and vice versa.
Not really. In Sham SRS the second-leg MAIL FROM does not change for
different first-leg MAIL FROMs. So there's nothing to key the database from.
A constant second-leg MAIL FROM is advantageous since it allows the ultimate
recipient forwarder to whitelist the forwarder. While whitelisting will no
longer be needed to avoid SPF FPs, the recipient will still have to do it,
because the forwarder will react to a single 5xx by suspending the forwarding
service....
Heh, that's a novel idea! But handling bounces actually isn't a problem
as long as you have a _two-way_ mapping between origin addresses and
forwarder-domain addresses.
Recovering the original MAIL FROM after rewriting it isn't the problem. The
problem is that the original message may itself have been forged, in which
case bouncing may earn the forwarder a backscatter blacklisting.
In theory, the forwarder could protect himself from this by rejecting on SPF
Softfail, None, and Unknown status (in addition to Fail, of course). But
that's not reasonable in practice.
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=82158542-aa5483
Powered by Listbox: http://www.listbox.com