Bug 217270 - Bad defaults in ssmtp.conf
Bad defaults in ssmtp.conf
Product: Fedora
Classification: Fedora
Component: ssmtp (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: manuel wolfshant
Fedora Extras Quality Assurance
: Patch
Depends On:
  Show dependency treegraph
Reported: 2006-11-26 04:56 EST by Ville Skyttä
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: ssmtp-2.61-10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-29 12:55:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Better config defaults (708 bytes, patch)
2006-11-26 04:56 EST, Ville Skyttä
no flags Details | Diff

  None (edit)
Description Ville Skyttä 2006-11-26 04:56:50 EST
The default ssmtp.conf has uncommented "rewriteDomain=" and
"hostname=_HOSTNAME_" options, which makes the default config pretty certainly
not work anywhere without modifications.  Commenting both of them out and
removing the confusing _HOSTNAME_ would be better and more likely to work out of
the box on quite a few systems - (untested) patch attached.

Also, there is movement towards IPv6-enabling everything in Fedora (see eg
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=IPv6Blocker), so perhaps
enable it here too (configure --enable-inet6)?  Just a remark, I don't use and
can't test that at the moment.
Comment 1 Ville Skyttä 2006-11-26 04:56:51 EST
Created attachment 142128 [details]
Better config defaults
Comment 2 Ville Skyttä 2006-11-26 05:00:06 EST
Oops, ipv6 seems to be enabled already, sorry about the noise.
Comment 3 manuel wolfshant 2006-11-26 17:32:02 EST
How about leaving the provided ssmtp.conf alone as in the source, but edit it in
I have just tested the following scriplet and it seems to behave in a reasonable
if [ $1 -eq 1 ] ; then
        DOMAIN=$(hostname -d)
        HOSTNAME=$(hostname --fqdn)
        sed -ie "s/_HOSTNAME_/$HOSTNAME/;s/=$/=$DOMAIN/" /etc/ssmtp/ssmtp.conf

Side effect is that it needs net-tools at install time.
What do you think ?
Comment 4 Ville Skyttä 2006-11-27 11:34:17 EST
Editing at %post time has the annoyance that the config file will be immediately
modified from the packaged one, thus causing *.rpm(new|save) backups left behind
on packages upgrades/erases.  It is also possible that the suggested approach
would lead to breakage if the hostname or domain of the box changes if someone
doesn't remember to manually take care of ssmtp's config too.  Therefore I think
the approach from comment 1 is a better one.
Comment 5 manuel wolfshant 2006-11-27 12:21:41 EST
Maybe I make an error, and if so please do correct me, but the file is marked
%config(noreplace) and the scriplet I suggest will only be active at install
(not upgrade), so a backup will only be left in case of erase (which I see as a
feature, not a bug). Nothing is touched at upgrade time.

I'll be back in a day or two, I want to perform more tests.
Comment 6 Ville Skyttä 2006-11-27 13:17:07 EST
It doesn't matter when your scriptlet is active, it causes modification of a
file marked as config after the package has been installed.  rpm checks for
these things internally on package upgrades - if a new upstream release of ssmtp
comes out with some upstream changes to the config file compared to the previous
(unmodified) one, package upgrades will result in useless *.rpmnew.

And if on erase a package leaves a *.rpmsave behind for a config file that 1) I
have not modified personally, and 2) the package has done it itself probably for
no reason, it most certainly qualifies as a (small, but annoying) bug to me, not
a feature.

I fail to see any reason why doing the suggested modifications in %post would be
better than shipping commented out entries - it's more complex, the result is
arguably functionally worse, and the setup requires potentially more manual
maintenance when the hostname/domain of the box changes.  ssmtp can figure the
hostname out internally (and if it can't, I'm having problems believing
"hostname --fqdn" could do any better) and setting the domain to "hostname -d"
by default could be seen as unexpected and harmful.
Comment 7 manuel wolfshant 2006-11-27 22:57:15 EST
Ville, thank you for clarifications.

Proposed patch included, rpm sucessfully built in devel.
If no objections within 24h, I will request building for the other branches and
close the bug (as CURRENTRELEASE ? ).
Comment 8 manuel wolfshant 2006-11-29 12:55:54 EST
Sucessfully built on all branches.

Note You need to log in before you can comment on or make changes to this bug.