Re: ADMD

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 songbird.com has an SPF record authorizing one server at 
> > 208.184.79.7, 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 songbird.com 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 'yahoo.com', 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 yahoo.com   *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *