[Top] [All Lists]

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

2007-03-13 11:44:05

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, much the way I use outgoing servers at and They guarantee delivery of my mail - because it has clout, and 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 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 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. I can "fire" any of them on short notice. 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 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