Vernon Schryver <vjs(_at_)calcite(_dot_)rhyolite(_dot_)com> wrote:
Then why are we wasting our time in ASRG? Why not just give up, and
live with a broken protocol which is designed to be easily abused?
Again, it is not the protocol that is "broken" and "easily abused,"
but the design goal or problem statement.
So the SMTP protocol is designed with to have features that permit
it to be easily abused. SMTP servers are often implemented poorly,
which further enables abuse. So our design is broken, but the
protocol is OK. Hmm...
If you really think that SMTP is hopeless as protocol, then you
should certainly quit because this mailing list is not about tossing
the design goal of public mailboxes.
I fail to see how SMTP=="public mailboxes". SMTP permits public
mailboxes, but public mailboxes don't require SMTP. Is there no other
possible method of delivering mail? Do we lack sufficient imagination
to see how a protocol other than SMTP may yeild public mailboxes?
Maybe SMTP is perfect the way it is. Maybe we can tweak the
implementations and configurations of SMTP servers to eliminate the
spam problem. But I still don't understand why there is huge
opposition to even discussing solutions other than SMTP.
I would like to discuss how we would design a protocol and
implementation requirements for it which would be resistant to spam.
Maybe we'll discover that SMTP satisfies all of the requirements. But
when anyone mentions non-SMTP solutions, a number of people stick
their fingers in their ears and shout "la-la-la". This confuses me.
Maybe the list should be re-named to "asrg, but only within the
context of SMTP, and without changes to SMTP".
The "spam gain" obtained by using multiple Rcpt_To commands and an
open relay is much less valuable on the modern Internet.
Or local delivery? Where one spam message gets delivered to many
local users. This was a significant percentage of the spam traffic at
my domain, the last time I checked.
The "valuable optimization for MTAs hosting large mailing lists" is
a feature which directly contributes to the spam problem.
We could say similar things for IPSec: It's expensive for commodity
hardware to do 1,000's of simultaneous sessions on a VPN gateway. So
we make a "valuable optimization", and fall back to ROT13. Presto!
Cheap IPSec hardware, that runs quickly!
Sometimes the best thing to do is the expensive thing to do. But if
our requirements for "public mailbox" systems include "valuable
optimizations" that permit abuse, then we've failed even before we've
started.
A case study is the artauction/art-server/artserver/etc. spammer
that apparently uses much of a T3 to send millions of 5-8 KByte
messages, one SMTP session per spam target. He has been at it for a
long time.
"anecdotal evidence".
Alan DeKok.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg