** Changed in: smartmontools
Status: Unknown => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/181
Title:
10mail script should use sendmail command, not the mail command
To manage not
** Bug watch added: Debian Bug tracker #931420
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931420
** Also affects: smartmontools via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931420
Importance: Unknown
Status: Unknown
--
You received this bug notification because yo
** Changed in: smartmontools (Ubuntu)
Status: Incomplete => Triaged
** Changed in: smartmontools (Ubuntu)
Importance: Undecided => Low
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/181
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 pa
> 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 \
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.
--
You received this bug notif
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 t
> @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: sma
"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
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 c
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 wor
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
> If you don't care, so be it.
Leaving the decision to actual package maintainer(s). I only maintain the
upstream project :-)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/181
Title:
10mail scr
> (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 sendmai
If this works:
$ echo -e 'Subject: Test sendmail\n\nFoo' | /usr/sbin/sendmail
some.one@some.where
but this does not:
$ echo Bar | mail -s 'Test mail' some.one@some.where
you should possibly address the issue to the maintainer of the mailutils
package. I typically use the 'bsd-mailx' package as
Okay, thanks for the info, but it doesn't solve the problem.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/181
Title:
10mail script should use sendmail command, not the mail command
To manage n
>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.
POS
17 matches
Mail list logo