[Top] [All Lists]


2007-03-14 08:06:00

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

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.



  Dave Crocker
  Brandenburg InternetWorking