Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
Spam is about filtering bad guys. RMX is about labeling good guys.
Hence, with RMX, you still know nothing about bad guys.
I don't quite agree.
How does it help to control spam if you continue to know nothing about
the bad guys?
Right now, we have a pool of SMTP originators. The pool contains
both good guys, and bad guys. It's difficult and expensive for any
recipient to distinguish between them.
With tools like RMX, a recipient can easily seperate the pool into
"accountable" originators, and "unknown" originators. This means that
the bad guys are more likely to be marked as bad guys, and the good
guys less likely to be so marked. While this doesn't give you direct
information about the bad guys, it does give you indirect information:
They're not the good guys.
In summary, RMX allows us to increase our confidence in the marking
probability for bad guys.
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 don't see why. Run spam assassin, and for messages from RMX
systems, set the "spam" threshold high, so that it's more forgiving.
For messages from non-RMX systems, set it low, so it's less forgiving.
Maintaining two numbers shouldn't be difficult for a seasoned system
administrator.
On the modern Internet, all of the mail posting semantics are achieved
with SMTP.
That's nice, but it leads me to a few questions:
- What changes, if any, may be made to a recipient MTA or MUA, in
order to fight spam?
- What changes, if any, may be made to an originating MTA or MUA, in
order to fight spam?
From what I can tell, your answer to the second question appears to
be "None". If the answer to the first question is also "None", then
I don't see why we're pretending we want to solve the spam problem.
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?
No... I'm saying that mobile users can today choose methods other
than SMTP for sending mail. They're ugly, they're awkward, but
they're also proven to work for thousands of people.
And as someone who's inundated with spam, I have *no* problem with a
local site policy saying "people who lie about their originating
domain go into the bit-bucket with the spammers." That's my
perogative, and I believe that with systems like RMX, many recipient
MTA's will be making similar choices. Mobile users who refuse to use
VPN's will then discover that most of their mail gets bounced.
By way of seeking something constructive out of this, would someone who
believes there are viable alternatives to SMTP
I believe there are viable alternatives to naked, un-accountable
SMTP for mobile users. VPN's, authenticated relaying, etc., all
exist, and are in wide-spread deployment.
What I'm missing about the "mobile user & naked SMTP" problem is
why, as the recipient of such email, it's *my* problem to filter out
mobile users from the spammers who use similar methods. Is it really
that difficult or contentious to ask mobile users to use a VPN?
-- and that they will
a) solve or at least reduce the spam problem,
Allow MTA's to verify the originator of the email?
b) match SMTP's functionality, and
SMTP over a VPN seems to be a good solution.
c) stand some chance of being adopted by the Internet's 100 million
users
Companies are selling these solutions today for mobile users, and
are making a living at it.
please put forward a technical specification of this "viable"
alternative, so that it moves from a general idea into something
concrete.
I'm not proposing that we scrap SMTP. But I still haven't heard
reasons why naked SMTP is the ONLY possible method for mobile users to
send email. Alternatives exist today, and are in wide-spread
deployment.
Alan DeKok.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg