Need help? Chat now!
Search results for:
Table of Contents
To better understand what smtp-cli is, let's talk about what it is not; smtp-cli is NOT an email server or relay agent; it is also NOT a way to send high volumes of mail. It is an email client that allows sending text, HTML, files, and pictures from the command line and scripts.
Instead of creating another email server, you can use smtp-cli to send updates from your VPS(s) via a remote email account to monitor the health or status. You could also set up a cron job to forward logs as part of server security hardening. This allows your server to run more or less unattended unless errors are found or limits are approached.
We will be using git to grab the smtp-cli script from GitHub. If you do not already have it installed, you can install it like this:
# yum install -y git
# apt-get install -y git
# git clone https://github.com/mludvig/smtp-cli.git
The smtp-cli script (the part the runs) is located inside a directory called smtp-cli, and inside is a file called smtp-cli (the -l flag in the command lets us look at the file attributes to make sure it is executable).
# ls -l smtp-cli
If those "x" are instead "-, "then run this command to make the file executable.
# chmod +x smtp-cli/smtp-cli
Now we can test to see if it runs.
Which should result in an error like this
Weird to have an error be good, but since we are just testing to make sure the script is downloaded and executable, that is all we need right now.
Now we are going to check our global PATH (where the VPS checks when I run things from the command line without a full path)
# echo $PATH
And copy the smtp-cli to the user sbin directory within your default PATH.
# cp smtp-cli/smpt-cli /usr/local/sbin ls -l /usr/local/sbin/smtp*
Now we can run smtp-cli from any directory on the VPS without worrying about including the full path to the file.
Because placing your unencrypted password in a script is pretty much the most insecure, not to mention difficult, way to manage a password, we will create a file that contains our password information. This allows us to update our password easily and makes a malicious actor at least have to look for the information.
Since I am running as the root user and creating a root cronjob, this file will be in the /root/ directory. Your cron job may be in your user crontab depending on the privileges you are granted by your system administrator, in which case you may be storing this in the /home/username.
# touch /root/.passwd
echo 'SomeRandomPassword' > /root/.passwd
Note that the "SomeRandomPassword" will need to be the plaintext of your actual email password for your remote email account.
Now we get to the good part, sending an email as part of a script or from the command line. I am going to test it by sending the file we created as part of our vnstat guide.
As a note, the $(some command) portion below allows a command to be run inline and use the output of that command as the input for the argument.
# smtp-cli --verbose --server mail.emaildomain.TLD:587 --enable-auth --user smtp-cli_guide@emaildomain.TLD --pass $(cat /root/.passwd) --from smtp-cli_guide@emaildomain.TLD --to test2@emaildomain.TLD --subject VPS-stats --attach /var/www/html/vps_bandwidth_stats.png
Now that we know it works, we can put the command in a bash script or cron job.
#!/etc/bash smtp-cli --verbose --server mailservername.emaildomain.TLD:587 --enable-auth --user login-user@emaildomain.TLD --pass $(cat /root/.passwd) --from email_orinator@emaildomain.TLD --to email_destination@emaildomain.TLD --subject subject-line --attach /full/path/filename.tosend >> /path/to/logfile.log
--help --body-plain=<text|filename> --body-html=<text|filename>
While this example provided for the ability to set up scripts or cronjobs, this simple mailer can also send mail using global variables or output for other monitoring scripts; All of these tools can send simple alerts or complex diagnostic data to your email based on a regular interval or a triggering event.
Several different issues can arise when using the script. The first issue would be how your mail server authenticates. Do you enter a full email address or just a username? That is what you would need after the –user argument. The example assumes you enter the full email address as the –user. Use what credentials you normally use for your server.
The second problem area is the –from field. Ensure this is the email account that you are logging into. You cannot send mail from an account you do not control.
The third is the server name and port selection of the –server field. This name should be a Fully Qualified Domain Name of your outgoing email server followed by a :portnumber. The standard ports for smtp are 25, 587, 465.
Finally, the –to field needs to be a valid email address, or it will never reach a destination.
Written by Paul Schene / July 10, 2020