Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Internet Email Services Association ( wasRE: Why do so few mailproviders support Port 587?)

  • From: Michael.Dillon
  • Date: Tue Mar 01 06:50:00 2005

> > No, I am not suggesting a return to the UUCP model. If I
> > was then I would have said that. I am suggesting that
> > we apply the lessons learned from the BGP peering model.
> 
> I'm skeptical that a model that only sort of works for under 30K ASNs
> and maybe 1K bilateral peering agreements for the *really* big Tier-1s
> won't scale to a world that has 40M+ .com domains and probably a million
> SMTP servers.

Well the way that I see this scaling is that you have
a core of email service providers who are members of
the Internet Mail Services Association. These core
operators sign up to a multilateral mail peering agreement
and provide email transit services for other operators.

The next layer is the non-core email service providers
who have bilateral mail peering agreements with one
or more core email transport providers. They essentially
relay their email through a core provider, or possibly,
they use some credential provided by their peer in the 
core to connect directly to other core members. The key
thing here is that there is some kind of contractual
agreement between the second tier and the core members.
If the second tier breaks the agreement, their email
flow is summarily cut off. You can do that with contracts.
The mechanism for email transport and authentication is
something that other people can work out. I know that
relaying will work, but may not scale. However there are
ways around this by separating the credentials/authentication
from the mail flow. For instance, the 2nd tier provider
connects to his peer in the core (CORE A) and asks for
a credential to send mail to another core member (CORE B).
CORE A hands him a magic cookie. He connects to CORE B and
hands over the cookie. CORE B validates that this is a 
legitimate credential from CORE A. Email flows.

And then there is the last layer which I call the end
user. Of course this includes many organizations as
well as individuals. It could even include someone
who hosts mailing lists, i.e. someone who sources
large volumes of mail. These people never talk to
the core providers and submit all their email to
a 2nd tier provider through the authenticated submission
port. This group is the most important group because
the entire system exists to serve their needs.

Note that a large provider like AOL would be both
a core email services provider and a 2nd tier
provider at the same time. The 2nd tier deals with
end users. In fact, AOL will also be an end user
as will every other company. It is more useful to
think of the functionality here rather than trying
to map specific companies into a specific layer.

I think that most people will agree that the
architecture that I have described stands a good
chance of scaling to a global level. And if there
are some scaling issues that arise, they should
be able to be solved within the core, i.e. the
group with multilateral email peering agreements.
They may decide to put some hierarchy within the 
core to match up with geography on a broad scale.

--Michael Dillon





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.