Re: I-D ACTION:draft-crocker-email-arch-06.txt

Frank's diagrams have finally made clear what has been bothering me since 
first encountering these "ADMDs" (or whatever we call them) in an earlier 
draft of this email architecture document.  What are these strange 
"Transit" domains, and how do they get involved in a mailflow?  Fig. 4 and 
the related text seem to imply that they are an independent part of a 
typical mailflow, outside the realm of either senders or receivers, and 
equal in stature to either of these.
I thought I had found such a beast in my own mailflow, but it turned out to 
be just another piece of the sender's network.  My outgoing mail was going 
via mailsystem.us, a server owned by Verizon.  The folks at my local ISP, 
gain.com, didn't know why mailsystem.us was in the loop, and told me that 
it was just something that was set up by their upstream provider.  The 
truth is they own the name gain.com, and they control the DNS records that 
route my mail via an agent named mailsystem.us.  If mailsystem.us screws 
up, I hold gain.com responsible.
Maybe we could clarify the draft with some words like:
'''
The boundaries of an ADMD may be defined differently by each participant in 
a mail transfer, and the concept may still be useful even if there is no 
agreement, or even a clear definition, as to the boundaries.
For example, a recipient may have email accounts at a large ISP, a small 
email service, and a professional association, all forwarded to a private 
mailbox at his own company.  Each of these may view themselves as 
independent ADMDs, and be mistrustful of the others.  To the recipient, 
however, they are all one ADMD with a well-defined boundary to the 
Internet.  There should be no loss of mail due to lack of trust within this 
network.
There may be overlapping "levels" of ADMDs.  The recipient's ADMD in this 
example would encompass four lower-level ADMDs.  At the highest level, 
there are really only two ADMDs - the sender's network, and the recipient's 
network.  There is a clear border between ADMDs defined in this way.  A 
recipient can look at the headers on any mail he receives, and see exactly 
where that border lies, and where the chain of trust ends.
'''

The other boundaries may not even be visible to an outsider.  What is the 
fundamental difference whether mailsystem.us is owned by a big telco or by 
the same ISP that owns gain.com?  If nothing changes but the ownership of 
gain.com, do we suddenly have a different architecture for the same mailflow?
What if after the merger, the guy in charge of mailsystem.us won't talk 
with the guy in charge of gain.com, even though they are now in different 
departments of the same company?  How do we decide if there are one or two 
Administrative Domains?  Is company politics a factor in defining 
architecture?  Is the actual ownership of the equipment or the IP addresses 
a factor?  Do any of these factors matter to the recipients of spam?
There needs to be a fat dark line in Figure 4 between the sender's and 
receiver's "ADMDs" or "Administrative Realms", or whatever you want to call 
these collections of related MTAs.  The Border should be an important, 
fundamental, and well-defined line in any diagram of mailflow over the open 
Internet.
-- Dave


At 05:37 PM 3/11/2007 +0100, Frank Ellermann wrote:


>           +-----+    +-----+ :
>          /| MSA |--->| MO  |---> to others
>         / +-----+    +-----+ :
> +-----+/     |        ^ ^    :
> | MUA |      | +------+ |    :
> +-----+\     V V        |    :
>         \ +-----+    +-----+ :
>          \| MDA |<---| MX  |<--- from others
>           +-----+    +-----+ :
>
> For the simple cases (no mediator) couple two of these boxes:
>
>           +-----+    +-----+ :  +-----+    +-----+
>          /| MSA |--->| MO  |--->| MX  |--->| MDA |\
>         / +-----+    +-----+ :  +-----+    +-----+ \
> +-----+/     |        ^ ^    :     |        ^ ^     \+-----+
> | MUA |      | +------+ |    :     | +------+ |      | MUA |
> +-----+\     V V        |    :     V V        |     /+-----+
>         \ +-----+    +-----+ :  +-----+    +-----+ /
>          \| MDA |<---| MX  |<---| MO  |<---| MSA |/
>           +-----+    +-----+ :  +-----+    +-----+