Dave Crocker wrote:
comments suggesting concern over architectural points.
No concern, only a show-stopper, there's no "bounce address"
in mail. For an abstraction removing the historical concept
of a "reverse path" the 3461 term "envelope sender address"
The ADMD business is beyond me, I've no clue what it is, it
is apparently some finer granulated concept than the MON
(mail originating network) + MRN (mail receiving network) .
The MON + MRN abstraction is much simpler, there's a sending
side, no matter how they organize it, e.g. MUA + MSA + "mail
out" (this could be already two ADMDs, if "MUA" is actually
an arbitrary customer of one or more mail providers). Throw
in a 3rd party (DKIM signer or what else), and it is still a
single MON - but with ADMDs you'd already have three ADMDs in
And there's a receiving side MRN, starting with the MX, no
matter how that's organized on behalf of the receiver. It
could be an outsourced backup MX + primary MX + 3rd party for
virus checking + MDA + (independent) end user, resulting in
four ADMDs. But for the architecture the abstraction "MRN"
would cover it, anything else is the internal business of the
All details within a MON or MRN (like how many ADMDs) aren't
interesting, the critical point is when an MTA has to lookup
the MX, i.e. when an "unknown stranger" talks with a server.
At that point the responsibilty for delivery passes from the
MON to the MRN, that's where the MRN either must be sure that
it can deliver, or it must be sure that it can report errors
to the originator, or it must reject the mail. Otherwise it
screwed up, and is forced to drop the mail, or to participate
in abuses of forged envelope sender addresses.
The q=mx hops are a singularity in SMTP, resulting in three
classes: Mail not going through this point (anything handled
as local or "bogus" within the MON), mail going through it
exactly once (MON to MRN, local aliases on the side of the
MRN not withstanding), or mail going through it more than
once (the MRN switches roles and forwards the mail as MON to
another MRN, e.g. mailing lists or other mediators).
The mediator is a good abstraction, it's an MRN on one side,
acting as MON on the other side, forwarding mails to a third
party after adjusting RCPT TO and MAIL FROM as required by
Only that it doesn't anymore in the 1123 5.3.6(a) case, where
the complete architecture is reduced to the horrorshow we know
today. Weasel words like "bounce address" can't fix this, it
is a design flaw in STD 3.
As far as I read the I-D again - I stopped near "Message-ID",
something might be odd there - it apparently considers SMTP as
one transport among others, that's good, and maybe it's also
good to skip all details about "MX" and reduce it to some kind
of black box:
Mail is injected into SMTP somewhere, point O, and leaves it
somewhere, point X. Where O could be a gateway from MMS, news,
uucp, or whatever, in simple cases it's just an MON. And X is
another exit gateway, or in simple cases an MX of the MRN.
So far the draft is fine. But where it implies that O could
inject mails with envelope sender addresses Y without prior
consent of Y, or that X could accept mails "from" Y actually
originating from O without verifying that this is okay, it
cannot work if there's an error later. Even if O and X agree
to DoS Y with bogus bounces it's not okay, nobody cares whose
fault this is.