Alan,
so, what is the real utility of the rmx record?
AD> Umm... you have more information with which to make better
AD> decisions? That doesn't seem like a bad thing.
Spam is about filtering bad guys. RMX is about labeling good guys.
Hence, with RMX, you still know nothing about bad guys.
How does it help to control spam if you continue to know nothing about
the bad guys?
that is, what can you safely do, versus not do?
AD> For RMX systems, you can safely be more liberal in filtering
AD> messages, because you have some level of confidence that any spam
AD> coming from RMX systems will be traceable and accountable. That
AD> doesn't seem like a bad thing to me.
What does this mean, exactly? A different set of filters for RMX-based
mail? The idea of maintaining two rulesets is a bit daunting. Seems
unlikely to scale.
AD> Are there NO other methods which a mobile user may use to send mail?
no.
AD> I disagree most strongly.
AD> SMTP is only one of many protocols used to send/receive email.
interesting. i believe there are no others. ("submit" is simply smtp on
another port.) which ones are you referring to?
AD> Some people have posted other alternatives.
no they have not.
On the modern Internet, all of the mail posting semantics are achieved
with SMTP.
The "alternatives" presented were for alternative lower layers, or for
extremely limited email protocols that will never gain large-scale use.
(They have been around long enough to demonstrate this limitation
clearly.)
AD> An additional one is
AD> mail via a web interface.
oh boy. now you are going to propose an array of non-standard user
interfaces as an email posting protocol?
methinks we have left the world of technical discussion of spam control.
the work here needs to be about protocols.
AD> The feeling I get here is the same from everyone who's requiring
AD> that mobile users be allowed to send SMTP traffic to any port 25 on
AD> the planet, and to pretend to come from any domain. They're adamant
AD> that that's the ONLY way they can send mail from remote sites, and
AD> that there are NO other workable alternatives.
...
AD> I'm at a loss to respond to such a position. It's so trivially,
AD> obviously wrong, that I'm left wondering what I'm missing.
You are over-interpreting my statements. They were written carefully.
Please read them the same way.
By way of seeking something constructive out of this, would someone who
believes there are viable alternatives to SMTP -- and that they will
a) solve or at least reduce the spam problem,
b) match SMTP's functionality, and
c) stand some chance of being adopted by the Internet's 100 million
users
please put forward a technical specification of this "viable"
alternative, so that it moves from a general idea into something
concrete.
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