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 before starting.
> 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.