On Tue, 16 Jan 2007, Jeremy Harris wrote:
it only saves you from backscatter if you *don't* use SRS.
I'm not speaking to that point.
And you don't need to. With the stunt and no SRS, indeed you don't have
to worry about backscatter. Of course you'll still have low deliverability
if the recipient is an SPF hardass...
Under SRS, if the recipient backscatters, the bounce goes to the
SRS-transformed address, and then the forwarder has to relay it. As far
as his IP reputation goes, it will be just as if he was the backscatter
emitter.
Irrelevant. I don't care about the recipient backscattering. I care
about him rejecting. By working synchronously you can avoid, as
a forwarder, being a backscatter source yourself when a next-hop
(final, in this case) rejects.
But what will happen, if you use SRS, is that the recipient will accept
the DATA, so you'll accept the sender's DATA. All seems well at first.
Then, 100 seconds later, you get an email -- MAIL FROM: <>, RCPT TO:
<SRS0=123=45=uceprotect.org=spamtrap>. The recipient has backscattered.
(Assume the hash and timestamp were valid). What do you do?
If you relay the bounce as SRS specifies, UCEPROTECT will hold you
accountable for the backscatter, even if on one level it wasn't your
fault.
(And if you aren't actually going to relay the bounce, much of the
complexity of SRS becomes pointless.)
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
-------
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