I've been using SSTMP on a local FreeBSD machine to send stuff like the output of certain cron jobs to my "real" main email account, which is not hosted on the same machine (or even domain). For example, I have a daily cron job set up as so:

smartctl -a /dev/ada0 | grep overall-health | mail -s "Silicon daily smartctl" [email protected]

This works fine, insofar as the mail being successfully delivered to my "real" email account. However, every time I send a message, I also receive a bunch of warning and bounce messages from my "real" email account's mail system.

I found that mail has a "verbose" flag, -v, which shows the conversation between my SSMTP and the host of my "real" email account. I tried it out, and noticed the following interesting portion:

[->] RCPT TO:<[email protected]>
[<-] 250 Accepted
[->] RCPT TO:</usr/local/sbin/[email protected]>
[<-] 250 Accepted
[->] RCPT TO:<[email protected]>
[<-] 250 Accepted
[->] RCPT TO:</usr/local/sbin/[email protected]>
[<-] 250 Accepted
[->] RCPT TO:<[email protected]>
[<-] 250 Accepted

So SSMTP is saying that the message should be sent not only to the intended recipient, but also to three other addresses? And one of them is especially weird looking ("/usr/local/sbin/[email protected]"), and for some reason that one gets two RCPT TO lines.

I have no idea where these "extra" RCPT TO lines are coming from. Anyone have any idea? Thanks.

Contents of my /usr/local/etc/ssmtp/ssmtp.conf:

[email protected]
[email protected]

1 Answer 1


I've figured it out and fixed it.

I took a look at the ssmtp source code to try to figure out the situations in which it will add a RCPT TO line for something. This then led me to try to figure out what command line args ssmtp was being called with. I found that mail was calling ssmtp with some rather bizarre-looking command line args, that moreover seemed to correspond to the "extra" RCPT TO lines:

# ps -jdp 63097 -ww 999
root 63097 62987 63097 60346    1 I     1  0:00.09 -su (bash)
root 36939 63097 36939 60346    1 S+    1  0:00.00 - mail -vs aojg [email protected]
root 38014 36939 36939 60346    1 S+    1  0:00.01 `-- sendmail send-mail /usr/local/sbin/ssmtp mailq /usr/local/sbin/ssmtp -i -v [email protected] (ssmtp)

I had for a while been suspicious of the file /etc/mail/mailer.conf, due to it having a lot of overlap with the "extra" RCPT TO lines. It looked like this:

sendmail        /usr/local/sbin/ssmtp
send-mail       /usr/local/sbin/ssmtp
mailq           /usr/local/sbin/ssmtp
newaliases      /usr/local/sbin/ssmtp
hoststat        /usr/bin/true
purgestat       /usr/bin/true

... but when I say "looked like", I mean that surprisingly literally. That's what it looked like to me when I did something like cat or nvim. But the fact that mail was passing the first three lines, except for the opening "sendmail" of the first line, made me look more closely.

Turns out that although it looked like six separate lines, it was actually four lines. The first three pseudo-lines were not separated by EOLs. They were instead separated by a whole bunch of spaces (and were therefore actually one single line). I don't know whether nvim and such display things like that as if they were individual lines, or else it was a just a coincidence (the number of spaces being exactly equal to the number that would cause the "perfect" wrapping).

So, mail wanted to invoke sendmail. It looked up the sendmail line in mailer.conf. It then considered everything on that line, except for the opening "sendmail" itself, to be what it should call to invoke sendmail. That should have been /usr/local/sbin/ssmtp, but due to the wacky spaces, it was instead /usr/local/sbin/ssmtp send-mail /usr/local/sbin/ssmtp mailq /usr/local/sbin/ssmtp.

That is, mail invoked the executable /usr/local/sbin/ssmtp with the command line args send-mail /usr/local/sbin/ssmtp mailq /usr/local/sbin/ssmtp (plus other args that it added on for legitimate reasons).

Finally, sendmail decided that each of those four startup args were email addresses to send to, tacking "@vesterman.com" onto each of them for whatever reason.

As for why the mailer.conf file was in this state in the first place, I believe it must have happened in some sort of tragic copy-paste mishap.

  • 1
    Good catch. Thanks for providing a self-answer
    – roaima
    Feb 2 at 9:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .