> 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.)
FWIW, more and more ingress MTAs are able to perform full address validation,
and may even know things like which users are over quota and hence unable to
receive mail.
There is enormous and increasing pressure to "front load" as much validation as
possible, in order to keep the load on spam and virus filters (which for many
sites constitues the biggest overhead in email processing by far).
However, no matter how smart you make ingress MTAs, there are always going
to be boundary cases where a message is acepted and subsequently found to be
undeliverable.
> > If you've delivered to the best MX, then that's as far as SMTP takes the
> > message.
> This, too, is often incorrect. Between the boundary MTA and final delivery can
> be multiple email hops, all using, or not using, SMTP.
Yep. There can also be hops across the Interet using protocols other than SMTP.
it's a big world out there, and it contains lots of varying practices.
And even if every site out there only operated a single MTA and never did any
internal routing, this still fails to take the autoforwarding case into
account. It is quite common for a message to arrive and through the use of
MTA-level aliases be sent right back out again.
> > 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...
Yes, but let's not confuse user handling of the messages they have received
after delivery with transport before delivery. For better or worse we have
defined things like fetching messages via POP as after-delivery email
management rather than transport.
Ned
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.