ietf-asrg
[Top] [All Lists]

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

2003-03-17 08:15:16


-----Original Message-----
From: asrg-admin(_at_)ietf(_dot_)org 
[mailto:asrg-admin(_at_)ietf(_dot_)org]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 ;-)
...
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.

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? ;-)

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.

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.

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!"

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).



_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>