On Fri, 2 Apr 2004, Havoc Pennington wrote: >On Thu, 2004-04-01 at 20:52, Chris Adams wrote: >> Once upon a time, Jeremy Katz <katzj@xxxxxxxxxx> said: >> > Heh, that's just sick. How about my statement holding for when the >> > clients are set up correctly? :-) (ie, if you don't use local sendmail >> > and just do smtp, then local /var/spool isn't needed) >> >> Way too many programs expect to be able to call /usr/sbin/sendmail to >> assume everything will use SMTP. And really, that is how it should be; >> why should every program be required to have an SMTP client built-in? >> >> The nice thing about that is that you are pretty much guaranteed that >> you can send mail at any time, even if the network is down. Sendmail >> (or another local mailer) will queue the mail locally and send it when >> it can. It is not a good idea to have things like cron jobs get stuck >> or lose their output because a remote SMTP server was unreachable. > >I think we have to assume that a managed read-only OS image sort of >deployment would have some limitations in possible configurations and >what apps could do. After all the whole point is to lock things down. > >One setup would be that each user has an outgoing mail queue in their >home directory, since homedir already has to be writeable by the user >and gets backed up and so forth. Surely you could provide a >/usr/sbin/sendmail that worked this way. > >A queue in /var is suboptimal because it partially defeats the purpose >of the deployment model - it leaves per-machine state to be corrupted, >backed up, hacked, etc. > How is printing done? How do cron jobs mail when a services home directory may not exist and the shell is nologin? Not trying to poke holes as much as think things out-loud. I wonder if queues should go under /var at all? -- Stephen John Smoogen smoogen@xxxxxxxx Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem --