10mail script should use sendmail command, not the mail command

>The 10mail script is trying to send messages with /usr/bin/mail (aka mailx), which is a user agent, not intended for automated message sending.

'mail' and its various variants are user agents, but also intended for automated message sending. This is the case since the early (pre-Linux) days.

POSIX and its predecessor say:
"Send Mode can be used by applications or users to send messages from the text in standard input."
See:
http://pubs.opengroup.org/onlinepubs/007908799/xcu/mailx.html
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mailx.html

If no script (like smartd-runner) is specified with '-M exec' directive, smartd also uses 'mail' as a default (see smartd_warning.sh):

mail -s "$SMARTD_SUBJECT" $SMARTD_ADDRESS <<EOF
$SMARTD_FULLMESSAGE
EOF

Okay, thanks for the info, but it doesn't solve the problem.

If this works:

$ echo -e 'Subject: Test sendmail\n\nFoo' | /usr/sbin/sendmail <email address hidden>

but this does not:

$ echo Bar | mail -s 'Test mail' <email address hidden>

you should possibly address the issue to the maintainer of the mailutils package. I typically use the 'bsd-mailx' package as 'mail' provider and don't remember similar problems.

Alternatively you could disable (chmod -x) 10mail and add some /etc/smartmontools/run.d/11sendmail script, something like:

#!/bin/bash
/usr/sbin/sendmail $SMARTD_ADDRESS <<EOF
Subject: $SMARTD_SUBJECT
To: ${SMARTD_ADDRESS// /, }

$SMARTD_FULLMESSAGE
EOF

(Caution: not tested :-)

> (Caution: not tested :-)

Heh... Understood.

I know how to work around the problem on my own system, though. I wrote up this report because I thought the maintainers might like to know that 10mail doesn't work on systems that have no /usr/bin/mail at all, but have a perfectly functioning sendmail command. If you don't care, so be it.

Just for the record, it's also worth noting that mailutils, which is currently listed in this package's Recommends: field, overrides the dma (Dragonfly Mail Agent) MASQUERADE setting and causes outgoing messages to bounce. In other words, 10mail doesn't work without a /usr/bin/mail, and in certain configurations, doesn't work with one either.

> If you don't care, so be it.
Leaving the decision to actual package maintainer(s). I only maintain the upstream project :-)

Thanks Forest for the report and Christian for chiming in. I think the current behavior is the intended one: mail it sent using a mailx compatible MUA, which is often used for automated message sending. mailx implementations (bsd-mailx, mailutils, ...) differ and may require to be configured to work properly. For example mailx from mailutils can send mail using a remote SMTP server, authenticating if needed; this means that different setups are supported, but some configuration is necessary.

If you just want to pass mail to the local MTA I'd suggest to install bsd-mailx instead of mailutils.

As this looks like a local configuration problem, rather than a bug in Ubuntu, I'm marking this report as Incomplete. If you think this issue deserves more discussion, then we'd be grateful if you would explain why you believe this is a bug in Ubuntu rather than a configuration issue, and then change the bug status back to New. Thank you!

The problem this presents to me personally is that the current packaging causes (by default) GNU mailutils to be installed, and that implementation of mailx forcibly overrides and breaks the dma MTA's MASQUERADE mode, upon which my site depends. (I verified with mailutils' author that this is the case.) As a result, the smartmontools mail feature simply does not work on systems like mine, and cannot be made to work with a mere configuration change.

However, it could be made to work with a fairly minor change to the 10mail script, to invoke sendmail* if available on the system. Since you seem to be using mailx because of the flexibility it offers in delivery options, perhaps this change would make sense, as it would buy more flexibility with relatively little effort, and without losing anything.

As I said, though, I didn't write this bug report just to solve my own problem. I took the time to write it up because it seems like a general case that probably affects other people, and I thought you folks would want to be aware of it.

