Hide Forgot
One of local users tried to send big email (3 letters for total 120 MB)to other local user. Second tried to read them using POP-3. The system buzz for some time by the harddisk, and third user said me that server is down. I turn on monitor and saw text "Out of memory for <process>". I tried to log in and saw "Out of memory for mingetty". I cold reboot server. Mail actions continued. I log in and saw I have no DNS server running. Several other processes was absent. One time I enter "ps ax" server said "signal 11" and nothing list. I repeat - and ps worked. I shutdown my server and saw message about swap error (while shutting down swap). I disconnect network cables from my server and boot. It buzz harddisk for several minutes and became normal. I checked filesysem - all is ok. Several megabytes free. I deleted mail queue and mailbox of receiver manually. While troubles I saw nearly zero free memory and exact zero free space in swap. I use 50 MB swap partition. I was surprised by signal 11 error from ps (happened several times, but after repeat command it worked) and by disappeared processes (named, arpwatch, may be some other - I cannot say exact). After first shutdown system worked slowly and unstable, but worked, while in first report I had to turn it off without halt.
On any default Linux installation there are no resource limits set up to prevent users from using gobs of memory/disk and other resources. As such, it is relatively easy for any user to hog resources and take a system down, however most systems have some aspect of trust with users and as such this does not turn out to be a problem, and is why it is the default in most (all?) Linux distributions, and other UNIX and Unix like OS's. The general idea being that for most systems, sysadmins can police their users adequately to teach them responsible usage of system resources, such as "don't send 200Mb file attachments in email" et al. While I would try to deter users from sending large mail like that, there is no technical reason why a 200Mb file attachment could not be sent. The software is capable of doing so. The real problem is that the system that you are running does not have the resources to handle such. The solutions that you might consider include: 1) Instruct users not to send large messages or 2) Add more resources to the system to handle the worst case or 3) Implement systemwide resource limitations to protect the system from such problems. #1 is the preferred system if you trust your users to not purposefully knock the system down. #2 is only viable if you actually want users to be able to send such large messages, and the upgrade is worth the effort. #3 is implemented by system policy that you must define as administrator of the affected systems. There is no way to predetermine such resource limitations in a general sense, and as such by default resource limitations are disabled on new installations. Look at the manpage for "ulimit" for instructions on limiting resources. You may also want to look into disk quota support as well.
You can also tell sendmail to limit the maximum size of messages recieved as well to prevent large messages from being accepted in the first place.