Red Hat Bugzilla – Bug 61459
Do not start sendmail in vain
Last modified: 2014-03-16 22:26:12 EDT
Description of Problem:
With a "normal" firewall configuration where smtp port is blocked it
does not seem to be much point in starting sendmail daemon which cannot
receive anything anyway. This daemon running is not needed neither for
sending out anything nor for a delivery of a local mail; both will work
just fine with it stopped. The only possible use is for testing or for
a blocking a boot sequence for a long time if a name resolution
happens to be, hmm, imperfect. The later "use" is likely unintended.
It seems that either startup should examine a status of an smtp port and
refrain from starting up sendmail if this is blocked, but with an override
(like "service sendmail reallystart" :-) or, maybe better, initial
configuration should make sendmail service "off" on all levels if no mail
will be coming.
There's no way for the package install system to know if mail will be coming or
not... also, some things talk to sendmail on localhost to send mail.
In general, we don't have a policy for services to check if their ports are open
> There's no way for the package install system to know if mail will be
> coming or not.
Eh? Firewal configuration is a part of an initial install.
> also, some things talk to sendmail on localhost to send mail
To daemon? Care for an example? Sending local mail, say from cron,
does not require anything to listen on port 25. Check for yourself.
The same with an outgoing mail although with that it is a good idea to
run queue from time to time or things may get stuck if the other end
is not a receiving mood.
Firewall configuration isn't written before packages are installed. Moreover,
with sendmail-8.12.x, it pretty much has to listen somewhere, so the message
sumbission stuff can work correctly.