Re: ADMD (was: Re: I-D ACTION:draft-crocker-email-arch-06.txt)

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.  How would an outsider know if 
Songbird is part of your ADMD or has their own ADMD?  From the headers on 
your message, it looks like you are submitting your mail directly to 
sb7.songbird.com, much the way I use outgoing servers at yahoo.com and 
controlledmail.com.  They guarantee delivery of my mail - yahoo.com because 
it has clout, and controlledmail.com because it has a pristine reputation 
for sending no spam.
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.  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", 
and my decision to whitelist or filter is done at HELO.  If I don't trust 
Songbird, I don't trust any MTA behind them.
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.  I can "fire" any 
of them on short notice.  yahoo.com is no longer my mailstore, because they 
wouldn't whitelist one of my domains that has never sent any spam.
The boundaries or "edges" between these cooperating agents are less 
fundamental than the Border established by the Public Internet, across 
which there is no relationship of trust.  An outsider has little use for 
the boundaries between ADMDs.  Even if he could figure out where they are, 
they may change without notice, and without any change in email headers, 
DNS records, or any public records, as far as I know.  The Border is 
well-defined for both sender and receiver.  "Edges", if I understand your 
definition, can only be determined by those familiar with the business 
arrangements between these ADMDs.
> 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 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 give it a strong push in the right direction.  I strongly favor 
protocols that will make life difficult for spammers, and I don't think 
"biasing" the outcome in this way will lead to "rigid designs".  My 
apologies to the authors if I misunderstood their intent, but there needs 
to be better examples to clarify the abstractions.
> So, ADMD is intended to capture this concept of boundaries between 
> independent spheres of control.
Maybe a better example would make it clear why these boundaries are 
important.  Otherwise, I would avoid the notion that there are "Transit 
ADMDs" truly independent of either side of an exchange.  The "Edge" labels 
in Fig 4 added to this confusion, because I was interpreting "Edge" to mean 
what I am calling "Border".
Even if you keep ADMDs defined as they are, I would really like to see the 
Border given at least as much emphasis as ADMD boundaries.  The Border is 
an important concept, and this architecture document could be a big help in 
getting everyone to understand that concept and the special role played by 
agents handling mail at the Border.  If everyone had such an understanding, 
I believe we would not see Public Mail Senders (Border ADMDs?) like 
songbird.com publishing incorrect or incomplete lists of their authorized 
transmitters.  I believe we would have simple and robust authentication at 
HELO, and that will be a big step in the right direction.
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.
In choosing an abstract model like this, I would put a high value on 
utility and on avoiding ambiguity.  Designers, mail admins, and anyone 
"outside" a group of related ADMDs, might find the Border concept much more 
useful than the proposed Edges.  Having less ambiguous boundaries will also 
move us away from the muddy mess we have now, where it is too easy for 
abusers to hide and for their silent partners to avoid accountability.
I would describe Administrative Actors as either Users or Agents.  Users 
include Originators, Mediators, and Recipients.  Agents include Senders, 
Forwarders, and Receivers.  Forwarders include Sending Forwarders, 
Receiving Forwarders, and Open Forwarders.  As far as I know, Open 
Forwarders (Transit Forwarders?) have no legitimate purpose.  An example 
could change my mind, however.
We could further subdivide Forwarders, depending on whether they are at the 
Border, but at this point I see little utility in further abstraction, and 
prefer to just think of individual MTAs.  There are Border MTAs and other 
MTAs.  The others are internal to the Sending or the Receiving Networks, 
and are of little concern to the outside world.
-- Dave