AOL rejecting mail from IP's w/o reverse DNS ?

The system exactly like you describe already exists. It�s based on the
X.400 protocol and is available across the world.

X.400 is immensely more complex than a federation of ISPs using
SMTP on another port number.

Or in some parts, used to
be. If that approach would be highly successful, why would it not prosper
instead of SMTP today?

X.400 didn't work for a variety of reasons such as
incomprehensible email addresses, too much complexity,
the need to run X.500 directory services, the high cost
of registering an X.500 organization identifier and the
lack of open-source software.

Internet mail systems have borrowed good bits from
X.400 in the past such as the lighweight variant of
X.500 known as LDAP. But peering agreements are not
something that was invented by the X.400 committee.

Lots of people now realize that there needs to be
some system for incoporating "trust" into the Internet
mail system so that mail servers can make decisions
on whether or not to trust incoming messages. I think
that X.400 is the wrong way to go when we can solve the
problem more simply by shifting large amounts of SMTP
traffic onto another port number based on one-to-one
peering agreements between the organizations using that
port number.

Example. Lets say that AOL, Verizon and MSN agree to try
this approach. On day one, they would only reroute email
originating with their customers to the NIMTP port. On day 2
they would start to certify some of the ISPs who send large
amounts of email to AOL, Verizon or MSN. Those ISPs would
only divert email from their own customers to NIMTP. Then
on day 3, these smaller ISPs would begin to certify some
of their peers and smaller local ISPs for NIMTP. On day 3
these smaller ISPs will divert AOL-destined email to the
NIMTP relay of the day 2 ISPs who will then pass it on
to AOL, Verizon or MSN.

If SPAM shows up somewhere, AOL knows who to call because
they exchanged that info as part of the peering agreement.
The Day 2 ISP fixes the problem by cutting off the NIMTP
peering with the culprit and then getting them to cut off
the spammers. This can all happen within a couple of hours
of a spam email appearing. Ideally, this mesh of NIMTP peers
will only have 4 or 5 relay hops between the smallest mail
servers and the biggest ones. In today's world that means
it might take 5 times as long to deliver a message, i.e. it
will take five minutes rather than one minute.

The NIMTP peers will no doubt hone the system to include
various forms of automated checks and notifications but that's
not important on day 1. The important thing is to set down
the ground rules for NIMTP peering and that can only be done
by human beings working for some of the larger users of email.

--Michael Dillon