[Top] [All Lists]


2007-03-14 10:40:33

At 07:48 AM 3/14/2007 -0700, Dave Crocker wrote:
David MacQuigg wrote:
At 04:57 PM 3/12/2007 -0700, Dave Crocker wrote:

{ADMDs have} real boundaries between meaningfully different centers of control, along different parts of the email service. The concept of ADMD is intended to refer to these boundaries.
My company uses email transit through an independent company (songbird).
I have my "operating policies" for email within my ADMD and Songbird has
theirs. Believe me, no matter how well we get along, the independence
between us is real and has an effect of aspects of the way email is
handled between us, even though Songbird is "only" a transit for my mail.

I'm still not seeing a good example of a "transit" domain that is truly independent of either sender or receiver.

I'm going to attempt to build on Ned's "the concept of crossing adminisrative
boundaries is centrol to where policy enforcment occurs and where rules change, having a well-understood way to refer to it is HUGELY useful."

First, I think there might be a confusion between using different perspectives. And end-user or end-user organization has one view of email. An operator has another. It even depends upon which kind of operator.

The reference to the nature of the relationship between any two ADMDs, such as originator/recipient (when there is no intermediary ADMD) is one. A proxy filtering service ADMD and the recipient ADMD is another. And so on.

The purpose of the ADMD construct is not to distinguish the specifics that characterize these very, very different relationships, but to provide a category in which these differences can be discussed. The UA/MTA construct cannot capture this type of issue.

Your reference to the term "border MTA" or "border gateway" demonstrates that there is something going on at a different level than merely MTA-MTA. And it well might be that the term needs to be elevated in the discussion of ADMD.

The Border is a special ADMD boundary, one in which there is no prior relationship. You define the term "Edge" on page 12 to mean something similar, but Fig. 4 shows an Edge between two related ADMDs. (From now on, I will assume that a "Transit ADMD" must be related to one side or the other. If not, we need an example.)

To keep things simple in Fig. 4, I would associate ADMD2 with ADMD3 and draw the Border at ADMD1. However, if ADMD2 is in reality associated with ADMD1, then the Border would cross both of the two lines going into ADMD3.

I see that has an SPF record authorizing one server at, not the one that sent your message!! Oh well, let's hope my spam filter doesn't trip on your choice of words or some minor errors in
the headers.  Let's also hope that will correct (or delete)
its SPF record before losing too much mail.
This is the kind of problem that I believe results from confusion over Songbird's role as a Border MTA. The Border is not between you and Songbird, regardless of their "independence". Songbird is your agent, and
you have a choice of many such agents who don't have a problem publishing a
correct list of their authorized transmitters.

In fact, this split between local (edge) email services and an ESP or transit provider is quite common. Indeed you cited three common scenarios: "a large ISP, a small email service, and a professional association, all forwarded to a private mailbox at his own company". None of these is part of your organization
or subordinate to it, though of course there is cooperation.  But there
is also independence.

They may be independent, but they are part of my network.

No they are not. They are part of an integrated service in which you participate. The relationship between you and the other provider is important, but it does not make them part of your network, except perhaps for a non-technical use of the word network.

I would think the term "network" should include a collection of agents connected by contractual relationships. Anyway to facilitate our discussion I will call what I have an NoA (Network of ADMDs). My NoA is what outsiders have to deal with when they exchange email with me. I can replace any component of my NoA as easily as replacing a Network Interface Card in my computer. True, I cannot control what goes on inside a component like '', but that is no different than trying to figure out which transistor is bad in my NIC. Regardless of my ability or authority to fix low-level problems within any component of my NoA, I can and do control it to the extent that it is acceptable to outsiders.

In any event, it is their independence that needs to be characterized by the architecture, and we do not have that ability, without something like ADMD.

I'm not saying that ADMDs aren't important, just that there is a higher level of organization, a Network of ADMDs that should not be ignored. When I first read this document two years ago, I came to the conclusion that IP-based authentication was futile, because a chain-of-trust through all these ADMDs was too difficult to establish. Now I see that there is a simpler way of looking at this architecture, one that facilitates IP-based authentication at a single, well-defined Border. The document is misleading because it implies that such a Border does not exist.

Can we at least agree that there is one special boundary between ADMDs, and that is the Border between sending and receiving NoAs? Can we agree that this Border is important enough to be included in Figs 3, 4 and 5? Do you see that this Border is unique in that
1) It is the only boundary that can be reliably seen by both sides.
2) It is the only boundary across which there is no prior arrangement or contract. 3) It is the only boundary where IP-based authentication can be done without any "chain of trust" involving unrelated MTAs.
4) It is present in every transfer across the open Internet.

-- Dave

************************************************************     *
* David MacQuigg, PhD    email: david_macquigg at   *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *