Hadmut,
Thanks for exploring my comparison in some detail.
ps. It strikes me that the RMX proposal is conceptually similar to the
old IDENT specification w
HD> IDENT was useless, because the peer machine itself gives any random
HD> answer. IDENT was useful as long as there were a few big UNIX and VMS
HD> machines where hundreds of users logged in but hadn't have root
HD> access.
Even then, it was not useful, because by the time it was proposed, there
were not a few big time-shared system.
However, the belief that it would have been useful under those
circumstances is based on the view that the administrator of the
timesharing system was independent of the person running the
applications AND that administrator could be expected to be trustworthy.
And therein lies the same, serious problem with RMX.
HD> In contrast, RMX doesn't ask the sending MTA, which could be the
HD> attacker, but a third party, which can be relied on since the query
HD> path doesn't depend on the incoming SMTP connection.
The reason that I refer to RMX as a point solution, rather than
something with a real potential for getting at the core of spam, is
because it "only" attempts to deal with From-field spoofing.
Spoofing is bad, but it is not at all the core problem with spam.
Spam is about content policies and author policies. RMX does nothing
about either of these.
Eliminate all spoofing and you are left with massive amounts of spam.
And, by the way, in the off-chance that RMX actually does achieve
wide-scale deployment, the folks who are currently doing spoofing will
simply move on to other techniques.
Note that there is nothing to prevent a spammer from hosting an MTA and
creating RMX records. They might not be able to do that for aol.com but
they CAN do it for a0l.biz, supposedly-honest.net, and an infinite
number of other domains.
Like IDENT, RMX relies on a model of strict, system-wide control.
Unfortunately, the diversity of the net means that it is essentially
impossible to enforce the kinds of controls that are required by such
proposals.
HD> Again, please inform yourself before posting.
I will return the favor, by suggesting that folks inform themselves
about the realities of Internet-scale operations, Internet-scale
deployment physics, and Internet-scale spammer adaptability.
Then, perhaps, we will not be presented with localized, near-term
proposals that will have no impact on large-scale, long-term spamming.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg