Fun new policy at AOL
Matthew Crocker
matthew at crocker.com
Thu Aug 28 17:41:54 UTC 2003
On Thursday, August 28, 2003, at 12:25 PM, Valdis.Kletnieks at 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>
More information about the NANOG
mailing list