Home page logo
/

nanog logo nanog mailing list archives

Re: Fun new policy at AOL
From: Matthew Crocker <matthew () crocker com>
Date: Thu, 28 Aug 2003 13:41:54 -0400



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>


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault