Categories
linux PHP

How to Test Sendmail From Command Line on Linux

What Is Sendmail?

sendmail is a very plain and simple MTA (Mail Transfer Agent), which implements the SMTP (Simple Mail Transfer Protocol) amongst others and can be used to transmit emails, typically on Linux. While there is a commercial version available which is called “Sendmail”, the sendmail we’re covering in this how-to article is the UNIX-based version of it, which comes with pretty much every Linux distribution as well as *BSD (FreeBSD, OpenBSD, and variants). Using the sendmail command might be the easiest way to send e-mails via Linux shell CLI (Command Line Interface), apart from mailx, which can be used in conjunction with sendmail to make it even easier to send and receive emails from the command line. Like the name already suggests, sendmail itself can only send emails and not store received ones in POP or IMAP mailboxes.

Where Is Sendmail And Its Configuration Files Located?

The first interesting information that we might need for testing sendmail is the path of the binary file that gets executed if we issue the command sendmail on our command line. To figure that out, we’ll use the which command as shown below:

[root@box ~]# which sendmail
/usr/sbin/sendmail

The above output means that the full path to our sendmail command’s binary file is /usr/sbin/sendmail which you should note for the steps further below.

If you want to adjust the configuration files of sendmail, you can usually find them in the directory /etc/mail/on UNIX (FreeBSD, OpenBSD) and Linux (CentOS, Fedora, Debian, Ubuntu) systems. The main configuration file of sendmail is /etc/mail/sendmail.cf, however adjusting that is not part of this tutorial. A good place for more information is the manual page of sendmail, that you can view by running the command man sendmail. Now to the interesting part of this sendmail command line tutorial.

How to Test the Sendmail Command On Linux

To quickly test if the sendmail command is working correctly to then use it for example in shell scripts, via command line or even from PHP scripts (PHP supports sendmail to send emails from PHP scripts – you can set the sendmail path in your php.ini), you can issue the below command on your UNIX or Linux system:

echo "Subject: sendmail test" | sendmail -v my@email.com

my@email.com is obviously the e-mail address you want the test email to be sent to. This sendmail command line example will send a blank email with the subject “sendmail test” to my@email.com if the test is successful. You can also send longer e-mails containing a subject, body and additional headers if you want to, but just to test if sendmail works that’s usually not required. Still, here is how you can do that:

1.) Create a file called mail.txt (or anything you like) in ~/mail.txt with vim or nano or your preferred text editor

2.) Paste the following content to it, but of course adjusting the email addresses, as those are just sendmail command examples:

To: my@email.com
Subject: sendmail test two
From: me@myserver.com
And here goes the e-mail body, test test test..

3.) At last we send the e-mail template we just created with: sendmail -vt < ~/mail.txt

That’s it – you can now test sendmail from the command line and even send full e-mails including headers from Linux/UNIX shell. Below is an example of how the simple sendmail test could look like on a live system:

sendmail test

Sendmail And Spam

One thing I’d like to add is that due to the fact that PHP and other scripts can usually access the sendmail binaries, it can also be used to send out spam and phishing mails and that’s what can happen on shared servers where accounts were compromised through an outdated CMS or weak passwords. If you want to find out which script or POSIX user is sending the spam with sendmail, you can issue the below command and pay close attention to the output:

ps faux | grep sendmail

Sendmail Conclusion

While sendmail can pose a few risks on shared or insecure systems, it is a great lightweight MTA that can be used to send e-mails from shell scripts, PHP applications or even directly the command line. It also automatically negotiates STARTTLS for encrypted transmission of the emails if the remote SMTP server supports it, which is a useful security practice.

'Coz sharing is caring
Categories
HTTP Concepts Technology

SPF, DKIM, AND DMARC

Emails consist of various part and each part focuses on certain protocol.

SPF

SPF focuses on the “domain” found in an email header that has many names, Return-Path, MAIL-FROM, Bounce address, Envelope from. In this article, we will refer to it as the Return-Path. If this header is missing, SPF falls back and looks at the “HELO/EHLO” hostname and checks for an SPF record there.

Don’t forget — the Return-Path header is a technical header that is not visible to the end user.  Unless they know how to display the headers of an email in their mail client they won’t see it. 

DKIM

DKIM focuses on the “DKIM-Signature” header.

Don’t forget — this header again is not visible to the end user unless they know how to display the headers of the email they have received.

DMARC

DMARC focuses on the domain found in the “From or Header from” header which is visible to the end user. In this article, we will refer to it as “From”.

Now that we know what headers each protocol looks at, what is actually contained in those headers and what is checked?

