--------- Received message begins Here ---------
>
> > 1. email -> sendmail
> > 2. sendmail figures out what it has to do with it. turns out it's deliver
> ...
>
> > Now, in order for step 4 to be done safely, procmail should be running
> > as the user it's meant to deliver the mail for. for this to happen
> > sendmail needs to start it as that user in step 3 and to do that it
> > needs extra privs, above and beyond that of a normal user.
>
> email -> sendmail
> sendmail 'its local' -> spool
>
> user:
> get_mail | procmail
> mutt
>
> The mail server doesnt need to run procmail. If you wanted to run mail batches
> through on a regular basis you can use cron for it, or leave a daemon running
And get_mail must have elevated privileges to search for the users mail...
or sendmail must have already switched user on reciept to put it in the
users inbox which also requires privleges...
And an additional daemon (owned by the user) is yet another attack point...
Cron could be used to batch message handling... as long as it runs before
the users quota is used up. This becomes the same as using IMAP or fetchmail
to download it.
It's much more efficent to process each mail as it arrives.
All this does is move the program that requires privileges to somewhere
else. It doesn't eliminate it.
Granted, sendmail could use a better implementation of a security model.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [EMAIL PROTECTED]
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
