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?


  • My understanding, which may be rather flawed: cron acts as a MUA... connecting to the mailx MTA... Sylpheed acts as a MUA connecting to a Dovecot or Courier or Postfix MTA Nov 7, 2018 at 1:33
  • My understanding of "part 2" regarding needing a MTA on the same machine is: No. ... The MTA is remotely situated on a domain's server. Nov 7, 2018 at 2:10
  • Then why does cron need a MTA installed on the same machine?
    – Tim
    Nov 7, 2018 at 2:11
  • >Then why does cron need a MTA installed on the same machine? ... because it doesn't connect to a remote machine's MTA. One could install a local MTA for Sylpheed to connect to... but generally there's a remote one that is used. Nov 7, 2018 at 2:21
  • Why does cron not connect to a remote machine's MTA, but need a local MTA? Why does Sylpheed more usually connect to a remoate MTA than local MTA? What is the difference between the purposes of connecting to a local MTA and to a remote MTA?
    – Tim
    Nov 7, 2018 at 2:33

3 Answers 3


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.

  • I think you are making an unnecessary distinction and maybe mixing up some concepts. Btw, MUAs do not have to be local, and do not have necessarily to use @ in a LAN setup Nov 7, 2018 at 4:02
  • 1
    @Rui your comment would be much more useful if you mentioned which distinction and which concepts you’re referring to. As it stands Wumpus would have to guess, which makes it hard to do anything to address the issues you raise... Nov 7, 2018 at 6:04
  • Unix mail does use a network... and along with cron uses Unix sockets... the "To" has an "@" ... user@localhost ... try it. mail user@localhost ... Unix mail will deliver it. Nov 7, 2018 at 14:02
  • 1
    @RubberStamp, and you can omit the @localhost part and it will still deliver it. No network required. The MTA was later extended to support one.
    – psusi
    Nov 7, 2018 at 17:48
  • 1
    "Network" needs to have a very careful definition... remember that localhost is ... and it's possible to have PAM utilize external authentication mechanisms like LDAP... The RFC address of the user is user@hostname ... mailx understands the use of the @ addressing scheme... and even includes such in its manual page under Recipient address specifications ... So, strictly speaking this answer is incorrect. Nov 7, 2018 at 18:03

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:


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           */
58 /* #define MAILCMD "/bin/mail"           -*/
59 /* #define MAILARGS "%s -d  %s"          -*/
60          /* -d = undocumented but common flag: deliver locally?
61           */
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.


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".

  • Thanks. (1) "cron itself can be configured to use any arbitrary mailer." Is "mailer" the same concept as MTA? (2) "most ISP do block port 25 connection." Which ISP do you mean? Is there an ISP which provides Internet access to the person who typed your telnet command telnet example.com 25? Is there also an ISP which makes the destination example.com 25 accessible from the Internet?
    – Tim
    Nov 7, 2018 at 16:26
  • @Tim ... added some ISP info... Nov 7, 2018 at 17:12
  • "But... most ISP do block port 25 connection.". Some may block incoming connections to port 25 ( I live in the US and have never had this ), but not outgoing (otherwise you would never be able to send mail ), which is what you are talking about here. "ISPs also generally blacklist their own dynamic IP address pools.", I think you are talking about SPF, which only suggests to other SMTP servers that any mail coming from @yourisp should only be accepted from the isp's official smtp server. It doesn't stop you from sending spam from other domains.
    – psusi
    Nov 7, 2018 at 18:05
  • @psusi ... Outgoing port 25 is generally blocked. The submission port is generally not blocked. However, the submission port is "supposed to" be configured using TLS... blacklisting is RBL checks. Emails from IPs listed in common RBL's are rejected right away... postfix uses reject_rbl_client option... don't know about other MTAs/SMTP. So, the blacklisting of dynamic IP address effectively limits spammers to IaaS services if they actually want to reach anyone besides the personal server crowd. Nov 7, 2018 at 18:35
  • No, it isn't... if port 25 were blocked, you would be unable to send any email. Ever.
    – psusi
    Nov 9, 2018 at 17:17

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.

  • Thanks. Why is sending process not symmetric with receiving process? The sending process has no something similar to MDA. How does MUA know what emails have been sent?
    – Tim
    Sep 11, 2020 at 21:23
  • @Tim, I just added a longer comment to the answer. I hope this makes a few points more clear. Feel free to ask further. Sep 12, 2020 at 17:47
  • Thanks. Could you convert the edit to a reply to unix.stackexchange.com/questions/609038/…? I will upvote
    – Tim
    Sep 12, 2020 at 18:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.