According to policy
/usr/share/doc/debian-policy/policy.txt.gz
"Non-conformance with
guidelines denoted by _should_ (or _recommended_) will generally be
considered a bug, but will not necessarily render a package unsuitable
for distribution."
and further down:
"If your package needs to know what hostname to use on (for example)
outgoing news and mail messages which are generated locally, you
should use the file `/etc/mailname'. It will contain the portion
after the username and `@' (at) sign for email addresses of users on
the machine (followed by a newline)."
Note that policy uses the word "should" for mailname, so wishlist doesn't
appear to be a suitable severity for this issue.
This bug is for the sender address, the merged bug #509810 is for the recipient
address, so it is actually a different issue and it remains a wishlist item,
I've unmerged them.
I've observed that on a freshly installed stretch system, the mailutils
implementation of the mail command is now the default:
/etc/alternatives/mail -> /usr/bin/mail.mailutils
while on older systems, it was bsd-mailx:
/etc/alternatives/mail -> /usr/bin/bsd-mailx
and so it impacts every new install. Therefore I've chosen the severity
"serious" for this issue.
People can work around this issue with:
$ sudo apt install bsd-mailx
As a consequence of this issue, when people send outgoing mail from a stretch
system using the /usr/bin/mail command, the sender domain may not be what they
expect and their mail may not even be accepted by their relay host. If all
their older Debian systems are running bsd-mailx this is an issue that will
take them by surprise on newly built systems.
Even if upstream doesn't want to support /etc/mailname because they consider it
a Debian thing, as mentioned in the earlier message in this bug, the Debian
version should probably contain a patch or it should not be the default
/usr/bin/mail.
