ietf-smtp
[Top] [All Lists]

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

2007-03-11 10:36:35

ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:

 [the real architecture vs. the standardized architecture]
the main problem would be that unless we're at least somewhat
constrained to what's been formally defined the document will
inevitably become so amorphous and general it will be useless.

For a kind of minimal abstraction some things are clear (also
in the I-D):

- it's certainly not only one hop sender - receiver - ready,
  but there is a critical hop "last MTA on the sender side
  to first MTA on the receiver side"
- anything else on the sender side is the internal business
  of the MON from the MRN's POV
- anything else on the receiver side is the internal business
  of the MRN from the MON's POV
- from the user's POV (as sender) we find the MSA stuff like
  enforced submission rights and SMTP AUTH
- from the user's POV as receiver we find the MDA stuff with
  IMAP and POP
- last but not least mailing lists, forwarding to 3rd parties,
  and gateways are also necessary to get a minimal abstraction
  (otherwise SPF or DKIM would be a FUSSP, but they are not).

With that a minimal abstraction could be something like:

          +-----+    +-----+ :
         /| 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 |/
          +-----+    +-----+ :  +-----+    +-----+

Of course there can be more than one MX, or more hops between
MX and MDA (e.g. for SIEVE and A/V magic), and likewise there
can be more than one MSA or more than one "MO" (mailout), and
more hops also on this side (DKIM signers, outbound SOF tests,
etc.), but the shown model should be good enough to discuss
many interesting questions like "reject at the MDA".

It's too detailed for cases involving "mediators", in essence
a combo of MRN and MON (receiving and then forwarding mails),
so maybe that case needs a less detailed abstraction.  But one
mediator (representing in reality one or more) should do it.

Unless it's about gateways to non-SMTP transports, that would
need a scenario with two (non-cooperating) gateways.  Arguably
this is already out of scope.

Frank