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

From: (no name) (no email)
Date: Tue Mar 01 2005 - 06:50:13 EST

  • Next message: Jim Segrave: "Re: AOL scomp"

    > > 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


  • Next message: Jim Segrave: "Re: AOL scomp"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD