Bug 1157727

I am sorry but I do not see this as a bug but as a feature. Most users are happy because in the default configuration they do not need to do anything to have a working configuration.

Oh, and if you are not happy with ssmtp you can always replace it with any other of the available smtp servers ( exim, msmtp, postfix, sendmail - in alphabetical order )

I am not saying that there is a bug of ssmtp itself, but that Fedora by default leaks all cron log emails to an external smtp server. It could be your ISO smtp server if they assign your host a domaing via DHCP and they have the mail alias

ssmtp was installed by default by an update, and is leaking these emails by default. that is the problem I refer to

ISP not ISO sorry

By the way, yum log says ssmtp was pulled as a needed dependency months ago

Apr 20 19:06:14 Installed: ssmtp-2.64-11.fc20.x86_64

So an update opened everyone machines to send email to a default server without notification. That is the problem, not ssmtp itself that is working as expected

This isn't a security issue.  If you look at the description for ssmtp it is doing exactly what it is supposed to do:

"""
A secure, effective and simple way of getting mail off a system to your mail
hub. It contains no suid-binaries or other dangerous things - no mail spool
to poke around in, and no daemons running in the background. Mail is simply
forwarded to the configured mailhost. Extremely easy configuration.
"""

So it is meant for it to do what you don't want it to do.  The problem is it provides /usr/sbin/sendmail which is what is required by a program (on my system it's smartmontools; that seems like an odd requirement to me to be honest).  As Manuel mentioned, you could install postfix/sendmail/exim and those would not do what ssmtp does because they serve a different purpose.  The purpose of ssmtp is quite clear.

What you may want to try is "rpm -e ssmtp" and see what complains; personally I think it's wrong for smartmontools to depend on a sendmail binary (that should be optional, not everyone will want to send email notices of device doom).

At any rate, I've removed the security-related bits here because this is not unexpected behaviour of ssmtp.  I've kept the bug private since it was filed that way, but I would encourage removing the group restrictions as this isn't a security issue that needs to be private.  Thanks.

I think people don't understand my position very well, I am not saying that there is a problem with ssmtp, and that it isn't doing what is what designed to do. What I am explaining is that I never wanted to send my cron jobs output to an external SMTP server, I didn't even wanted the output on any email like the default Fedora install was supposed to do, no SMTP service running by default. I don't want to install a new local SMTP server in order to avoid cron jobs output to be sent to probably third party servers.

The security problem is that a Fedora update pulled this package and installed it for me without I ever wanting it. I am not against a new package requiring a new dependency, but what I don't want is a new update that decides for me that data will be sent to an external server by default, without my knowledge. The contents of a cronjob output email can be simple and innocus to someone writing a script that show private data. this is why I marked this a a security bug.

I used ssmtp as the package to associate this bug because it was the package that was pulled, but it could go to other if needed. 

redhat-lsb and smartmontools are the dependencies that block the uninstall of this package. redhat-lsb is pulled by Google applications (Chrome and music manager), so I don't count them because they are external to Fedora, but smartmontools, should not be pulling ssmtp if it was it that brought ssmtp as an update.

I don't find right that every Fedora desktop installation without a real smtp server running get ssmtp installed by default, If ssmtp required configuration to use, It could be fine, or just don't pull ssmtp with smartmontools.

Feel free to file a bug with smartmontools and ask the maintainer to stop requiring a mailer to be present. From my point of view, ssmtp does exactly what it advertises to do and it's default configuration, as shipped, is a feature ( or convenience if you please ) not a bug.

OTOH I am pretty surprised that ssmtp is chosen as the default mailer. This comes as news to me.

There is no need to keep this private as the issue is well public on Fedora devel mailing list.

It is completely unacceptable to have ssmtp being pulled into some install just during its update if it behaves in such "automagical" way. This is really serious problem.

Given that ssmtp requires a mailhub to function properly, there are only two approaches available:
- provide a default configuration which does not work for anyone ( by not including a mailhub at all in its config or by using some random more-or-less guaranteed to not exist server name) which will then lead to the creation of dead.letter files for any user that uses ssmtp to send mail
- provide a default configuration which uses the most obvious name of a mail server - approach that was taken by Debian when the package was created and by me when I packaged it for Fedora.

If crond sends its output to unwanted servers, then the proper fix is either editing /etc/sysconfig/crond and thus asking crond to no longer send mail reports ( CRONDARGS=-s -m off ). This should maybe be even made a default.

And the all around fix is to make sure that ssmtp is not pulled in if it is not desired. I have no idea where does the sudden change in the behaviour of Fedora come from but the "Provides:" as shipped by ssmtp were not changed in a long, long time so I doubt ssmtp is the culprit here. I am of course willing to patch/change the package if I am proven wrong but I still believe that ssmtp behaves as expected and advertised.

sorry , I missed a phrase above. Please read the second paragraph as: 
If crond sends its output to unwanted servers, then the proper fix is either
- editing /etc/sysconfig/crond and thus asking crond to no longer send mail reports ( CRONDARGS=-s -m off ). This should maybe be even made a default.
- or replacing ssmtp with a smarter MTA and configure that MTA to deliver the messages locally