SPF —This verifies if an email was sent by an authorized sender by checking a list of authorized IP addresses you publish in your DNS. The receiving server will take the domain found in the Return-Path header and check for an existing SPF record. It checks the SPF record to see if the sending IP address of the email is actually contained in the SPF record. If the IP address is contained in the SPF record that means that it is authorized to send emails. This means that SPF PASSED. If the IP address is not in the SPF record then SPF FAILS.

The overall logic is:

If the sending IP address is contained in the SPF record = SPF PASS

If the sending IP address is not contained in the SPF record = SPF FAIL

DKIM — The receiving server will check the DKIM-Signature header which contains the selector (s=) and signing domain (d=) which are tags used to look up the public key. Once retrieved, the public key is used to validate the email message. If validation is successful then DKIM PASSES and if the validation process is unsuccessful then DKIM FAILS.

The overall logic is:

If validation is successful = DKIM PASS

If validation is unsuccessful = DKIM FAIL

DMARC — The receiving server will check if either SPF or DKIM PASSED, then it will check if the Return-Path domain used by SPF and/or the “d=” domain used by DKIM align with “From” domain, and finally it will extract the DMARC policy published by the domain found in the “From” address and comply with the policy.

The overall logic is:

If SPF PASSED and ALIGNED with the “From” domain = DMARC PASS, or

If DKIM PASSED and ALIGNED with the “From” domain = DMARC PASS

If both SPF and DKIM FAILED = DMARC FAIL

DMARC not only requires that SPF or DKIM PASS, but it also requires the domains used by either one of those two protocols to ALIGN with the domain found in the “From” address. Only then will DMARC PASS.

What’s the difference between Strict vs Relaxed alignment?

Strict alignment means that the Return-Path domain or the signing domain “d=” must be an exact match with the domain in the “From” address.

Relaxed alignment means that the Return-Path domain or the signing domain “d=” can be a subdomain of the “From” address and vice versa.

What happens if DMARC fails?

If DMARC fails then the receiving server would typically comply with the policy that you have specified in your DMARC record.

If you are in report-only mode (p=none) the email will be accepted by the receiving server and scanned by other filtering criteria.

If you are in quarantine mode (p=quarantine) the email will be quarantined and typically sent to the spam folder of the recipient.

If you are in reject mode (p=reject) the receiving server will abort the connection with the sending mail server and the email will never reach the end user.

Irrespective of the policy, the metadata for the email will be logged along with the status of the authentication results and forwarded to your DMARC report processor.

SPF troubleshooting and top tips

  1. Make sure that you have an SPF record in your Return-Path domain.
  2. Make sure that you have an SPF record in your HELO/EHLO domain in case of bounces where the Return-Path domain is empty.
  3. Make sure there is a single SPF record per domain.
  4. Make sure that the SPF record syntax is correct.
  5. Make sure that your Return-Path domain aligns with the From domain.
  6. Make sure that your authorized senders are part of the SPF record.
  7. Make sure that unauthorized senders are not in your SPF record.
  8. Make sure that you do not go over the 10 DNS lookup limit imposed by SPF.
  9. Make sure that deprecated SPF record mechanisms such as the “ptr” mechanism are not used in your SPF record.

DKIM troubleshooting and top tips

  1. Make sure that the sending systems you use support DKIM.
  2. Make sure that the emails are DKIM signed.
  3. Make sure that the signing domain aligns with the “From” domain.
  4. Make sure that you use a DKIM key size over 1024 bits (a 2048 bit key is advisable)
  5. Make sure, where possible, that the DKIM selectors you choose closely identify the sending service so you can distinguish between them.
  6. Make sure to revoke any keys that have been compromised.
  7. Make sure that the DKIM keys you manage are rotated on regular basis.
  8. Make sure that the DKIM key syntax is correct.
  9. Make sure that there exists a public key for each corresponding private key that signs your emails.

DMARC troubleshooting and top tips

  1. As DMARC is based on both SPF and DKIM and the domains used by those two protocols, you will have to make sure that the Return-Path domain for SPF is either an exact match or a subdomain of the “From” domain. The same applies to the signing domain used by DKIM.
  2. Make sure that the DMARC record syntax is correct.
  3. Make sure that you have configured all of your systems correctly with SPF and DKIM before moving to a reject policy as your emails will be lost.
  4. Make sure that you use a system or third-party provider to receive DMARC reports so that you can make sense of those reports and discover any systems that are misconfigured.
  5. Monitor the status of each of your sending sources and make sure that any changes to SPF and DKIM are identified.
'Coz sharing is caring