In article ,
Andy Wade wrote:
}I've never understood why this step of relaying through an ISP's (or
}other mail provider's) server is necessary. Why can't a mail client
}just look up the MX record(s) of the destination domain and send the
}mail straight there. Is it just to relieve the client of the bother of
}handling failed deliveries and bounces etc., or is there some other reason?

It's a fossilised behaviour which is now unnecessary and quite harmful.

The email protocols were designed to work with direct connections from
the sender to the recipient's system. That was in the days when a
computer that offered email was normally shared between many users,
always on, and always connected. So, to give an example of one type of
setup, when a sender triggered sending, their mail program invoked the
sendmail program to queue the message on their local machine. The
message would very quickly be taken off the queue, and the recipient's
machine would be looked-up (via their MX record) and contacted (via
SMTP). The message was sent across the SMTP connection, and when it
arrived on the recipient's machine it was appended to the mbox file in
their home directory. If the recipient happened to be logged in at
this time, they might have a program that notices that mbox has been
modifed and alerts them (e.g. biff).

However, some time later, the Internet became sufficiently popular
that people started getting dialup access. This obviously doesn't work
very well with the procedure just described. It would be rare for both
sender and recipient to be connected at the same time, so direct email
would be impractical. One essential step was to have the recipient get
their mail delivered to a server that was always connected - their
ISP's SMTP server. In many cases that's sufficent. The receipient now
has to use a program that fetches any new mail each time they connect,
which needs a new protocol - POP3. However, that doesn't really cover
all the cases to make email fully practical. If the recipient's mail
server is not instantly contactable, the sender has to stay dialled-in
until a retry succeeds. The simple solution to this is to have the
sender's dialup mail program send all email to the sender's ISP's mail
server over SMTP (since it has to be available always for incoming
mail, it's trivial for it to accept outgoing mail as well). There was
a time when many SMTP mail servers would accept email addressed to
anyone from anyone and pass it on. Spam has stopped that practice, so
such relaying nowadays is restricted to the ISP's customers.

Now that dialup has become rare again, and people have always-on
broadband, there's no good reason why email needs to be sent via the
sender's ISP. (Going via the recipient's ISP can be useful as it saves
the recipient having to leave their computer on all the time). Even
when retries are needed, it would be useful in many cases for the
sender to see that the message is still queued and being retried as it
lets them know that it definitely hasn't been sent yet.

One way this harms email is that if either of the relaying mail
servers cannot pass on the message, then the sender can only be
notified by sending them an email (i.e. a 'bounce'), which may itself
fail to get through. On a direct connection, the sender knows that the
message has been delivered, and even when sending to the receiver's
ISP, the destination address is typically checked before the message
is accepted, so a typo in the address can be rejected very quickly,
but the sender's ISP obviously cannot know which addresses are valid
at the receiver's ISP, so adding that extra intermediary necessarily
delays notification of failure.

However, the main harm done by this outdated architecture is that it
has greatly assisted in sending spam email. If senders connect
directly to recipients' ISP's mail servers, this makes it much easier
for the mail servers to notice that a sender is sending spam and block
them. When the senders go via an ISP, this means that the recipient
sees an incoming connection from the ISP for email sent by any of that
ISP's customers, making is really difficult to distinguish between one
customer who is spamming and should be blocked and all the other
customers who are innocent and should be handled normally. This is why
you occasionaly read of some major email hosting company either
getting mistakenly blacklisted or mistakenly blacklisting someone
else.

Of course having email go via two ISP's mail servers is very
convenient for spy agencies as it gives them more placed to intercept
messages.