2

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.

  • 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 – RubberStamp Nov 7 '18 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. – RubberStamp Nov 7 '18 at 2:10
  • Then why does cron need a MTA installed on the same machine? – Tim Nov 7 '18 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. – RubberStamp Nov 7 '18 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 '18 at 2:33
6

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 – Rui F Ribeiro Nov 7 '18 at 4:02
  • @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... – Stephen Kitt Nov 7 '18 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. – RubberStamp Nov 7 '18 at 14:02
  • @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 '18 at 17:48
  • 1
    "Network" needs to have a very careful definition... remember that localhost is 127.0.0.0/8 ... 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. – RubberStamp Nov 7 '18 at 18:03
1

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

  • 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 '18 at 16:26
  • @Tim ... added some ISP info... – RubberStamp Nov 7 '18 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 '18 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. – RubberStamp Nov 7 '18 at 18:35
  • No, it isn't... if port 25 were blocked, you would be unable to send any email. Ever. – psusi Nov 9 '18 at 17:17
1

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

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.