Re: ADMD

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.

> How would an outsider know if
> Songbird is part of your ADMD or has their own ADMD?  
The purpose of an architecture is to distinguish roles.  Your question is 
about the ability of a particular participant to know about that distinction. 
 Although it well might (or might not) be useful for that particular 
participant to be able to know about that particular relationship, getting 
them that knowledge is different from defining an architecture that makes that 
distinction.
I apologize for how obtuse the above paragraph is, but will ask folks to 
consider it carefully, since I think it goes to the heart of the current 
differences in view.
Let me stress that I can easily believe that the document needs improvement in 
its discussion about ADMDs.  Whenever I see a couple of people put serious 
effort into understanding some text that I wrote, and come away either 
confused or completely misunderstanding my point, I assume I haven't stated 
things well enough.  So, I'm hoping the current thread can produce guidance 
for revising the text.

> But even if there were a chain of MTAs between you and Songbird, and they
> were clearly labeled with different domain names, I'm still not seeing the
> utility of having outsiders treat Songbird as a separate ADMD. 
Do neighbor ADMDs have to have different domain names?  I think the answer is 
typically yes. Although I could construct a plausible scenario where they 
might not be -- department MTA vs. organizational backbone MTA -- I'd guess 
that that would be a poor configuration since it makes diagnostics more 
difficult.  But note that I'm suggesting that even within a single 
organization there might be different ADMDs.  Take another look at Ned's 
language, to see why.
So I'm already seeing the likelihood that the document needs to a) discuss 
relationship with domain names, and b) discussion about some typical 
relationships, beyond what is already discussed, to make the construct more 
concrete.

> As an
> operator of a server receiving your mail, I will attempt to authenticate
> songbird.com before proceeding beyond HELO.  Songbird is the "Border MTA",
Songbird has a border system, yes, but so does brandenburg.  It happens that 
brandenburg's is just an MUA, but it still operates according to policies that 
are independent from Songbird (who happens to host brandenburg's domain name.)
So, the hosting/administration of domain names is probably not a very useful 
guideline for distinguishing between neighboring ADMDs.  And we need to be 
careful in looking at Received header fields, since they are added somewhat 
inconsistently.
For example, brandenburg's MUA (thunderbird) happens not to put an initial one 
on.  I'd guess that it is typically for the oMUA not to add a Received header 
field; one could argue that the act of posting a message should including 
having the posting agent add its own identification, but that's really a 
separate discussion.

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

> > As the "tussle" paper that I cite in the architecture document points 
> > out, these boundaries can have a profound effect on the ways a real-world
> > service operates.
> I found this paper very frustrating, again due to a lack of real-world 
> examples.  When I try to apply its "principles" to the tussle between 
> spammers and legitimate email users, it pushes me in the wrong direction.
I suspect there is a useful discussion to pursue here, for feedback to the 
paper's authors.  I'll see how the current discussion develops, to consider 
what I'd say to them.  Others might want to do the same.

> I do not want "neutrality" in the design of protocols relevant to this
> tussle.  I do want to "dictate the outcome" of this tussle, or at least
I think you are confusing the difference between identifying a tussle 
boundary, versus considering the details of a particular tussle.  The goal of 
the architecture is to define the boundaries, not to dictate particular 
relationships.  In that regard, the architecture must be neutral about the 
details, even as it defines a category (ADMD) into which the discussion of the 
details can take place.

> I understand the goal of this document is to describe email as it is, and
> in that regard the complexity of Fig. 5 is justified.  There really are
> many agents performing various services along the way.  Fig. 4, however, is
> much less constrained.  At this level of abstraction, I think Frank's
> figure is an equally valid description of the real world.
ack.

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net