Subject: [Asrg] The proposal to end all proposals ;-)

From: Jason Hihn <[email-masked]>
Date: Fri, 14 Mar 2003 09:58:08 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 14 Mar 2003 18:23:36 -0500

>does well). Eventually we'll be able to see which ones work best.

I ran some large mailing lists back in the 80's.  It was not fun. 
Just managing the bounces was hell.  To remind me of this fact I keep 
two books around from those days.  Both books describe how, if you 
are using mail system x and network system y, you can construct a 
message to get to someone on mail system a and network b.  Two whole 
books.

What you describe would take us back there.  Furthermore, it is 
exactly that fragmentation that is keeping anyone from investing in a 
new architecture--there's too big a risk that some other system will 
win out.

This sounds way too much like "I know, let's make it impossible for 
anyone to talk to each other.  *That* will stop the spammers!"
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Jason Hihn <[email-masked]>
Date: Mon, 17 Mar 2003 10:03:57 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Kee
> Hinckley
> Sent: Friday, March 14, 2003 6:24 PM
> To: Jason Hihn
> Cc: Asrg
> Subject: Re: [Asrg] The proposal to end all proposals ;-)
...
> message to get to someone on mail system a and network b.  Two whole

I have no idea what I suggested has to do with mailing lists and bounces.
Furthermore, there is nothing that says our x's,y's,a's and b's are the same
as in the book. Two books? Maybe the author was just long winded? ;-)

> new architecture--there's too big a risk that some other system will

Indeed. But what you fail to see is that fragmentation is good, as long as
it's compatible. When it's trivial to replace your protocol and maintain
backwards compatibility, then there's no risk.

We all are running a really spam-happy protocol, SMTP. It can't be fixed
without some modification. Something will have to be done about it. What I
suggest is that we all stop running SMTP universally, and penalize those
that run it.

> anyone to talk to each other.  *That* will stop the spammers!"

What I am suggesting is no more complicated than two modems negotiation what
protocols to use. Lets do a sample:

S: I have mail for you, what are your protocols?
R: sender_vfy,1; site_cert,2; smtp,3; (protocol,preference)
S: (checks his own capabilities) sender_vfy
R: (applies penalties applicable at the time) ok (or "ok, port#")
S: {message}
R: {passes message off to sender_vfy daemon)

I don't see what is so hard about that! Then people can run multiple
protocols, and negotiate the preferred one of the site. This will eliminate
the problem of needing everyone to commit to a new protocol and needing
significant adoption of it. Furthermore, protocol revisions are much easily
tolerated (ex.: sender_vfy_99b,1; sender_vfy_99a,2; etc)

Also configurable are penalties. The preference number can also carry with
it a penalty: speed or filtering. For the time being, everyone will need to
run SMTP, but we can penalize it with a tar proxy or something of the sort
while letting less spam happy protocols thrive.

A picture is worth a thousands words, so here's a sample config file:
#negotiator config file
protocols{
    sender_vfy_99a {
        daemon_port=35423
        preference=1
    }
    sender_vfy_99b {
        daemon_port=35422
        preference=0
    }
    smtp {
        daemon_port=25 #tar proxy runs here
        preference=100
    }
}
preferences {
    0,1 { }
    100 {
        filters {
		fail_on 1  #(as opposed to 2, 3, or all)
		pre_delivery{
	            ip_blacklist
			ip_whitelist
		}
		post_delivery{
	            word
      	      sender_blacklist
            	crc_blacklist
			sender_whitelist
		}
        }
	  actions {
		pre_delivery_delay 2 #two second fixed delay
       }
    }
}
#end of file

What this also allows us to do is wrap SMTP (and other protocols) with
enough armor that it might not suck so much.

If we are ever to replace SMTP, I don't how we can't afford to not have this
software function!

In case I wasn't clear, I'm only suggesting that we replace the equivalent
of the transport layer, not the application, network or media. sender_vfy
can be SMTP at the core (application layer) for all I care (it probably has
to be anyway).