I'm thinking that we need to proceed in a slightly different way.
We can focus on filters on the short term because they have immediate
effect. That should buy us some time for us to get a better protocol
implemented.
I think we also have the option of taking ALL proposals and running with
them at once. All we need is an interop spec that will allow the receiving
server to dictate how mail is delivered to it. This would have the effect of
de-universalizing spam methods. Even though there are a variety of SMTP spam
techniques, they all fall under SMTP. If we have some servers that use
verification, while other use certs, other use some hash hand shake, and
other may use dcc, etc. we raise the barrier to entry for spamming while
giving each method a chance to 'do it's thing' and compete (and thrive if it
does well). Eventually we'll be able to see which ones work best.
SMTP is a protocol that not only tells how you get in the door, but it also
takes you through the door. I'd like to separate that out and come up with a
meta transfer protocol if at all possible. It'll enumerate the accepted
methods for delivery, and how to do them.
True, this will complicate things for everyone, but in the end the spammers
will suffer the most. Admins should be able to handle the complexity of what
I'm suggesting rather easily. We may very well come up with a super server
what supports every variation of mail delivery protocol known to man, and
have the receiver use only the 'best' few. For now {SMPT; sender validation;
DCC} would be the accepted list. The goal here is to eliminate SMTP, and
maybe add more advanced protocols. This would allow interop and
experimentation on the living 'net.
I imagine an FTP like system where control goes over a connection, and data
over the other. Once the receiver is satisfied on the control connection, he
can start reading from the data socket. Also, the control connection could
be a daemon that proxies out delivery daemons. That probably made no sense,
so here it goes: A control daemon runs. Also running is an SMTP and DCC
daemon. The control daemon does his thing and then when it comes time to do
the actual data transfer, we can have it hand-off to the running daemon.
This would make transfer daemons plug-able at runtime and eliminate the need
for a server-all-in-one server implementation.
What this does is makes the spammer have to craft his methods for each mail
server, and each technique. Hopefully he can't be everything at once.
The control daemon should negotiate the preferred method of transfer. For
now, this is good ol' SMTP. But people who want to eliminate spam can run
whatever type daemon they want and if the receiver supports it, and use that
protocol. Eventually (5 years, 10 years, whenever) we can drop SMTP once
we've seen what each system does to the flow of spam. The market will be
able to decide what is best, rather than those with the loudest marketing
teams.
This allows slow adopters to interop while those motivated to kill spam can
do something. Then they can peer pressure everyone else into dropping SMTP.
In the short term, we need only to push to have this daemon running.
Hopefully this is one area where fragmentation can be put to good use. The
admin can run 1, 3, or 20 mail delivery systems.
Here's one issue I see. Spammers will be able to adjust their 'attacks' to
exploit the negotiated method. Solution: keep inventing new methods (or
adjusting the current one if there's room) until we stumble across the right
one(s). Right now this is unheard of because SMTP is hard-wired in, but it
doesn't have to be ;-)
Here's the other issue: If spammers are given a choice they will negotiate
to the easiest method for them to use. We need some sort of penalty for not
using the preferred method. Maybe a tar-pit(s)? (Tar proxy the non-preferred
daemons)
Comments?
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg