I'm also not sure about the utility of the ADMD idea - it seems redundant
to me, or at too high a level without a clear mapping down to the
protocols.
OK, if it os redundant there has to be something else that's eqvuivalent. So
what is that exactly?
At any point between MTAs in the chain of relays, or between the MUA and
MSA, the message may or may not cross an administrative boundary, and the
recipient MTA may enforce policies on that mail flow. I think the idea of
ADMDs is to clarify these administrative boundaries, but it seems too
vague to me to be useful.
On the contrary, since 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. I cannot begin to count
the number of times I've found myself talking at cross purposes due to the lack
of this concept in our terminology set. And you'll pardon me for thinking it
more than a little awkward to have to reach back to X.400 to get it.
X.400 experience is why I don't care for the specific term ADMD much if at all,
but I've been unable to come up with a viable alternative so I'm OK with
reusing the term.
My inclination would be to replace the talk of ADMDs with a list of the
various kinds of client/server connection in the various Internet mail
specifications (RFC 974 SMTP, smart hosts (i.e. traditional outgoing
relays), message submission, non-974 routing (e.g. mailertable), ETRN,
ODMR, batch SMTP, etc.) and classify them according to the kind of
organizational relationships they allow, probably including some
discussion of authentication and authorization and the bullet points from
the section 1.1 overview.
Been there, tried that (for exactly the same reason) the last time one of these
documents was attempted (by Stef et al, not Dave). Rathole doesn't even begin
to describe the result - we spent literally DAYS arguing about about how to
classify this stuff. This was one of, if not the, main factor for why the
previous effort at producing an architecture document self-destructed so let's
PLEASE not repeat that mistake, OK?
Ned