Re: Fun new policy at AOL

[Matthew Crocker]

On Thursday, August 28, 2003, at 12:25 PM, Valdis.Kletnieks@vt.edu 
wrote:

> On Thu, 28 Aug 2003 12:00:29 EDT, Matthew Crocker said:
>
> > How does this sound for a new mail distribution network.
> Only a few problem here:
>
> 1) Bootstrapping it - as long as you need to accept legacy SMTP because
> less than 90% of the mail is being done the new way, you have a hard 
> sell
> in getting anybody to go to the effort of buying in.
Play with DNS MX records like QMTP does.

Something like

crocker.com		IN	MX		65000  trusted-mx.crocker.com  # Trusted 
connections are tried first
				IN	MX		66000  untrusted-mx.crocker.com # untrusted are tried second.


untrusted-mx.crocker.com accepts mail from everyone just as regular 
SMTP works today.
trusted-mx.crocker.com uses DNSRTTL (Real Time Trust List) to only 
accept connections from IPs it trusts.
ISP runs an internal DNSRTTL list and/or there is a Internet wide list 
of trusted ISPs

sending mail server knows the rules, attempts to connect on 
trusted-mx.crocker.com  If accepted it uses its private key to sign a 
message.  If not, resort to the untrusted-mx.crocker.com host
trusted-mx.crocker.com looks up the IP in its RTTL (Real Time Trust 
List), accepts the connection and using DNS pulls the public key of the 
sending mail server.
trusted-mx.crocker.com validates the signed message using the public 
key and accepts the mail.

Current SMTP traffic (untrusted) tries to connect to 
trusted-mx.crocker.com which rejects the connection so it tries the 
next higher MX record (untrusted-mx.crocker.com)

You could have several RTTLs on the network maintained by certain 
people (Paul Vixie ??, AOL, etc).  ISPs can use their own and/or one of 
the Internet ones.
ISPs need to request access to an RTTL by the maintainer and needs to 
meet requirements of that RTTL.  Each RTTL could have different/more 
strict rules to gain access.

As more and more ISPs join the RTTLs more traffic is handled by the 
trusted mail servers.  ISPs can file a formal complaint if spam is 
coming in from a trusted source.  They can either block them internally 
or petition to have them removed from the RTTL.  ISP always has the 
option of not using a specific RTTL and forces the traffic back to 
untrusted.

The untrusted mail server starts getting less and less traffic.  More 
and more messages are marked as SPAM/auto deleted.  Untrusted is always 
available but starts off with a very high spam score.  ISP customers 
can choose to accept mail from untrusted mail servers if they want with 
some easy procmail scripts (if Recieved by header has 
untrusted-mx.crocker.com, put in SPAM folder)

All of the technology is in place today.  Just need to reverse the RBL 
to become an RTTL

Maybe I should write up an IETF-draft.  Anyone want to help me with 
that?

Seems pretty simple to me, It can be implemented today without 
affecting existing mail servers.


> 2) Feel free in working out arrangements with 4,000 other ISPs, or 
> getting
> stuck with a provider.  You thought it sucked trying to get a route 
> announced
> for multihoming, this is going to be a lot worse.
No need to do that.  Just establish a couple RTTLs and have ISPs 
register/validate themselves with the RTTL.  Once in the RTTL they 
would be trusted by everyone using the RTTL.  Access to an RTTL 
requires that the ISP meet certain specifications.  Develop a '10 
commandments of mail serving'.

1. Thou shall not relay
2. Thou shall not distribute viruses more than 1 day old
3. Thou shall not distribute UCE
4. Thou shall not covet thy neighbors mail server

...



> 3) Go read up on why ADMD/PRMD sucked in X.400 (hint - see (2)).
> <mime-attachment>