On Thu, Oct 19, 2023 at 01:10:22PM +0200, Gertjan Klein wrote:
> Op 17-10-2023 om 23:20 schreef Greg Wooledge:
> > [...]  This is different
> > from when an MTA accepts a message directly from a MUA.  That's usually
> > called a "submission", and can use either SMTP or /usr/sbin/sendmail.
> 
> So a submission from a MUA can use SMTP as well... The MTA could then be
> bypassed. I suppose e.g. Thunderbird would do this. So it does perhaps make
> sense that a MUA explains whether it needs a MTA.

Traditional Unix terminal- or command-line-based MUAs inject new messages
into the outgoing mail queue by piping them to /usr/sbin/sendmail.

Fancy GUI MUAs like Thunderbird are often written to work on either
Windows or Unix, so they don't always offer the ability to inject through
/usr/sbin/sendmail (because obviously Windows doesn't have that).
In some of these cases -- maybe Thunderbird is one of them, maybe not,
I don't know -- they require a submission MTA to be available.  New
messages are injected using SMTP, typically with password-based SMTP AUTH.
That submission MTA might be localhost, or it might be provided by one's
ISP, or it might be something on the public Internet, such as Gmail.

The difference between a submission MTA and a receiving MTA is pretty
subtle.  And yes, a single MTA might serve both roles, but not always.
A submission MTA (which does only this job) doesn't accept messages from
outside senders.  It only accepts messages from its authorized clients,
which are a known set of people, identified by IP address or by password
or by some other means.

SMTP is a fairly simplistic protocol, and if we ignore encryption and
authentication and various other extensions, it boils down to these steps:

1) The client (MUA or MTA) connects to the server (MTA).  The server
   identifies itself by sending a banner message.

2) The client identifies itself by sending a HELO message, which is
   acknowledged by the server.

3) The client states the next email's sender address by sending a MAIL FROM
   message, which is ack'ed by the server.

4) The client states the next email's recipient(s) by sending RCPT TO
   messages, each of which is ack'ed by the server.

5) The client sends the next email's body in a DATA message, which is ack'ed.

6) The client either disconnects or goes to step 3 if there's more email.

The difference between a submission MTA and a receiving MTA is how
the MTA responds in steps 3 and 4.  A submission MTA might require that
the sender address have a specific @domain part, for example.  It will
generally allow *any* recipient addresses, since its job is to accept
mail on behalf of a client, and whisk it away to wherever.

A receiving MTA, on the other hand, probably allows any sender address,
but only allows recipient addresses with locally recognized @domain parts.
This is because the receiving MTA's job is to accept email *from* anywhere
in the universe, but only if it's *for* one of its known users.  Anything
else should be rejected.

Of course there are in-between cases, where an MTA is configured to
accept some local deliveries, or to relay email to some specific
external destinations, but not to any other destinations.  And then
there's all kinds of anti-spam technology, anti-virus, etc.  Things
get ridiculously complex in the real world.

Reply via email to