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