Why does cron use MTA to send emails, while we use MUA to send emails?

Question

I have looked at the definitions of MTA, MUA, MDA, for example, https://ccm.net/contents/116-how-email-works-mta-mda-mua and https://en.wikipedia.org/wiki/Email_agent_(infrastructure)

• In Lubuntu, the default email client is Sylpheed, and many also use Thunderbird. If I am correct, both Sylpheed and Thunderbird are MUA.

• In https://unix.stackexchange.com/a/479613/674, Stephen mentioned that cron uses MTA (such as postfix or sendmail) to send the outputs of its jobs as emails.

My questions are:

• Why does cron use MTA instead of MUA to send emails? If cron can use MUA to send emails, how?

• why do we use MUA (Sylpheed or Thunderbird) instead of MTA to send emails? If we can use MTA to send emails, how?

• When we install MUA (Sylpheed or Thunderbird) , does Sylpheed or Thunderbird need a MTA installed on the same machine to send emails?

Thanks.

Answer 1

At its base, mail on Unix is a local phenomenon. Users on the same host can mail each other without the existence of any network. (The "addresses" are simply usernames, with no @.) This of course means that the method of communicating a message from MUA to MTA must be local. Usually, that method is a pipe to a program named sendmail.

Purely local mail can be extended to participate in the Internet mail system by making the MTA understand addresses containing the @ symbol. The MUA still doesn't need to know about the existence of the network; it just needs to treat addresses as opaque strings and let the local MTA figure out which ones need to go over the network.

The MTA is obviously the right place for network configuration because there is only one of them on the system, but multiple MUAs can be in use by different users, or even the same user. A single program that handles the network stuff for all of them means the configuration doesn't need to be done more than once.

MUAs that inject their outgoing messages to a remote server are intended to allow "Unix-like" systems to pretend to work properly without an MTA. This configuration is a rejection of the traditional scheme of things. It cuts out the heart of the mail system - the ability to send a message to any local user - and provides no adequate replacement for it.

Cron is acting as an MUA, which is why it doesn't "use an MUA", and it's doing what Unix MUAs have always done, sending mail while having no idea that a network exists, relying on the local MTA to figure it out. And addressing the recipient by local username is the only reasonable default, since cron jobs run on behalf of a local user and there's no way of knowing what address that user might have on some remote host.

Answer 2

On cron and MUA-MTA connection

Practical Answers

I generally create an postfix alias for my cron users. This way all cron job mails are delivered to the aliased address in my lookup table.

• So, a practical answer is:

Cron messages can be sent off server/domain/machine to any arbitrary Internet wide email address.

---

Furthermore, cron itself can be configured to use any arbitrary mailer MTA.

From my cron source tree in Debian Buster:

cron-3.0pl1/config.h

45 #define MAILCMD _PATH_SENDMAIL                   /*-*/
46 /* #define MAILARGS "%s -i -FCronDaemon -odi -oem  %s"       /*-*/
47 #define MAILARGS "%s -i -FCronDaemon -B8BITMIME -oem  %s"        /*-*/
48          /* -i    = don't terminate on "." by itself
49                         * -Fx     = set full-name of sender
50           * -odi  = Option Deliverymode Interactive
51           * -oem  = Option Errors Mailedtosender
52           * -t    = read recipient from header of message
53           * -or0s = Option Readtimeout -- don't time out
54           * XXX: sendmail doesn't allow -or0s when invoked
55           * by joe user.  --okir
56           */
57
58 /* #define MAILCMD "/bin/mail"           -*/
59 /* #define MAILARGS "%s -d  %s"          -*/
60          /* -d = undocumented but common flag: deliver locally?
61           */
62
63 /* #define MAILCMD "/usr/mmdf/bin/submit"    -*/
64 /* #define MAILARGS "%s -mlrxto %s"      -*/

---

• So, a second practical answer:

Cron can be compiled to use any arbitrary MTA

---

Theoretical Answer

