In the past, I’ve touched on the subject of how to set up a localhost to send emails. At some point it was enough with just installing
postfix and following a few prompts. Then port 25 was blocked by the ISP and it was necessary to set up a
postfix to use an external
SMTP server. Now, on Fedora 29 I wanted to enable e-mail sending using php’s
mail function. It took me a full day to do it, but finally got it working. It is worth mentioning that this time I didn’t want to set up
postfix to use an external
SMTP server, although I did try using
postfix, but as the logs revealed, port 25 is blocked by my ISP.
One thing to note, that actually cost me a lot of time, is that you won’t find a mail log file in Fedora 29. Fedora uses
systemd to do logging now, so you will have to use
journalctl to view the logs. Reviewing the logs is how I found out that
postfix was timing out when trying to send emails.
In any case, my idea wasn’t really to use
postfix. Fedora 29 ships with
esmtp which is a “send-only sendmail emulator” according to the man page. The nice thing about it, is that you should only have to make a
.esmtprc file on your home directory with the remote SMTP server information. This worked great. I could send emails using `mail` in the command line, and I could even fire up
php -a and use the
mail function to send out emails. Everything was great until I tried to send emails from one of my locally hosted dev sites (finally getting around to build buzu.me lol). The email was never even accepted for deliver, as denoted by the
false value returned by the
In order to investigate this matter, I decided to try to send emails as the apache user from the command line. This resulted in a error. The command complained about not being able to create a
.esmtp_queue directory on
/usr/share/httpd/. I decided to manually create it, and make apache the owner of it. I tested again, and it worked! You should know that at this time my
esmtprc is now located at
/etc/ so that apache can use it. I suppose I could create at
.esmtprc file in the
httpd directory, but I haven’t tried that.
I knew now that apache could send emails, so I decided to check again using the locally hosted site, and no luck.
mail continued to return
false, indicating that the email wasn’t even accepted for delivery. At this point, the only time the
mail function returned
true was when I used
postfix, but I had decided not to use it since
esmtp is made specifically for the purpose I intended.
One thing had changed though. Before I manually created the queue directory for the apache user, the
mail function simply failed, but now,
selinux was displaying an alert, but when I tried to open it, it was blank. I remembered that at some point I had seen an
SELinux entry in the logs, so I decided to re-visit the logs and look for a similar entry. I found this:
***** Plugin catchall_labels (83.8 confidence) suggests *******************
If you want to allow mktemp to have write access on the .esmtp_queue directory
Then you need to change the label on .esmtp_queue
# semanage fcontext -a -t FILE_TYPE '.esmtp_queue'
where FILE_TYPE is one of the following: admin_home_t, courier_spool_t, etc_aliases_t, etc_t, exim_log_t, exim_spool_t, mail_home_rw_t, mail_home_t, mail_spool_t, mqueue_spool_t, munin_var_lib_t, postfix_etc_t, qmail_spool_t, sendmail_log_t, system_mail_tmp_t, tmp_t, user_home_dir_t, uucpd_spool_t, var_log_t.
restorecon -v '.esmtp_queue'
***** Plugin catchall (17.1 confidence) suggests **************************
If you believe that mktemp should be allowed write access on the .esmtp_queue directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
allow this access for now by executing:
# ausearch -c 'mktemp' --raw | audit2allow -M my-mktemp
# semodule -X 300 -i my-mktemp.pp
I decided to change the context to
mail_home_rw_t and tried again. It worked.
It is worth noting that at some point I also did
setsebool httpd_can_sendmail=1. Without that,
httpd can’t use