Arnt Gulbrandsen wrote:
Jeff Macdonald writes:
Ok, you both lost me. Or Perhaps you are agreeing with me. How does a
sending MTA know that final delivery has happened?
It only knows that final delivery will happen, not that it has happened.
It does not know that final delivery will happen.
An "MX" host is an incoming boundary MTA (see email-arch) for email. It
typically does not know all of the valid addresses within the organization and
it certainly cannot know about all of the possible errors that could prevent
delivery, between the time the MX host takes receipt and final delivery finally
happens (or doesn't.)
If you've delivered to the best MX, then that's as far as SMTP takes the
This, too, is often incorrect. Between the boundary MTA and final delivery can
be multiple email hops, all using, or not using, SMTP.
The message may have a long way to go, but that's independent
of SMTP and DELIVERBY. For example, the recipient may use something like
Thunderbird offline, in which case the recipient's inbox at the server
is just another spool, emptied when the recipient polls.
Folks seem to think that receipt by a host listed with an MX in the (presumably
public) DNS is of fundamental import to for the end-to-end process of posting
and delivering mail. It doesn't. It is merely one of a potentially large
number of hops along the way. In fact, the email architecture has little or no
technical details that pertain to the operation or semantics of a boundary MTA...