As stated in comments and other answers, cron is acting as a MUA. It doesn't have the code base to handle actually sending the messages anywhere except a predetermined MTA which is located on its own logical machine. It's useful to note, that the logical machine may, in fact, not be the same physical machine.

On Using MTA to Send Emails

Connecting directly to a MTA via its SMTP port

An email can be sent directly through a MTA by connecting to its SMTP.URL:port and working through any authentication manually.

telnet example.com 25

Will generally work if one has unblocked access to port 25 via connecting ISP. And you'll get a message similar to this:

Trying xxxx:xxxx::xxxx:xxxx:xxxx:xxxx...
Trying xxx.xxx.xxx.xxx...
Connected to example.com.
Escape character is '^]'.
220 mail.example.com ESMTP Postfix (Debian/GNU)

But... most ISP do block port 25 connection. And this method of sending email is cumbersome, so in general, a well designed MUA such as sylpheed or thunderbird is used.

Why ISPs block the standard SMTP port: 25

Most Internet users connect to the Wide Area Network (WAN) through an Internet Service Provider (ISP). These ISPs generally block common ports that are utilized for running Internet services such as HTTP (80) SMTP (25) and several possible others.

In general ISPs have a Terms and Conditions Agreement with its customers that precludes running an Internet service from its network. There are at least two reasons for this general ISP policy:

1. Internet Services consume bandwidth.
2. ISPs act as a minimal barrier for many email spammers or malicious web services.

ISPs also generally blacklist their own dynamic IP address pools. So, any mail services running from an ISP dynamic IP address is very likely to either be rejected or placed directly into the "spam" folder of any large email provider.

Blacklisted IP blocking

IP blacklisting is very simple and effective. It's used in the MTA configuration to immediately reject incoming mail that originates from a blacklisted domain.

/etc/postfix/main.cf

...
smtpd_client_restrictions = ...
                            reject_rbl_client cbl.abuseat.org
                            reject_rbl_client pbl.spamhaus.org
                            reject_rbl_client sbl.spamhaus.org
                            reject_rbl_client bl.blocklist.de
...

Example from one of my actual server logs:

Oct 14 04:45:23 xxxx postfix/smtpd[17679]: NOQUEUE: reject: RCPT from xxxxx.xxxx.xxxx.jp[xxx.149.xxx.xxx]: 554 5.7.1 Service unavailable; Client host [xxx.149.xxx.xxx] blocked using sbl.spamhaus.org; https://www.spamhaus.org/sbl/query/SBL319039; from=<yuuki429@xxxx.xxx.xxx.jp> to=<xxx@example.com> proto=ESMTP helo=<xxxx.xxx.xxx.jp>

Effectiveness of port blocking and RBLs in the Age of Botnets

These policies were more effective before the current age of on-demand web servers. In my experience, the spammers and malicious actors have simply moved from ISP connected services to botnets and on-demand Command and Control (C&C) servers.

Most of the spam or brute force attacks against my own servers begin with a C&C probe usually run from an Amazon EC2 IP address. Followed by a series of botnets coming from addresses in far off countries somewhere.

ISPs that do not block ports

I'm not sure if any USA ISPs allow all ports. However, I have seen some European ISPs that simply hand consumers the Internet fire hose with no blocked ports and no filters.

So, I don't have an answer for this one except "Check with your ISP".

Answer 3

The short answer might be: It is the unix philosophy "Do one thing and do it well".

First understand the difference of MTA vs MUA:

• The MUA (Mail user agent) (like Thunderbird etc) is a program to allow easy interaction with the user. This program is mainly focused on user interaction. It presents current mails in the various mailboxes to the user and allow the user to send mails to a given mail address. Additional features are possible. Mainly it handles all the lower level things to keep the user happy.
• The MTA is a program in the background. Its sole purpose is to provide a stable backend to transfer mails from one "location" to another. (Here "location" might mean host, person or something else. Just to get the idea behind it.) Its interface is mostly a programmatic API (see SMTP protocol). Of course a human can fake such text but it is not so easy to keep it in specs manually when doing a real world mailing example.
• The MDA (Mail delivery agent) is a program that offers access to the mailboxes of a user. It uses a programmatic interface as well. Examples of such interfaces are POP3 or IMAP.

