RE: [Asrg] seeking comments on new RMX article

["Eric D. Williams" <[e-mail]>]

On Monday, May 05, 2003 11:06 AM, Dave Crocker [SMTP:[e-mail]] 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg