On Sun, 22 Feb 2004, David Woodhouse wrote:
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.
You're quite right and quite wrong. At this stage, we don't even check the
timestamp. However, if victim.com is an SRS compliant host, then it will
drop the mail because the hash is invalid, and if it isn't an SRS
compliant host, then that address probably won't exist anyway, so it's a
non-issue. Since the host victim.com will drop the mail either way, this
is simply a very ineffective denial of service, and will probably fail
miserably at that as well.
I think you should reread the sections in the documents which describe the
games played by the various spammers. For an enjoyable introduction to
gaming, I suggest "The Game's Afoot" by Alexander Mehlmann.
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_.
But we lose nothing by applying SRS, so it makes no difference either way.
We might as well save the complexiy of checking SPF during SRS.
hence 2. It's pointless rewriting the sender address if the original
sending domain isn't publishing SPF records.
But we lose nothing, so it doesn't hurt. Why should we tie SRS to SPF? We
gain nothing from doing so. They are independent solutions.
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.
It it is a general assumption in the case of SRS that any responsible
administrator will publish SPF records. The following assumption is that
any spammer will check for SPF records before attempting to abuse a
domain. There is no point leaving a sitting target just because it allows
us to use a different RPR scheme.
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¹.
You are relying on the fact that there are no SPF records for your rpr
domain. In the indefinite future, it may become so that those domains
which do not publish SPF records are usually spamhausen or being exploited
by such, since any administrator who wishes to protect the image of his
domain will publish SPF records. Other than that assumption, your proposal
seems to differ from SRS only in that it does not explicitly support
multiple hops, and will cause the length of the local-part to increase
well beyond the 64 byte limit, probably at the first hop.
The comments at the bottom of that page need some clear and sincere
justification, rather than just a "proof by divine intervention" or "proof
by hint to the reader". In order to make it fly, you must explain:
* How to use the guarded SRS system as an open relay (not the basic flaw
in the preliminary shortcut system, which is explained in the paper).
* How your proposed RPR system is invulnerable to joe jobs.
* How your proposed RPR system deals with multiple hops.
I would be EXTREMELY interested in these explanations, since this is the
stage when we have to fix all of these problems.
Thanks.
S.
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/