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
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
in getting anybody to go to the effort of buying in.
Play with DNS MX records like QMTP does.
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
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
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
stuck with a provider. You thought it sucked trying to get a route
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)).