On Monday, May 05, 2003 11:06 AM, Dave Crocker
[SMTP:dhc(_at_)dcrocker(_dot_)net] wrote:
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.
I think the premise is that RMX is about finding a method to give
accountability.
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?
Part of the 'spam' problem lies in accountability. I think the RMX proposal is
incremental toward that end and not a 'spam' control proposal. Some modicum of
'spam' control is I suppose a side-effect or benefit of RMX.
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.
I do not think scaling of RMX is overly burdensome but you raise an interesting
point via this argument. Would RMX be better served by an 'accountability'
extension that handles/gives feedback, concerning determinations based on RMX?
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.
I agree, SMTP has evolved into a ubiquitous transport between messaging systems
that use alternative (non-Internet) based local transports. In fact it could
be argued that SMTP has usurped many of those 'proprietary' transports to a
large degree.
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?
As I mentioned in a previous message, I think that is not the point which is
being proffered. I think there is congruence on the messaging transport idea
but where the element of mobility has been introduced there are different ways
to attack the mobility problem.
methinks we have left the world of technical discussion of spam control.
the work here needs to be about protocols.
I agree but where in the stack will it/they sit?
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
"c)" is/was a sticky point but I think you may agree that in the universe of
potential specifications at least X.400 at one point was a proposed candidate,
however interoperability being a key concern (among the implementors) and the
'testing' labs were a fait accompli on adoption and led to the ultimate demise.
At least as a message posting and transport scheme.
please put forward a technical specification of this "viable"
alternative, so that it moves from a general idea into something
concrete.
-e
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg