Wow! Thanks for the great response!! Your response would be a great addition to the FAQ (hint, hint).
For the short term, because of this situation, I was forced to disable MimeDefang (ack.. it killed me to do this), and the server responded well.
I agree with your assessment that the remote side was probably sending too aggressively from whomever was sending it. I dug through the maillog and couldn't narrow it down to a specific address, although the recipient seemed to be the same in a number of cases.. this will take more investigation on my part, that is for sure. :)
Our existing sendmail M4 setting is:
INPUT_MAIL_FILTER(`mimedefang', `S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T, T=S:60s;R:60s;E:5m')dnl
With the mimdefang setting being: MX_BUSY=600
Which, although I looked at this and said to myself "That looks ok", after pasting it here, I realized that 600 seconds is 10 minutes. Hrm...
A definite adjustment to one or both to syncronize them would be a good thing. Although, that makes me wonder if the sendmail settings we currently have are too aggressive...
Oh, and for those that asked, we have the max_message_size set to 1048576 (1MB). This *is* email, not ftp. :)
After getting those settings fixed, I was able to get things back up and running again. I've had a few hiccups throughout the day as there were a couple of situations that spiked up the load. As it is, with my mimedefang-filter, I'm only spam scanning:
if ((-s "./INPUTMSG" < 100*256) && (! exists($SendmailMacros{'auth_authen'})) )
I'm going to have to dig a bit more, but, overall, the tweaking of the timeouts did help a lot..
-Rich
Aleksandar Milivojevic wrote:
There were some discussions on the list about this recently.
Basically what happens is that you either configured mimedfang-multiplexor or sendmail or both with too short timeouts. Because of this either multiplexor or sendmail or both are not waiting long enough for filtering to finish. By your description, I'd say somebody sent you *very* large email, and sendmail is the one that got impatient. Mail is rejected with tempfail, old process is still spinning, remote side tries to redeliver (probaby too agressivly), new process starts, and you end up going in circles, and your load average hits the roof.
The first timeout is in mimedefang-multiplexor. It controls for how long multiplexor will let the child to run before killing it. The second timeout is in sendmail. It controlls for how long sendmail will wait for MIMEDefang to do its job. You should set this two timeouts to aprox. same value (maybe setting multiplexor timeout minute or two shorter). That way, old process will be terminated by multiplexor at about same time as sendmail gives up. It really doesn't make any sense to have them set differently (the first that you hit will couase tempfail).
How long should the timeout be. Depends on how large emails you are allowing (and the speed of your machine). If you limit the size of email in sendmail to say 1-10MB, around 15 minutes should suffice on reasonable fast machine. If you limit it to anything larger, values as large as 1 hour should be considered.
Small hint, do not run SpamAssassin on large emails. If mail is larger than say 100kB, skip SpamAssassin checks. They will take forever to complete.
Oh, BTW, multiplexor timeout is controlled in /etc/sysconfig/mimedefang (well, at least on RedHat type systems):
MX_BUSY=1740 # (29 minutes, we give up before sendmail does)
sendmail timeouts are defined in sendmail.mc:
INPUT_MAIL_FILTER(`mimedefang', `S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T, T=S:30m;R:30m;E:30m')
_______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
