Re: Mailutils+nullmailer: sender full name
On Wed, Oct 18, 2023 at 06:04:30PM +0100, Tixy wrote:
> On Wed, 2023-10-18 at 11:28 -0500, David Wright wrote:
> > (Aside: does anyone know what "heirloom-mailx" is?)
>
> I remember it being the mailx compatible program that got installed by
> default many releases ago, and it was replaced by s-nail in
> 2016. (Possibly as a fork of that orphaned project?)
>
> I still use s-nail on all my machines.
Before I go any further, please note that "mailx" is the POSIX approved
program name for sending scripted emails. "mail" is a legacy synonym,
not standardized, because way too many systems have differing programs
named "mail" with differing behaviors. There's also capital-M "Mail"
which thankfully has fallen out of favor.
Now, <https://wiki.debian.org/NewInStretch> says:
Users of the heirloom-mailx package should beware: in stretch,
heirloom-mailx has become a transitional package bringing in
s-nail. However, the s-nail package does not provide mailx. If you
have scripts which call mailx -a attachfile ... you will need to
rewrite those scripts, or manually change the /etc/alternatives/mailx
symlink. (update-alternatives will not work.) See also bugs 858080
and 846062.
* In addition, s-nail does not provide a /usr/bin/mail program. If
you run mail in a script, be sure to install either bsd-mailx
or mailutils. Note: bsd-mailx and heirloom-mailx (s-nail) do not
conflict with each other any more.
What a mess, eh? (That addendum about /usr/bin/mail wasn't mine, I don't
think. Maybe? Dunno, it's been many years.)
Of particular note is the "-a" option. bsd-mailx's -a adds additional
headers. heirloom-mailx's -a attaches files. Any system that relied
on mailx -a somefile ... for sending email with attachments would have
broken after a stretch upgrade, unless explicit steps were taken to fix
the situation.
Before stretch, if you had heirloom-mailx installed, both "mail -a file"
and "mailx -a file" worked. After upgrading to stretch, you'd have an
s-nail program, but *not* a mail or mailx program, so all your scripts
would break. And if you did the obvious thing and installed bsd-mailx
as a replacement, "mailx -a file" would try to add a header named "file"
instead of attaching a file named "file".
So, after the stretch upgrade, you would either have to change all of
your scripts to use s-nail instead of mailx, or you'd have to change the
/etc/alternatives/mailx symlink manually, pointing it to s-nail
despite the package manager's refusal to consider s-nail a valid
alternative.
I don't know whether mailutils works better in this respect. I've never
used it.
Since I've got bsd-mailx installed on my home system, and
/etc/alternatives/mailx pointing to it, I can conclude that I didn't
suffer from this particular problem at home. Which makes sense -- I
don't send any automated emails from this computer.
Servers might be a dramatically different story.
Reply to: