Haack's Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
-------------------------------------------
  * **exim4** 
  * **Jonathan Haack**
  * **Haack's Networking**
  * **netcmnd@jonathanhaack.com** 

-------------------------------------------

#hacking #freesoftware #gnulinux 

First off, a big thanks to [[https://jasonschaefer.com|jason]] an [[http://regenerosity.com|geoff]] for helping me get this banged out – it was painful and tiring, but I got it working – and even better, I broke it four times and rebuilt it. Anyway, here is how to set up a send-only MTA that duals as a relay for other servers, including TLS configuration. First, download and install the packages and run the configuration tool:

  sudo apt install exim4 mailutils
  sudo dpkg-reconfigure exim4-config

On the ncurses screen that follows, select internet site; mail is sent and received directly using SMTP

{{ :computing:1.png |}}

On the next screen, put in your fully qualified domain name (FQDN) as follows:

{{ :computing:2.png |}}

The next screen is asking you for the addresses you want this instance of exim to listen from. In my case, I did not want to listen to any external connections – only to this server itself, the localhost, and on both ip4 and ip6. This is also the default, and so my configuration looks like:

{{ :computing:3.png |}}

On the next screen, don’t get confused like I did. The question is “for which [DNS entry should] this machine should consider itself the final destination” and the answer is the DNS entry you have pointing to your relay server, or in my case smtp.codetalkers.club:

{{ :computing:4.png |}}

The next screen is equally confusing and you might be tempted to enter the domains you intend to relay email for in this parameter field, but do not. Leaving this blank means that your server will not be considered a “fallback MX or mail gateway” for any other server’s email:

{{ :computing:5.png |}}

The next screen is where you can enter the domains you authorize to relay email through your server as follows. Note that it clearly states “Machines to relay email for” on this parameter. I permitted two of the external servers I manage as follows:

{{ :computing:6.png |}}

In the next screen, you are prompted about whether you would like to enable normal mode or a mode that is more suited towards dial-up connections. Unless you are actually using dial-up still, leave this parameter at its default of no:

{{ :computing:7.png |}}

The next field is for the location of the mailbox. I left it at the default:

{{ :computing:8.png |}}

The next field has huge ramifications for configuring exim4, especially if you intend to configure a different instance as a full mail server (MTA and IMAP). In my case, I wanted to keep things simple and use this as a workhorse relay for other servers that I curate where the IP and DNS do not permit direct sending of email. For those reasons, I left this at its default of no:

{{ :computing:9.png |}}

The next screen asks for the postmaster. However, simply adding an email address here will not work. Setting up a postmaster with a smarthost relay requires a special configuration which I am still working on. For now, I left this blank:

{{ :computing:10.png |}}

Okay, now we just need to verify your primary exim configuration file. You will notice that I removed the commas and horizontal list because, in cases where the relay will function for many different domains, it is not feasible to keep this in a gigantic horizontal array.

  sudo nano /etc/exim4/update-exim4.conf.conf
  
{{ :computing:11.png |}}

There are some other configurations necessary as well. There is the default configuration for exim4 and it needs to be revised as well. You need to adjust the last line to specify which ports this relay should listen on – exim’s directions tell you this right above the entry:

  sudo nano /etc/default/exim4
  
{{ :computing:12.png |}}

The relay should function now, and should be listening on ports 25, 587, and 10025. You should probably restart the services and/or reboot the machine. In my case, however, I wanted to use port 587 with TLS enabled, so I did a bit more first. First, the auto-generated configuration file did not include a parameter enabling TLS. More importantly, every time I added it manually and restarted the service, it disappeared:

  sudo nano /var/lib/exim4/config.autogenerated
  <MAIN_TLS_ENABLE = yes>
  sudo systemctl restart exim4

This is because it is autogenerated. And thanks to jason again for digging through resources at /usr/share/doc/exim4-base/README.Debian.gz in order to figure this out. The solution is to create a file called exim4.conf.localmacros inside /etc/exim4/ which will be consulted when the service is restarted and then accordingly populate the auto-generated configuration above. Here is how I did that:

  sudo nano /etc/exim4/exim4.conf.localmacros
  <MAIN_TLS_ENABLE = yes>
  sudo systemctl restart exim4

Now that this is done, you should open up the auto-generated configuration and see a new entry:

{{ :computing:13.png |}}

Notice the MAIN_TLS_ENABLE = yes line is added and will this time, survive a service restart because of the localmacros file created above. Next, it is time to symlink your TLS certificate and keypair to the default location for exim4. In my case, I already had Let’s Encrypt set up on this server for my primary domain, so I just used that pair as follows (proceed with caution):

  sudo -i
  cd /etc/exim4
  ln -s ../letsencrypt/live/teacher.codetalkers.club/fullchain.pem exim.crt
  ln -s ../letsencrypt/live/teacher.codetalkers.club/privkey.pem exim.key

When this is done, you will need to adjust the group owner and permissions on the certificate and key directories to allow the Debian-exim group to access these keys. Otherwise they will not be accessible. I think the following permissions should be safe and yet also permissible enough for your TLS-enabled services to function, but I welcome feedback (as always) if you think I got it wrong:

  sudo -i
  chown root:Debian-exim -R /etc/letsencrypt/live/
  chown root:Debian-exim -R /etc/letsencrypt/archive/
  chmod 0755 -R /etc/letsencrypt/live/
  chmod 0755 -R /etc/letsencrypt/archive/

Try not to mess up on the symlinks and make sure you are using relative paths as I did above, and if you mess up, add the -sf flag to fix them or purge certbot and start over. Be careful here and best to run as root instead of using sudo so you can use tab completion. Once this is done, you should have some standard output like this:

{{ :computing:14.png |}}

Okay, it is now time to verify that your TLS is functioning correctly. If you are using a firewall, make sure to open up ports 25, 587, and 10025. Here is how I verified my relay’s TLS functionality using swaks. You can also nc and/or telnet:

  swaks -a -tls -q HELO -s smtp.codetalkers.club:587 -au test -ap '<>'

In full disclosure, I am still debugging this on the testing host, but once it is working, the swaks output will look like my functioning relay. ;0

{{ :computing:15.png |}}

Okay, now that you have everything set up on the relay server, we need to set up an exim4 client to test and send an email to it with. First, install exim4 on the client and begin the setup for “mail sent by smarthost; no local mail”

  sudo apt install exim4 mailutils
  
{{ :computing:16.png |}}

The next screen allows you to choose the name of the client machine – I stuck with the name of the host which it auto-populated for me:

{{ :computing:17.png |}}

The next screen asks you to specify where exim4 should listen. Again, you want it to listen on localhost since you are not (even more so in this case), listening to any external services:

{{ :computing:18.png |}}

Likewise, on the next screen you are also not accepting incoming connections to the client machine, so leave the next parameter empty as well indicating that you will not accept any connections besides localhost:

{{ :computing:19.png |}}

The next screen allows you to specify a name by which this client can identify itself to those servers it makes connections with – again, I left this as the default hostname:

{{ :computing:20.png |}}

The next screen – finally – is where you input the server name and port for the relay server you set up above. Since I have TLS activated on port 587 for my relay, I additionally specified that port, although I do allow connections from the others for other client workstations:

{{ :computing:21.png |}}

Again, unless you are using dial-up, say no on the next screen:

{{ :computing:22.png |}}

Unless you have a need to or the knowledge of why, leave the configuration as standalone:

{{ :computing:23.png |}}

Okay, restart the exim4 service for good measure and send a test email. First, let’s run a tail on the exim4 log on the relay server in case we need to debug or this test fails:

  sudo tail -f /var/log/exim4/mainlog

With the log running on the relay server, let’s send a test email from the client workstation as follows :

  sudo systemctl restart exim4
  echo "Hi Relay Server, I am testing you" | mail -s "Subject - Test" oemb1905@jonathanhaack.com

If everything was successful, you should get some log output like this:

{{ :computing:24.png |}}

Okay! Happy Hacking!

Update: If your host shares the domain with an email you use elsewhere, make sure to exclude the main local domains and comment that out.
  
  sudo nano /etc/exim4/exim4.conf.template
  domainlist local_domains =
  
There is a big mistake above, where I specify for exim4 to listen to nothing instead of everything.  Here is what you need to change:

  sudo nano /etc/exim4/update-exim4.conf.conf
  dc_local_interfaces='::::0:0.0.0.0'

On major system upgrades, exim4 often gets hosed.  Specifically, you need to fully remove and purge it, and then when you reinstall it, the command `dpkg-reconfigure exim4-config` has no ncurses output and just fails.  Here is what I found that works:

  sudo mv /etc/exim4 /etc/exim4-old
  sudo apt-get -o Dpkg::Options::="--force-confmiss" install --reinstall exim4-config
  sudo dpkg-reconfigure exim4-config
  
Rebuilding again today lol.  Messages won't send from clients using the relay.  Delete these and restart the exim4 service:

  rm /var/spool/exim4/db/*
  rm /var/spool/exim4/input/*
  rm /var/spool/exim4/msglog/*
  rm /var/log/exim4/*
  sysemctl restart exim4.service
  
To delete all frozen emails and/or individually delete/read.

  exim -bp | awk '/^ *[0-9]+[mhd]/{print "exim -Mrm " $3}' | bash

To read email body:

  exim4 -Mvb <message id>

To view the email header:

  exim -Mvh <message id>

TLS can pitch an annoying warning that states "TLS connections will fail. Suggested action: either install a certificate or change tls_advertise_hosts option."  I should not be getting this Warning, nor should I have to change any options in the config, since I am already advertising TLS and properly accepting smtp connections from it (see swaks output above).  Most online resources talk about getting this warning when it is a false positive, but in this case, it is false negative, meaning it is saying I don't have this but I do.  Here's how to suppress the irrelevant and in this case, incorrect, warning:

  sudo nano /etc/exim4/exim4.conf.template
  
Search for "A weaker form" and once you get to that section look for where it states ''.else'' and then "Use upstream defaults" and then closes with ''.endif'' - right in between else/endif, put the following line:

  tls_advertise_hosts =

Just so you are clear, it will look like this:

{{ :computing:tls.png?400 |}}

To stop the relay from barfing when clients with incomplete TLS emails through it, you can do the following on the client sending th email (not on the server/relay):

  sudo nano /etc/exim4/exim4.conf.localmacros
  REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS = !*
  systemctl restart exim4

 --- //[[alerts@haacksnetworking.org|oemb1905]] 2024/12/16 01:30//
Haack's Wiki

User Tools

Site Tools

Page Tools