smartmontolls pulled it around:

Apr 20 19:06:14 Installed: ssmtp-2.64-11.fc20.x86_64
Apr 20 19:06:15 Updated: 1:smartmontools-6.2-5.fc20.x86_64

I have already opened the bug #1158493 against smartmontools when was requested, no fix there either.

I am using localhost and letting ssmtp fail (It really doesn't fail, it tell the caller everything was ok but save a dead.letter file).

There are probably other software that can detect the presence of a mailer and use it that I don't think to only disable cron mail output to be a full fix. The same smartmontools can be sending the errors/warnings to a root user on a third party server by default and not to the local root user. I think ssmtp should fail instead of trying mailhub if the mailhub line is removed, I tried that, there is a hardcoded server name in the binary (mailhub).

(In reply to manuel wolfshant from comment #10)
> Given that ssmtp requires a mailhub to function properly, there are only two
> approaches available:
> - provide a default configuration which does not work for anyone ( by not
> including a mailhub at all in its config or by using some random
> more-or-less guaranteed to not exist server name) which will then lead to
> the creation of dead.letter files for any user that uses ssmtp to send mail
> - provide a default configuration which uses the most obvious name of a mail
> server - approach that was taken by Debian when the package was created and
> by me when I packaged it for Fedora.

The first one is clearly superior.  There is really no good reason for a distribution default installation to assume that any domain name within the current (search?) domain (BTW set through insecure DHCP?) is under the same administrative control.

At the very least, ssmtp should IMHO be configured in such a way that it requires a clear administrative action (changing the configuration, or enabling a service; not just installing the package) to start sending mail externally to the default name.  This is orthogonal to the question of installing it by default.

(And separately, the default /usr/sbin/sendmail implementation should IMHO be capable of local delivery, and perhaps optionally SMTP, definitely not the other way around.  We will need to figure out how to achieve this with packaging, and sadly the most trivial way I can think of at the moment is to re-add a mail server to default comps.)

"clearly" is a very big word. Except for a few cases where the servers were named after movie characters or other similar ways, in most of the companies where I was involved they were using obvious names as "mail" or "imap ".

ssmtp does not run as a service so there is nothing to enable. If it is installed and not configured it will pollute the home of root with the famous dead.letter file

I'll have to test what happens when there is no config file at all. If it does not like the situation and insists on having a config file, we could just ship a ssmtp.conf.dist which should be edited and moved to ssmtp.conf. Does that sound sane enough ?

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

on F21, a 'yum remove ssmtp' which I would want to do since it is apparently what is blocking local mail delivery for cron, /etc/aliases (who should get root's mail!) etc,

and the following packages are listed as being removed for dependencies

google-chrome-stable
google-musicmanager-beta
redhat-lsb
redhat-lsb-core
redhat-lsb-cxx
redhat-lsb-desktop
redhat-lsb-languages
redhat-lsb-printing
tlp
uudeview

which is an odd list

But honestly despite all the 'this is how its supposed to work' blah-de-blah, the *default* configuration, STOPS local mail delivery completely and could potentially wind up delivering ROOT's MAIL to an EXTERNAL MACHINE NOT OWNED BY the machine's user. 

whatever you decide to do, you should make sure that by default, LOCAL mail delivery is not in any way impaired or compromised, and ONLY if the user MANUALLY intervenes with the config, should internal mail be allowed to be routed elsewhere. 

clearly I cannot remove it, because I want to keep google chrome (why google chrome requires it let alone uudeview, I have no idea) but I want root's mail forwarded to my local user on the box via /etc/aliases. 

What do?

(In reply to Scott R. Godin from comment #16)
> on F21, a 'yum remove ssmtp' which I would want to do since it is apparently
> what is blocking local mail delivery for cron, /etc/aliases (who should get
> root's mail!) etc,
[...]
> What do?

Prior to removing ssmtp, install a different mail transport agent, one which can better fit your needs. ssmtp has only one goal and only one way to fulfil that goal. By mere definition it NEEDS a mail hub to connect to in order to deliver mail. End of story.

okay.. so somehow it was not abundantly clear that it was the *complete absence* of any other MTA, that caused ssmtp to be that which was installed in their place, and that the presence of *any* MTA would satisfy the dependency, and thus after installing say, sendmail, one could remove ssmtp without triggering the other dependencies.


I can better understand your stance regarding the 'this is how ssmtp is supposed to work' schtick, however, it would have helped enormously if the above had also been made more clear sooner and that ssmtp were not the failsafe install in the absence of another MTA.

(In reply to Scott R. Godin from comment #18)
>it would have helped enormously if [...] ssmtp were not the
> failsafe install in the absence of another MTA.

I fully agree with this. I still do not understand why among all those that exist, it was selected as fallback / default . It simply is not suited for this task, its use case is completely different.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Updating for Fedora 23 because ssmtp may be pulled when installing Google Chrome (requires redhat-lsb). Currently it is pulling esmtp that at least has a default to use procmail.

esmtp doesn't look like an active project. It could happen that it be orphaned and by mistake ssmtp being pulled for everyone again.

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.