I'm looking at the Feb 12 version of your SRS paper. In §2.7 you pose
the question 'What do we actually _need_ in order to forward a mail back
to B yet make sure A never receives a spam?'
What you don't seem to consider is the possibility of forwarding
unwanted message directly to victim B.
It should be noted that the shortcut scheme _does_ open you up for
relaying, albeit in a limited fashion. If you receive a mail to...
SRS1+victim(_dot_)com+HHH+TT+anywhere(_dot_)com+user(_at_)yourdomain(_dot_)org
...then surely you'll send it on to...
SRS0+HHH+TT+anywhere(_dot_)com+user(_at_)victim(_dot_)com
...without performing anything but the most basic syntactic checks or
maybe checking the timestamp.
I'm slightly confused as to why we bother with the multi-stage rewriting
at all. Note first the following two observations:
1. It's pointless rewriting the sender address if your host was
a permitted sender for that domain _anyway_.
hence 2. It's pointless rewriting the sender address if the original
sending domain isn't publishing SPF records.
That being the case, surely it makes sense to use a domain for SRS which
doesn't have SPF records, so that none of your SRS0+.... addresses will
even _need_ a second rewrite, and no global convention is required for
such rewrites.
For example, my implementation (http://www.infradead.org/rpr.html)
rewrites to some localpart @rpr.infradead.org, and there's no need for
anyone else to perform _further_ rewrites on that sender address because
I don't publish SPF records for the rpr.infradead.org domain¹.
In doing so, we avoid the need for multiple rewrites completely, and
hence we also avoid the need for the problematic shortcuts.
--
dwmw2
¹Actually I don't publish them for infradead.org yet anyway but I plan
to, as soon I feel as I've given the users sufficient time to object to
the stated plan and/or start using SMTP AUTH.