Whan a user send a mail in his MUA, the MUA connects to a MTA of his ISP. The MTA checks the users credentials and accepts the mail for delivery. The mail is now reported as sent to the user. The MTA of the ISP now checks how to deliver the mail and maybe finds a next station to put the mail to. A mail can make multiple hops this way before a host is found that is the ultimate destination of the mail. This MTA will know how to put it in the destination user's mailbox (typically locally on the server). The recipient might now open his MUA and connect to his ISP's MDA. The MDA looks in the local filesystem and reports back that there was a new message and its content.

So the simple answer is: Cron is a program and thus will use the programmatic interface of an MTA instead of an MUA. (how should cron interact with these programs at all?)

To send mails using an MTA: Connect to ports 25, 578 or whatever you use and use the SMTP(S) protocol. This is exatly what your MUA does for you under the hood. You can/must use the same credentials/host/port settings you would use in the settings of your MUA.

The MUA is capable of doing network communications to the MTA. So no local MTA is needed on each machine (you do not need postfix locally running for running Thunderbird, right?).

However when we are talking of services on a machine that should be capable to send mails anywhere there are in fact two options:

1. The program (e.g. cron) knows of a remote MTA that accepts the mails. This needs to be done individually for each and every program which is cumbersome at best when administrating many services.
2. There exists a "default route" for all mails. Then any local program can simply use this route without manual configuration.

Here the unix philosophy mentioned above comes into play: Instead of implementing the communincation (and authorization etc) for all programs it is implemented once (the MTA) and this program provides a default interface that accepts mails from local services (either via unix socket, pipe to a command or network port). This is the reason that most services assume a local MTA to be running. This MTA might be a very minimal one that simply forwards the mails to a bigger one for sorting etc.

The de-facto standard here was the recent program sendmail (also an MTA). Due to huge problems with it it was superseeded by other MTAs like postfix that still provide the old sendmail interface (the reason there exists a sendmail wrapper within postfix packet).

---

Edit 1: @Tim, why do you think the sending and receiving need to be symmetric? The MTAs are responsible for the inter-server communication. This one is symmetric in some sense but you only see one side of it (during sending mails to others). The reception is done by your provider's servers. The mail transmission itself is very quck (matter of msecs).

So, you do not need somethink like a MDA on the sending side. You can simply give it a go and put the mail on its way. Think of it as a postal service. You just drop the parcel at the post office, they take care of any further setps.

The MUA just puts the mail on its way. As soon as it has been accepted by the first MTA the MUA assumes it to be sent. Again the postal analogue: As soon as you put a parcel at the post office for sending, you assume it is going to be delivered. If anything goes wrong on the route, you will get the parcel retourned. Exactly this is what happens when the mail causes issues on its way. The MTA will send a returning information to you (so called bounce) if the message could not be delivered to the next station.

Now the receiving side once more. I first go with the postal analgue again. If you were always reachable all the time and also always in teh same location, the post officer could directly come to you to deliver your mail. That would mean a MTA delivers a mail directly to you.

Unfortunately, you have a non-static IP (you are not always in the same location) and you are definitively not always there (not always at home). As a result, the MTA coudl try to deliver the mails but as you are not available, the mail would have been bounced (see above).

To avoid this, you have your post box. This is true both in email as well as normal mail. The post officer/MTA puts the mails in the box on his terms (timing). Whenever a message needs to be delivered he can do so. In case of the MTA this means nothing more than saving a file in a dedicated folder.

The postbox represents a synchronization elenment between you and the post officer. You can go to the post box anytime you find it suitable and look for your post. As the MTA saved the mail on the server, you do not have direct access. Here the MDA comes into play. The MDA allows access to the postbox on your behalf and according to your timing.