How To Setup A Mail Relay Server To Relay Mail Through MXRoute [CentOS, Alma, Rocky]

FrankZFrankZ Moderator
edited January 26 in LES Talk

This is a guide on how to set up a sendmail mail relay server to relay outbound mail via MXRoute. You will not need to have a reverse DNS (ptr) record for this VM's IPv4 address or worry about IP reputation. You can use this relay server to relay mail through MXRoute from any other VPS as well.
If you're sending a limited amount of mail this outbound only mail relay server can be setup on a small VM with as little as 1 core, 512MB Ram, 5GB disk. If you send a lot of mail than you should up size your VM accordingly.

In part one of this guide we will set up an outbound only mail relay server that will connect and send mail via MXRoute.
In part two we will show how to set up sendmail on any VPS that you want to relay mail through the outbound only mail relay server that you set up in part one. You can also use postfix or any other mail service on the secondary servers to relay through the outbound only mail relay server.

NOTE: In an effort to make this rather long guide a more reasonable size I have put many of the code blocks that you will need to copy into display pull downs. You will need to click the to see this information.


Part One

Install required packages

CentOS 7:
yum -y install sendmail sendmail-cf cyrus-sasl cyrus-sasl-plain
yum -y remove postfix

CentOS 8, Alma8linux, Rockylinux:
dnf -y install sendmail sendmail-cf cyrus-sasl cyrus-sasl-plain
dnf -y remove postfix

Make sure your hostname is set

Edit /etc/hosts and ensure there is a line [your IPv4] tab [your host name]
Edit /etc/sysconfig/network and ensure there is a line HOSTNAME=[your host name]

Setup the certificates

Get a cert from Let's Encrypt for your mail relay server (I am not showing how to do this here)
Make a subdirectory called "certs" under /etc/mail/:
mkdir /etc/mail/certs


Copy the cert template in this drop down to /etc/mail/certs/sendmail.pem using a text editor
-----BEGIN PRIVATE KEY-----
Put your mail relay host private key here
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
Put your mail relay host certificate here
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG /kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4 avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2 yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+ HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX nLRbwHOoq7hHwg==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFYDCCBEigAwIBAgIQQAF3ITfU6UK47naqPGQKtzANBgkqhkiG9w0BAQsFADA/ MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT DkRTVCBSb290IENBIFgzMB4XDTIxMDEyMDE5MTQwM1oXDTI0MDkzMDE4MTQwM1ow TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwggIiMA0GCSqGSIb3DQEB AQUAA4ICDwAwggIKAoICAQCt6CRz9BQ385ueK1coHIe+3LffOJCMbjzmV6B493XC ov71am72AE8o295ohmxEk7axY/0UEmu/H9LqMZshftEzPLpI9d1537O4/xLxIZpL wYqGcWlKZmZsj348cL+tKSIG8+TA5oCu4kuPt5l+lAOf00eXfJlII1PoOK5PCm+D LtFJV4yAdLbaL9A4jXsDcCEbdfIwPPqPrt3aY6vrFk/CjhFLfs8L6P+1dy70sntK 4EwSJQxwjQMpoOFTJOwT2e4ZvxCzSow/iaNhUd6shweU9GNx7C7ib1uYgeGJXDR5 bHbvO5BieebbpJovJsXQEOEO3tkQjhb7t/eo98flAgeYjzYIlefiN5YNNnWe+w5y sR2bvAP5SQXYgd0FtCrWQemsAXaVCg/Y39W9Eh81LygXbNKYwagJZHduRze6zqxZ Xmidf3LWicUGQSk+WT7dJvUkyRGnWqNMQB9GoZm1pzpRboY7nn1ypxIFeFntPlF4 FQsDj43QLwWyPntKHEtzBRL8xurgUBN8Q5N0s8p0544fAQjQMNRbcTa0B7rBMDBc SLeCO5imfWCKoqMpgsy6vYMEG6KDA0Gh1gXxG8K28Kh8hjtGqEgqiNx2mna/H2ql PRmP6zjzZN7IKw0KKP/32+IVQtQi0Cdd4Xn+GOdwiK1O5tmLOsbdJ1Fu/7xk9TND TwIDAQABo4IBRjCCAUIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw SwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5pZGVudHJ1 c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTEp7Gkeyxx +tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEEAYLfEwEB ATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2VuY3J5cHQu b3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0LmNvbS9E U1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFHm0WeZ7tuXkAXOACIjIGlj26Ztu MA0GCSqGSIb3DQEBCwUAA4IBAQAKcwBslm7/DlLQrt2M51oGrS+o44+/yQoDFVDC 5WxCu2+b9LRPwkSICHXM6webFGJueN7sJ7o5XPWioW5WlHAQU7G75K/QosMrAdSW 9MUgNTP52GE24HGNtLi1qoJFlcDyqSMo59ahy2cI2qBDLKobkx/J3vWraV0T9VuG WCLKTVXkcGdtwlfFRjlBz4pYg1htmf5X6DYO8A4jqv2Il9DjXA6USbW1FzXSLr9O he8Y4IWS6wY7bCkjCWDcRQJMEhg76fsO3txE+FiYruq9RUWhiF1myv4Q6W+CyBFC Dfvp7OOGAN6dEOM4+qR9sdjoSYKEBpsr6GtPAQw4dy753ec5
-----END CERTIFICATE-----


