/bin/mail as an MTA
Introduction
If one looks at the manpage for the humble mail program (man 1 mail), it has a ton of options. I've used it over the years in hacky scripts and to read root's mail on some poorly configured server, but I never realized that mail can operate as an MTA (Mail Transfer Agent).
Mechanism
I was recently working on a configuration for redundant Postfix mail servers and Dovecot IMAP servers and needed a means to test. Looking at the manpage for mail, they give an example command, which I've modified and included here:
echo "Test email" | \ env LC_ALL=C MAILRC=/dev/null password=${PASSWORD} user=${USER} \ mail -n \ -Sv15-compat \ -Ssendwait \ -Snosave \ -Sssl-verify=warn \ -Ssmtp-auth=plain \ -Ssmtp-use-starttls \ -S "smtp=submission://${MAIL_SERVER}" \ -S "from=${SENDER_EMAIL}" \ -s "Testing" \ -. \ $RECIPIENT_EMAIL
I'm sending "Test email" as the body of the message to $RECIPIENT_EMAIL from $SENDER_EMAIL with "Subject: Testing". I thought I'd explain the options in this post.
LC_ALL=C– no UTF-8 needed for testing.MAILRC=/dev/null– don't read any local .mailrc to completely control the options used.user…= andpassword…= – you can set the auth credentials in thesmtp=URL below, but they need to be URL-encoded, so I took the lazy path and stuck them in the environment for everyone to see.-n– don't read/etc/mail.rc, again to completely control the options used.-Sv15-compat– use the newer options tomail.-Ssendwait– the manpage indicates error reporting will be more reliable with this option set. I turned-off encryption and sniffed the wire to determine if there were any obvious differences, but I didn't see any. Needs more investigation…-Snosave– nodead.letterfiles scattered everywhere!-Sssl-verify=warn– I'm using a self-signed X509 certificate, so I need this option to negate cert verification. With Let's Encrypt, the days of bad certificate discipline may finally be over.-Ssmtp-auth=plain– I'm using theplainauthentication method.-Ssmtp-use-starttls– for thesubmission:schema, you need this option or you won't be getting an encrypted session. This is not needed for thesmtps:schema since that one implies encryption.-S smtp=submission://${MAIL_SERVER}– the URL for the destination MTA. The manpage has the various schemas accepted, and you can specify the port if your not using the schema's default.-S from=${SEND_EMAIL}– sets the envelope "from" field.-.– indicates the end of options. I wonder why they didn't use the standard--?
Just thought this was neat.