Once upon a time, Arjan van de Ven <arjan@xxxxxxxxxxxxx> said: > and it's not like sendmail/exim/whatever can't decide to become a daemon > if it can't deliver... but only then. That would require more privilege in the /usr/sbin/sendmail program. For example, with sendmail, the binary is setgid-smmsp, which is just enough privilege to write a new entry to the MSP queue directory. You probably don't want to run a new daemon as a normal user, so then you have to have a setuid-(someuser|root) binary somewhere to start a daemon on demand. You'd still need to do something on boot, since there could be entries in the queue from the last time the system was up (at which point, you might as well just start a queue monitor daemon, maybe something using inotify to only wake up when a new queue entry is written to be a little more efficient). Not saying it isn't possible, but it would take some (possibly not insignificant) changes to make it work sanely and securely and cover the corner cases correctly. Also, part of the justification for a local MTA is that some programs want to use SMTP on 127.0.0.1, which requires some kind of daemon running there (either an MTA or xinetd to fork an MTA on demand). If you want a local MTA (which IMHO should be there) and want to make it work differently (start running a queue only on demand for example), you're probably going to be better off writing an MTA to match your special requirements (or starting off with something simple like ssmtp), rather than trying to shoe-horn such changes into a "full fledged" MTA like sendmail/postfix/etc. -- Chris Adams <cmadams@xxxxxxxxxx> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