After copying the cert template to /etc/mail/certs/sendmail.pem you will need to modify the following:
1. Replace Put your mail relay host private key here with the private key you received with your certificate from Let's Encrypt for your relay mail server host name.
2. Replace Put your mail relay host certificate here with the certificate you received from Let's Encrypt for your relay mail server host name.

While in the directory /etc/mail/certs execute the commands:
openssl dhparam -out dhparam.pem 4096
and
ln -s /etc/ssl/certs/ca-bundle.crt ca-bundle.crt
and
chmod 600 dhparam.pem sendmail.pem

You should now have three files in your /etc/mail/certs directory

ca-bundle.crt [a soft link]
dhparam.pem
sendmail.pem

The certificate will need to be undated before it expires.
I should add a script to auto update the mail server cert from LetsEncrypt. (coming soon™)

Configure sendmail.mc

Move the original sendmail.mc to sendmail.mc.org:
mv /etc/mail/sendmail.mc /etc/mail/sendmail.mc.org


Copy the code in this drop down to /etc/mail/sendmail.mc using a text editor
divert(-1)dnl
dnl #
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl
VERSIONID(`setup for linux')dnl
OSTYPE(`linux')dnl
dnl #
dnl # Do not advertize sendmail version.
dnl #
define(`confSMTP_LOGIN_MSG', `$j Sendmail; $b')dnl
dnl #
dnl # default logging level is 9, you might want to set it higher to
dnl # debug the configuration
dnl #
dnl define(`confLOG_LEVEL', `9')dnl
dnl #
dnl # Your outgoing mail will be sent out through an external MXRoute server
dnl # Change the friday.mxlogin.com to the MXRoute server to which you have been assigned
dnl #
define(`SMART_HOST',`friday.mxlogin.com')dnl
define(`RELAY_MAILER_ARGS',`TCP $h 587')
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
FEATURE(`authinfo',`hash /etc/mail/authinfo')dnl
dnl #
define(`confDEF_USER_ID', ``8:12'')dnl
define(`confTO_CONNECT', `1m')dnl
define(`confTRY_NULL_MX_LIST', `True')dnl
define(`confDONT_PROBE_INTERFACES', `True')dnl
define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail')dnl
define(`ALIAS_FILE', `/etc/aliases')dnl
define(`STATUS_FILE', `/var/log/mail/statistics')dnl
define(`UUCP_MAILER_MAX', `2000000')dnl
define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl
define(`confPRIVACY_FLAGS', `goaway,restrictqrun')dnl
define(`confAUTH_OPTIONS', `A')dnl
PrivacyOptions=nobodyreturn
dnl #
define(`confCACERT_PATH', `/etc/mail/certs')dnl
define(`confCACERT', `/etc/mail/certs/ca-bundle.crt')dnl
define(`confSERVER_CERT', `/etc/mail/certs/sendmail.pem')dnl
define(`confSERVER_KEY', `/etc/mail/certs/sendmail.pem')dnl
define(`confCLIENT_CERT', `/etc/mail/certs/sendmail.pem')dnl
define(`confCLIENT_KEY', `/etc/mail/certs/sendmail.pem')dnl
define(`confDH_PARAMETERS', `/etc/mail/certs/dhparam.pem')dnl
dnl #
define(`confTO_IDENT', `0')dnl
FEATURE(`no_default_msa', `dnl')dnl
FEATURE(`smrsh', `/usr/sbin/smrsh')dnl
FEATURE(`mailertable', `hash -o /etc/mail/mailertable.db')dnl
FEATURE(`virtusertable', `hash -o /etc/mail/virtusertable.db')dnl
FEATURE(redirect)dnl
FEATURE(always_add_domain)dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
dnl #
dnl # The following limits the number of processes sendmail can fork to accept
dnl # incoming messages or process its message queues to 20.) sendmail refuses
dnl # to accept connections once it has reached its quota of child processes.
dnl #
define(`confMAX_DAEMON_CHILDREN', `20')dnl
dnl #
dnl # Limits the number of new connections per second. This caps the overhead
dnl # incurred due to forking new sendmail processes. May be useful against
dnl # DoS attacks or barrages of spam. (As mentioned below, a per-IP address
dnl # limit would be useful but is not available as an option at this writing.)
dnl #
define(`confCONNECTION_RATE_THROTTLE', `3')dnl
dnl #
dnl # The -t option will retry delivery if e.g. the user runs over his quota.
dnl #
FEATURE(local_procmail, `', `procmail -t -Y -a $h -d $u')dnl
FEATURE(`access_db', `hash -T<TMPF> -o /etc/mail/access.db')dnl
FEATURE(`blacklist_recipients')dnl
EXPOSED_USER(`root')dnl
dnl #
dnl # The following causes sendmail to only listen on the IPv4 loopback address
dnl # 127.0.0.1 and not on any other network devices. Remove the loopback
dnl # address restriction to accept email from the internet or intranet.
dnl #
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
dnl #
dnl # The following causes sendmail to additionally listen to port 587 for
dnl # mail from MUAs that authenticate. Roaming users who can't reach their
dnl # preferred sendmail daemon due to port 25 being blocked or redirected find
dnl # this useful.
dnl #
DAEMON_OPTIONS(`Port=submission,Addr=127.0.0.1, Name=MSA, M=Ea')dnl
dnl #
dnl # The following causes sendmail to additionally listen to port 465, but
dnl # starting immediately in TLS mode upon connecting. Port 25 or 587 followed
dnl # by STARTTLS is preferred, but roaming clients using Outlook Express can't
dnl # do STARTTLS on ports other than 25. Mozilla Mail can ONLY use STARTTLS
dnl # and doesn't support the deprecated smtps; Evolution <1.1.1 uses smtps</td>
dnl # when SSL is enabled-- STARTTLS support is available in version 1.1.1.
dnl #
dnl # For this to work your OpenSSL certificates must be configured.
dnl #
DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA,Family=inet,Addr=127.0.0.1,M=s')dnl
dnl #
dnl # The following causes sendmail to additionally listen on the IPv6 loopback
dnl # device. Remove the loopback address restriction listen to the network.
dnl #
dnl DAEMON_OPTIONS(`port=smtp,Addr=::1, Name=MTA-v6, Family=inet6')dnl
dnl #
dnl # enable both ipv6 and ipv4 in sendmail:
dnl #
dnl DAEMON_OPTIONS(`Name=MTA-v4, Family=inet, Name=MTA-v6, Family=inet6')
dnl #
dnl # We strongly recommend not accepting unresolvable domains if you want to
dnl # protect yourself from spam. However, the laptop and users on computers
dnl # that do not have 24x7 DNS do need this.
dnl #
dnl # FEATURE(`accept_unresolvable_domains')dnl
dnl #
dnl # Also accept email sent to "localhost.localdomain" as local email.
dnl #
LOCAL_DOMAIN(`localhost.localdomain')dnl
dnl #
dnl # The following example makes mail from this host and any additional
dnl # specified domains appear to be sent from mydomain.com
dnl #
dnl MASQUERADE_AS(`mydomain.com')dnl
dnl #
dnl # masquerade not just the headers, but the envelope as well
dnl #
dnl FEATURE(masquerade_envelope)dnl
dnl #
dnl # masquerade not just @mydomainalias.com, but @*.mydomainalias.com as well
dnl #
dnl FEATURE(masquerade_entire_domain)dnl
dnl #
dnl MASQUERADE_DOMAIN(localhost)dnl
dnl MASQUERADE_DOMAIN(localhost.localdomain)dnl
dnl MASQUERADE_DOMAIN(mydomainalias.com)dnl
dnl MASQUERADE_DOMAIN(mydomain.lan)dnl
define(`confHELO_NAME',`myhost.mydomain')
define(`confDOMAIN_NAME',`myhost.mydomain')
CLIENT_OPTIONS(`Addr=Family=inet,Addr=123.123.123.123')
CLIENT_OPTIONS(`Family=inet6,Addr=::ffff:123.123.123.123')dnl
dnl # FEATURE(`require_rdns')
DAEMON_OPTIONS(`Name=MTARelay,Family=inet,Port=2525')
dnl #
LOCAL_CONFIG
dnl # Certificates and keys must also have been configured
O CipherList=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:!DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
dnl # Disable SSLv2, SSLv3, TLSv1.0 (TLSv1.1 and TLSv1.2 should be supported)
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_NO_TLSv1 +SSL_OP_CIPHER_SERVER_PREFERENCE
dnl # Set options required when operating as client to remote servers
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_NO_TLSv1
MAILER(smtp)dnl
MAILER(procmail)dnl
dnl MAILER(cyrusv2)dnl


After copying the code to /etc/mail/sendmail.mc you will need to modify the following:
1. Change friday.mxlogin.com to the mail server you were assigned by MXRoute.
2. Change both occurances of 123.123.123.123 to the IPv4 of your mail relay server.
3. Change both occurances of myhost.mydomain to the hostname.domainname of your mail relay server.

After making the above changes execute the command:
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

Setup MXRoute authinfo


Copy the code in this drop down to /etc/mail/authinfo using a text editor
AuthInfo:friday.mxlogin.com "U:[your user name]@friday.mxlogin.com" "I:[your user name]@friday.mxlogin.com" "P:[your password]" "M:LOGIN PLAIN"


After copying the code to /etc/mail/authinfo you will need to modify the following:
1. Change both occurances of [your user name] to the username that you were assigned by MXRoute.
2. Change all occurances of friday.mxlogin.com to the mail server you were assigned by MXRoute.
3. Change [your password] to the password that you were assigned by MXRoute.

After making the above changes ensure that you are in the directory /etc/mail and execute the command:
makemap hash authinfo < authinfo

Enable sendmail, saslauthd, and reboot

Execute the following commands to enable sendmail and saslauthd to start on boot and then reboot:
/usr/bin/systemctl enable sendmail.service
/usr/bin/systemctl enable saslauthd.service
reboot

Set SPF DNS record

Add the IPv4 address of this mail relay server and MXRoute to your DNS spf record:
TXT "v=spf1 +ip4:[IPv4 address of this mail relay server] include:mxlogin.com -all"

Is it working ?

Test if everything works as expected by running this command:
echo "Subject: hello" | sendmail [email protected]
(replace [email protected] with your email address)

Check the log file:
cat /var/log/maillog

If you see stat=Sent (OK, you are sending your mail through MXRoute:

Jan 9 16:40:55 f sendmail[2246]: 309KF3K5001390: to=<[email protected]>, ctladdr=<[email protected][your relay mail server]> (0/0), delay=01:25:51, xdelay=00:00:01, mailer=relay, pri=750282, relay=friday.mxlogin.com. [159.69.65.104], dsn=2.0.0, stat=Sent (OK id=1pEzt1-0004Nf-UP)

If you see stat=Deferred, it is not working:

Jan 9 15:30:02 f sendmail[1848]: 309KF3K5001390: to=<[email protected]>, ctladdr=<[email protected][your relay mail server]> (0/0), delay=00:14:58, xdelay=00:00:00, mailer=relay, pri=390282, relay=friday.mxlogin.com., dsn=4.0.0, stat=Deferred

NOTES

If you make any revisions to /etc/mail/sendmail.mc you will need to execute:
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

If you make any revisions to /etc/mail/authinfo you will need to execute:
makemap hash authinfo < authinfo

Then restart sendmail:
/usr/bin/systemctl restart sendmail.service

So that the changes you made will take effect.

Are we done yet ?

If you are NOT planning to have any other VMs relay through this mail relay server you are done. All mail from this VM will relay via MXRoute. While sendmail is listening on port 2525 no mail will be relayed except from localhost.

If you DO want to relay other VMs mail through this mail server to also send their mail via MXRoute then continue below.

Allow other VMs to relay through this server

Open /etc/mail/access in your favorite text editor and add each of the VMs that you want to allow mail to relay through this server by adding their IP address, each on a seperate line, at the bottom of the file as Connect:123.123.123.123 RELAY.


An example file is shown in this drop down. Change 123.123.123.123 to the IPv4 of the VM you wish to allow to relay via your mail relay server.
# Check the /usr/share/doc/sendmail/README.cf file for a description
# of the format of this file. (search for access_db in that file)
# The /usr/share/doc/sendmail/README.cf is part of the sendmail-doc
# package.
#
# If you want to use AuthInfo with "M:PLAIN LOGIN", make sure to have the
# cyrus-sasl-plain package installed.
#
# By default we allow relaying from localhost...
Connect:localhost.localdomain RELAY
Connect:localhost RELAY
Connect:127.0.0.1 RELAY
#
Connect:123.123.123.123 RELAY

After you have added all the VMs you wish to allow to relay to MXRoute via this mail server, and saved the file, execute this command:
makemap hash /etc/mail/access.db < /etc/mail/access

Restart sendmail:
/usr/bin/systemctl restart sendmail.service

You will need to execute the two commands above anytime you make any additions or subtractions to the /etc/mail/access file for the changes to take effect.

Don't forget to open your firewall

To relay mail via your outbound only mail server from other VMs you must open your firewall for port 2525 access.

For firewalld:
firewall-cmd --permanent --zone=public --add-port=2525/tcp
service firewalld stop
service firewalld start


Part Two

In part two we will show how to set up sendmail on any VPS that you want to relay mail through the mail relay server that you set up in part one. It's much easier and faster.

Install required packages

CentOS 7:
yum -y install sendmail sendmail-cf
yum -y remove postfix

CentOS 8, Alma8linux, Rockylinux:
dnf -y install sendmail sendmail-cf
dnf -y remove postfix

Make sure your hostname is set

Edit /etc/hosts and ensure there is a line [your IPv4] tab [your host name]
Edit /etc/sysconfig/network and ensure there is a line HOSTNAME=[your host name]

Edit the sendmail.mc file

Open /etc/mail/sendmail.mc with your favorite text editor and add the lines in the pull down near the bottom of the file between the quoted lines shown above and below the pull down box.

dnl MASQUERADE_DOMAIN(mydomain.lan)dnl

CLIENT_OPTIONS(`Family=inet6,Addr=::ffff:123.123.123.123')dnl
define(`SMART_HOST',`myrelay.mydomain')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 2525')dnl

MAILER(smtp)dnl
MAILER(procmail)dnl
dnl MAILER(cyrusv2)dnl

After copying the code to /etc/mail/sendmail.mc you will need to modify the following:
1. Change 123.123.123.123 to the IPv4 of the server that is being installed.
2. Change myrelay.mydomain to the hostname.domainname of your mail relay server from part one.

After making the above changes execute the command:
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

Enable sendmail and reboot

Execute the following commands to enable sendmail to start on boot and start now :
/usr/bin/systemctl enable sendmail.service
reboot

Set SPF DNS record

If you have not done so previously, add the IPv4 address of the mail relay server and MXRoute to your DNS spf record of the domains for which this VM will be sending mail:
TXT "v=spf1 +ip4:[IPv4 address of mail relay server] include:mxlogin.com -all"

Is it working ?

Test if everything works as expected by running this command:
echo "Subject: hello" | sendmail [email protected]
(replace [email protected] with your email address)

Check the log file:
cat /var/log/maillog

If you see stat=Sent, and Message accepted for delivery you are sending your mail through your mail relay server:

Jan 10 04:27:12 localhost sendmail[2993586]: STARTTLS=client, relay=my.relayserver., version=TLSv1.3, verify=OK, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Jan 10 04:27:13 localhost sendmail[2993586]: 30A9RCpK2993585: [email protected], ctladdr=<[email protected]> (0/0), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=149367, relay=my.relayserver. [IPv4 for my.relayserver], dsn=2.0.0, stat=Sent (30A9RCkP001947 Message accepted for delivery)

On the mail relay server from part one these are the logs of the same email message successfully being relayed through to MXRoute:

Jan 10 04:27:13 my sendmail[1947]: 30A9RCkP001947: from=<[email protected]>, size=11346, class=-60, nrcpts=1, msgid=<[email protected]>, proto=ESMTPS, daemon=MTARelay, relay=the1stvps [IPv4 of 1st vps]
Jan 10 04:27:16 my sendmail[1949]: STARTTLS=client, relay=friday.mxlogin.com., version=TLSv1.2, verify=OK, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128
Jan 10 04:27:17 my sendmail[1949]: 30A9RCkP001947: to=<[email protected]>, delay=00:00:04, xdelay=00:00:04, mailer=relay, pri=239346, relay=friday.mxlogin.com. [159.69.65.104], dsn=2.0.0, stat=Sent (OK id=1pFAuc-0004BM-Uh)

If you see stat=Deferred Connection timed out , it is not working.
In this case the firewall was not open for port 2525 on mail relay server:

Jan 10 04:24:01 localhost sendmail[2987677]: 30A8S7uH2987677: to=<[email protected]>, delay=08:45:57, xdelay=00:00:00, mailer=relay, pri=931045, relay=my.mailrelayserver., dsn=4.0.0, stat=Deferred:Connection timed out with my.mailrelayserver.

If you see stat=User unknown , it is not working.
In this case the IPv4 of this server was not in the /etc/mail/access file on the mail relay server:

Jan 10 22:30:47 localhost sendmail[3093806]: 30B3UkCR3093806: [email protected], delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=32612, relay=my.relayserver. [IPv4 of my.relaysever], dsn=5.7.1, stat=User unknown

This will be shown on the mail relay server as the following Relaying denied error.

Jan 10 22:30:47 my sendmail[1363]: 30B3UjUR001363: ruleset=check_rcpt, arg1=<[email protected]>, relay=the1stvps [IPv4 of 1st VPS], reject=550 5.7.1 <[email protected]>... Relaying denied

Are we done yet ?

Yes, for this guide that is it for now.....
But no you are not done yet. At a minumum servers that send outbound mail should use DKIM in addition to having SPF records and all the good stuff that MXRoute provides.



A warning from MXRoute so as to not cause problems

@jarland said:
It’s worth noting that a slight variation on this kind of setup consumes a significant amount of my time trying to protect the infrastructure from being overwhelmed by pure junk that drags down IP reputation by increasing the association between our IPs and spam folders. These are the big line items:

  1. Almost no one who does this cares that their hostname isn’t an actual valid domain, forcing me to locate all of their server hostnames and add them to a banned sender list so they get errors instead of flooding the queue with junk I can’t deliver or bounce.
  2. That cron job you have set to run every minute sends a notification, and the person who sets this up commonly has all of these emails sent to their Gmail address.
  3. A simple command line interface or a cron job notification lacks the required headers that a legitimate email client would add without the user noticing.

Number 1 causes our mail queues to be packed full of “[email protected]{1..999}” emails that I can’t and won’t deliver because they’re not from valid envelope senders. But I can’t say that these are inherently bad and prevent them from going out before I identify each one of them because temporary DNS issues could cause a sending address to appear invalid that isn’t later. So I queue them, but then I audit the queues every day for this junk and use it to build my banned sender list (ex. *@localhost, *@vps1, *@vps.local, etc.).

Number 2 loops in with #1, and the two items work hand in hand to try to overly associate our IP addresses with Gmail’s spam folder, and number 3 comes in here as part of that. A bad sending address, a cron job notification that the user never meant for human consumption (and will never read, save for the 1 in a million user who might), and a lack of valid headers combined with Gmail’s threading feature mean you see one little junk email in your Spam folder, but you actually sent 1,440 junk emails per cron job to Gmail that were all destined to the spam folder. Combine that with the 600 other users doing the same thing, and you then have 864,000 emails from our platform daily, which are guaranteed to land in Gmail’s spam folder. Almost none of those users even meant to send those emails. The users rarely have any idea that they sent them, and they have no plan of gaining anything from it. It’s hard to let all of that through and then tell people I’m focused on doing everything I can to ensure inbox delivery.

All this to say, it’s good to be able to configure your systems to do this, but please keep one thing in mind: The MXroute platform is designed to send emails that are intended for either human consumption or automatic processing. It is not intended to be used as a garbage delivery system for Gmail. It also can’t be used as a garbage delivery system for Gmail, expecting that intentionally sent emails have a high probability of landing in the inbox. It can be one or the other. It can’t be both. Doing everything I can to get intentional emails into the inbox has always been my top focus. So please, if you do this, take a moment to consider what your server is doing and how it may use this configuration in ways you weren’t thinking of at the time.

Do make sure that your sending addresses are always valid. If your hostname isn’t valid, has no MX or SPF records itself, then your cron jobs and other system emails are going to be sending as invalid envelope senders. Think “[email protected]” that’s not valid, even “[email protected]” is invalid if myvps.mydomain.tld lacks valid MX/SPF. Most of that is fine if you’re sending to yourself to be delivered to an inbox on the same MXroute server that your service is hosted on, but if you’re sending these out to remote recipients that’s when you really need to dot your I’s and cross your T’s, making sure you have everything done properly.

Comments

  • :+1:

    Thanked by (1)FrankZ

    Just sitting in my cave wondering at what point life went wrong.

  • MasonMason AdministratorOG

    Thanks for the contribution and easy-to-follow write-up, @FrankZ!

    Thanked by (1)FrankZ

    Head Janitor @ LES • AboutRulesSupportDonate

  • What's the purpose of including the mail relay server's IP address in the SPF record?
    This IP wouldn't connect to recipient MX servers.

    Thanked by (1)FrankZ

    3 of 3 my VirMach VPS are online, but you should consider Webhosting24 aff or Nexril aff.
    box5 is the culprit - @Fritz ; yoursunny is my dinner for tonight - @FatGrizzly

  • Not_OlesNot_Oles Hosting ProviderContent Writer

    Hi @FrankZ! Thanks for the great article! I seem to recall hearing somewhere that using the hardfail qualifier "-all" in the spf record might result in emails becoming slightly more likely to be classified as spam. Apparently, and counter intuitively, the softfail qualifier "~all" might work better for deliverability. I wish I remembered the source for this. ¡Saludos!

    Thanked by (2)FrankZ abtdw

    Tom. 穆坦然. Not Oles. Happy 233 哈哈哈 New York City guy visiting Mexico! How is your 文言文?
    The MetalVPS.com website ran very speedily on MicroLXC.net! Thanks to @Neoon!

  • very nice tutor 💯

    Thanked by (1)FrankZ

    free KVM & free LXC on stock
  • edited January 19

    very nice turtle💯

    Thanked by (2)ehab FrankZ

    Join masochist club: https://virmach.com/special-offers/
    Ya cannot Whaaaaaaaaaaaaaaaagh everywhere

  • That's a lot of steps.

  • ehabehab Content Writer

    @imok said:
    That's a lot of steps.

    i can help you .... give me your passwords,

    Thanked by (1)FrankZ
  • MasonMason AdministratorOG

    @imok said:
    That's a lot of steps.

    "No thanks, God, that's a lot of steps." - @imok

    Thanked by (2)imok FrankZ

    Head Janitor @ LES • AboutRulesSupportDonate

  • vyasvyas OGContent Writer

    @imok said:
    That's a lot of steps.

    @FrankZ means business. he is implying, "Step up or be left out."

    Thanked by (1)FrankZ

    VPS reviews | | MicroLXC | English is my nth language.

  • edited January 19

    @FrankZ said: If you're sending a limited amount of mail..

    ;)

    Thanked by (1)FrankZ

    It wisnae me! A big boy done it and ran away.
    NVMe2G for life! until death (the end is nigh)

  • FrankZFrankZ Moderator

    @yoursunny said:
    What's the purpose of including the mail relay server's IP address in the SPF record?
    This IP wouldn't connect to recipient MX servers.

    Force of habit. On the few occasions that I have had issues connecting to MXRoute and send mail directly from the relay server, I have sometimes forgotten to add the IP of the relay server to the SPF record, which with the hard fail SPF record causes mail to be rejected. Force of habit also has me set up a reverse DNS entry for the relay server by default even though that is also not required to send outbound mail via MXRoute.


    @Not_Oles said: Hi @FrankZ! Thanks for the great article! I seem to recall hearing somewhere that using the hardfail qualifier "-all" in the spf record might result in emails becoming slightly more likely to be classified as spam. Apparently, and counter intuitively, the softfail qualifier "~all" might work better for deliverability. I wish I remembered the source for this. ¡Saludos!

    Hi Tom and thank you for the compliment on my first attempt at this sort of thing :)
    Most people do use the the softfail qualifier "~all" instead of the hardfail qualifier "-all" and it is reasonable to do so. Personally I do not recommend doing this as the softfail qualifier is taken by many receiving mail servers as "even if the sending server does not match the SPF record it is still ok to accept mail from the server". If someone has set up the outbound mail server as I have shown above, the hardfail qualifier "-all" should not be an issue as the SPF record should always match the sending mail server. The biggest reason I recommend the hard fail in the SPF record is that mail that is sent from email servers that you do not control, who are spoofing your domain as the sender may be accepted with a softfail, with a hardfail those emails should always be rejected by the receiving mail server.


    @imok said:
    That's a lot of steps.

    I was probably overly explicit, so it looks more intimidating than it is. If there is any demand I can turn this into a couple of install scripts so that it would be easier to install. :) You would still need to set a few things manually like the SPF record, but the script would do most of the heavy lifting.


    @AlwaysSkint said:

    @FrankZ said: If you're sending a limited amount of mail..

    ;)

    Corrected. If you only found one error in my long post I am going to consider that a success. :wink:

  • I'll give this a run through (with CWP installing the core software), when/if the $6 Dallas VPS gets activated. :+1:

    Thanked by (2)FrankZ edrebe

    It wisnae me! A big boy done it and ran away.
    NVMe2G for life! until death (the end is nigh)

  • This is probably obvious to more experienced folks but what is the advantage of setting up an outgoing mail relay on a VPS to send mail mail to an MXRoute account? Wouldn't it be easier to direct your outgoing mail straight to MXRoute instead of having it go through an extra relay point?

    Isn't the MXRoute service an outgoing mail relay itself (as well as other things)?

    DISCLAIMER: I iz notz zo zmarty

    Push up videos! (non aff link)

  • FrankZFrankZ Moderator
    edited January 20

    @JDMcPea said:
    This is probably obvious to more experienced folks but what is the advantage of setting up an outgoing mail relay on a VPS to send mail mail to an MXRoute account? Wouldn't it be easier to direct your outgoing mail straight to MXRoute instead of having it go through an extra relay point?

    Isn't the MXRoute service an outgoing mail relay itself (as well as other things)?

    DISCLAIMER: I iz notz zo zmarty

    Hello. The relay is to send mail out through MXRoute to other mail servers like gmail and such. Not to send email to MXRoute, as you are correct that would not serve any real purpose. The reason I like to relay my outbound mail through MXRoute is that @Jarland is very good at deliver-ability so I don't have to worry about if the mail gets to the recipient.

    The idea behind a relay of this type is so that if you have various different web servers that send outbound mail, as an example a forum, you could setup that VPS to relay its mail via the relay server, then through MXRoute, and finally to the destination mail server of the recipient. You could of course just do part one of this tutorial on each server that you wanted to send outbound mail from, if you only had a few servers. I normally have at least 40 servers sending some outbound mail so I find it more convenient to set up a couple of relay servers and have all the other servers send mail through the relays.

    Another reason, or use, for the relay is if your VPS host blocks email ports (25, 465, 587) by using the relay which is on port 2525 these servers can still send outbound email via the relay.

    Thanked by (3)jarland JDMcPea Mason
  • jarlandjarland Hosting ProviderOG
    edited January 20

    It’s worth noting that a slight variation on this kind of setup consumes a significant amount of my time trying to protect the infrastructure from being overwhelmed by pure junk that drags down IP reputation by increasing the association between our IPs and spam folders. These are the big line items:

    1. Almost no one who does this cares that their hostname isn’t an actual valid domain, forcing me to locate all of their server hostnames and add them to a banned sender list so they get errors instead of flooding the queue with junk I can’t deliver or bounce.
    2. That cron job you have set to run every minute sends a notification, and the person who sets this up commonly has all of these emails sent to their Gmail address.
    3. A simple command line interface or a cron job notification lacks the required headers that a legitimate email client would add without the user noticing.

    Number 1 causes our mail queues to be packed full of “[email protected]{1..999}” emails that I can’t and won’t deliver because they’re not from valid envelope senders. But I can’t say that these are inherently bad and prevent them from going out before I identify each one of them because temporary DNS issues could cause a sending address to appear invalid that isn’t later. So I queue them, but then I audit the queues every day for this junk and use it to build my banned sender list (ex. *@localhost, *@vps1, *@vps.local, etc.).

    Number 2 loops in with #1, and the two items work hand in hand to try to overly associate our IP addresses with Gmail’s spam folder, and number 3 comes in here as part of that. A bad sending address, a cron job notification that the user never meant for human consumption (and will never read, save for the 1 in a million user who might), and a lack of valid headers combined with Gmail’s threading feature mean you see one little junk email in your Spam folder, but you actually sent 1,440 junk emails per cron job to Gmail that were all destined to the spam folder. Combine that with the 600 other users doing the same thing, and you then have 864,000 emails from our platform daily, which are guaranteed to land in Gmail’s spam folder. Almost none of those users even meant to send those emails. The users rarely have any idea that they sent them, and they have no plan of gaining anything from it. It’s hard to let all of that through and then tell people I’m focused on doing everything I can to ensure inbox delivery.

    All this to say, it’s good to be able to configure your systems to do this, but please keep one thing in mind: The MXroute platform is designed to send emails that are intended for either human consumption or automatic processing. It is not intended to be used as a garbage delivery system for Gmail. It also can’t be used as a garbage delivery system for Gmail, expecting that intentionally sent emails have a high probability of landing in the inbox. It can be one or the other. It can’t be both. Doing everything I can to get intentional emails into the inbox has always been my top focus. So please, if you do this, take a moment to consider what your server is doing and how it may use this configuration in ways you weren’t thinking of at the time.

    Do make sure that your sending addresses are always valid. If your hostname isn’t valid, has no MX or SPF records itself, then your cron jobs and other system emails are going to be sending as invalid envelope senders. Think “[email protected]” that’s not valid, even “[email protected]” is invalid if myvps.mydomain.tld lacks valid MX/SPF. Most of that is fine if you’re sending to yourself to be delivered to an inbox on the same MXroute server that your service is hosted on, but if you’re sending these out to remote recipients that’s when you really need to dot your I’s and cross your T’s, making sure you have everything done properly.

    Hate radiates from the source. If you look around and see it everywhere, it's coming from you.

  • @FrankZ said:

    @JDMcPea said:
    This is probably obvious to more experienced folks but what is the advantage of setting up an outgoing mail relay on a VPS to send mail mail to an MXRoute account? Wouldn't it be easier to direct your outgoing mail straight to MXRoute instead of having it go through an extra relay point?

    Isn't the MXRoute service an outgoing mail relay itself (as well as other things)?

    DISCLAIMER: I iz notz zo zmarty

    Hello. The relay is to send mail out through MXRoute to other mail servers like gmail and such. Not to send email to MXRoute, as you are correct that would not serve any real purpose. The reason I like to relay my outbound mail through MXRoute is that @Jarland is very good at deliver-ability so I don't have to worry about if the mail gets to the recipient.

    The idea behind a relay of this type is so that if you have various different web servers that send outbound mail, as an example a forum, you could setup that VPS to relay its mail via the relay server, then through MXRoute, and finally to the destination mail server of the recipient. You could of course just do part one of this tutorial on each server that you wanted to send outbound mail from, if you only had a few servers. I normally have at least 40 servers sending some outbound mail so I find it more convenient to set up a couple of relay servers and have all the other servers send mail through the relays.

    Another reason, or use, for the relay is if your VPS host blocks email ports (25, 465, 587) by using the relay which is on port 2525 these servers can still send outbound email via the relay.

    @FrankZ Thanks for your answer- I now understand that one advantage would be if my VPS provider blocks the email ports then setting up a relay on another VPS would be a good solution.

    I think I phrased my question poorly- what I meant to write was is why not have outgoing email relayed directly through (not to) an MXRoute account? Assuming my host does not block email ports. For example- lets say I have a VPS with a WordPress website and the Contact form is set up to send outgoing messages through MXroute, which then delivers them reliably to Gmail, Outlook, etc.

    Or I could have it set up to send the WordPress email first to a relay server that I have set up on another VPS, which will then send the email to MXroute, which will then send to Gmail, etc.

    One possible advantage I can think of (please let me know if this is not accurate) is that when I get an account with MXRoute they limit the servers/IP addresses that I can use to send outgoing mail through their service? In that case a setting up my own relay on a VPS would allow an unlimited number of IPs/servers from which I can send email through MXRoute?

    Push up videos! (non aff link)

  • FrankZFrankZ Moderator

    @JDMcPea Your assessment is correct. The relay server in Part 1 can be setup on any VPS. In your example of the VPS with the WordPress site you could set up the mail server as described in Part 1 on the same VPS as the WordPress site and do not do Part 2.
    You would need to set WordPress to use Mail SMTP instead of the default wp_mail (PHP mail) by going to the menu item "WP Mail SMTP", choosing "Other SMTP" and entering localhost as the SMTP server. In this case I would also suggest setting up OpenDKIM, on the same VPS which will be a tutorial I will be putting up shortly as a companion to this one or if you do a google search I am sure you can find a tutorial regarding OpenDKIM that you can use. It this scenario your email would go directly to MXRoute from your WP VPS with no second VPS but your email is still being relayed via MXRoute.

    Thanked by (1)JDMcPea
  • I guess you would also add a step for autoupdating the .pem, tied into letsencrypt setup ... (Unless I missed that when reading through) :)

    Thanked by (1)FrankZ
  • FrankZFrankZ Moderator

    @flips said:
    I guess you would also add a step for autoupdating the .pem, tied into letsencrypt setup ... (Unless I missed that when reading through) :)

    Thank you for pointing that out, you are correct, that step is not included and should be. I will make a note in the above that the cert step should be redone as the cert expires.

    Thanked by (1)flips
  • For Lighty I found Dehydrated easy to use to add a hook/script to generate the pem and reload the web server ... :)

    Thanked by (1)FrankZ
Sign In or Register to comment.