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.
