[Mimedefang] timeout before data read?

[Rich West]

(this got bounced the first time around because it contained too much 
quoted material.. bah)

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')
>