*When I say sendmail here, I don't mean the traditional implementation. I'm using dma, the Dragonfly Mail Agent, on my systems. It is very lightweight, works well, and has been proposed as the new default on debian-based distributions.
https://wiki.mageia.org/en/Dma_Dragonfly_Mail_Agent
https://wiki.debian.org/Debate/DefaultMTA/DMA

"invoke sendmail* if available on the system"

Might OTOH be too much of a departure from expected/usual behavior for other users of this.
I wonder if it really is that easy to alternate between mailx/sendmail if that could be done via a config file that defaults to mailx but could be changed to sendmail.

That would not affect the behavior by magic, but would allow to change the config for those who want that. I think that would be the best option for distributions but you'd not want to deviate with that behavior or you get a long term maintenance debt.

@Christian F. - would such a configurability of the used mailer be something that upstream would want add?

> @Christian F. - would such a configurability of the used mailer be something that upstream would want add?
I don't see much benefit in adding such complexity as various distributions already override our defaults with custom '-M exec' scripts (Debian/Ubuntu: smartd-runner, Fedora/RedHat: smartdnotify, ...)

I added two (now tested:-) wrappers for sendmail to upstream examplescripts directory:
https://www.smartmontools.org/changeset/4930

Thanks Christian,
for the hint about the custom -M and the example sendmail wrappers!

Those examples will further help people being in the danger zone a.k.a. "unusual configuration" to fixup their config to work without installing the mail command (if that is unwanted). These wrappers will allow them to use sendmail through the wrappers. Especially the second you added which is compatible to run with the parts.d based smartd-runner.

We usually ship the examples in /usr/share/doc/smartmontools/examples/ so on the next merge the new ones will be included and until then are available in the upstream repository.

I think with that the bug will most likely stay as-is from now on - for the majority it will just work (after all the package also recommends mailx) and for the rest we now have documented plenty of ways to use sendmail through configuration.

At quick glance, I don't see a quick and easy way to test email notifications. Is there one? Is it documented someplace? I'd hate to be the one who thought an email would be sent when a problem is detected, only to find out after it was too late that I was mistaken.

> At quick glance, I don't see a quick and easy way to test email notifications.

1. '-M test' in smartd.conf enables test messages. Here a quick example which does not touch smartd.conf and runs only one smartd check cycle in debug mode:

# sed -n '/^DEVICESCAN/s,$, -M test,p' /etc/smartd.conf \
  | /usr/sbin/smartd -c - -q onecheck

2. Or: run smartd's internal warning script directly. This does not require root and does not access any device. Set SMARTD_ADDRESS from '-m ...' and SMARTD_MAILER from '-M exec ...'. Example:

$ <email address hidden>' \
  SMARTD_MAILER=/usr/share/smartmontools/smartd-runner \
  /usr/share/smartd_warning.sh --dryrun

Remove --dryrun to actually exec .../smartd-runner.

@Christian E. - A possible enhancement for 10mail would be to fall back to sendmail if mail is not available. Something like:

#!/bin/bash
mail=/usr/bin/mail
sendmail=/usr/sbin/sendmail
if [ -x $mail ]; then
  echo "$SMARTD_FULLMESSAGE" | $mail -s "$SMARTD_SUBJECT" $SMARTD_ADDRESS
elif [ -x $sendmail ]; then
  $sendmail $SMARTD_ADDRESS <<EOF
Subject: $SMARTD_SUBJECT
To: ${SMARTD_ADDRESS// /, }

$SMARTD_FULLMESSAGE
EOF
else
  echo "Found neither $mail nor $sendmail"
  exit 1
fi

Thanks Christian. Falling back to sendmail if mail(1) isn't available seems an effective solution which at the same time won't change the behavior of existing setups.

The issue this report is about is present in Debian too. Ubuntu doesn't normally make any changes over the Debian smartmoontools package, so this bug would be best fixed directly in Debian, and then Ubuntu will pick up the fix automatically.

I'm going to report this bug against the Debian smartmontools package and link this report to the Debian bug.