wrote:
> On Nov 28, mark@??? (Mark Murray) wrote:
>
> > Better to minimise the number
> > of apps that can deliver mail to /var/mail, and ensure they use a
> > co-operating locking scheme.
>
> Better still to deliver the mail to the user's home directory and avoid
> _all_ the problems of a common mail spool. Ever done an ls -l on
> /var/spool/mail with 10000 user mailboxes in it? How many coffees did you
> brew while you waited for it to complete.
This also creates problems. What happens if the home directory is NFS
mounted(how do you lock?)? Has permissions screwed up? Is on a full volume? Is
out of quota?
The above I just thumb-sucked without _too_ much careful thought, but I think
you get the idea.
> And yes, I would also recommend something like procmail as the delivery
> agent, but I also think the vulnerability of a writable spool is vastly
Procmail is OK - but it has its problems too. OTOH, if you can make the ruke
on your system "all mail to users shall be delivered by procmail", you have
reduced the number of conflicting programs that may fight for mailboc
ownership. (You have also given users a tool from hell for greating bounce
mail :-) )
> overrated compared to other security risks in common use with no fix,
> like all the popper daemons people are using the provide no logging of
> failed password attempts, or exponential backoff strategie, to name one
> glaring one off the top of my head.
While valid problems, these are not mail _delivery_ problems. They are
indications that the programs concerned need fixing.
Different systems dont necessarily solve problems, they often just replace
them with different ones. Given any chosen method for delivering mail, the
onus is on the folk who develop/administer/use this to make sure it works as
well and as securely as possible. That goes for any choice of system - mail,
news, your car etc.
M
--
Mark Murray PGP key fingerprint = 80 36 6E 40 83 D6 8A 36
This .sig is umop ap!sdn. BC 06 EA 0E 7A F2 CE CE
