Milter-greylist

Jonas Israelsson wrote:
> Hello!
>
> I am trying to implement milter-greylist at a quite high mail volume site. In peak we have about 12 mails a second and a total of about 500.000 mails / day.
>
> The greylist daemon seem to last for about 10 minutes or so before the following errors pop up on the log..
>
> Aug 31 16:24:38 7800005 sendmail[14741]: [ID 801593 mail.error] l7VEOS0D014741: Milter (greylist): timeout before data read, where=negotiate
> Aug 31 16:24:38 7800005 sendmail[14741]: [ID 801593 mail.info] l7VEOS0D014741: Milter (greylist): to error state
> Aug 31 16:24:38 7800005 sendmail[14741]: [ID 801593 mail.error] l7VEOS0D014741: Milter (greylist): init failed to open
> Aug 31 16:24:38 7800005 sendmail[14741]: [ID 801593 mail.info] l7VEOS0D014741: Milter (greylist): to error state
>
> Does this mean the milter daemon simply cant cope ?
>
> In busy hours we have about 400 sendmail children running.
>
> The Machine is a Quad Cpu AMD-64 (extra all) with 4 GB memory running Solars 10, and yes I have compiled 64 bit binarys. 
>
> Is there anyone out there with experiences using milter-greylist in a  site with similar volumes ? 
>   

Just a comment on the 400 sendmail children running . . .

We were seeing increasing numbers of sendmail children, until the limit
was hit and mail could not be accepted. The log files showed repeated
entries where it stopped accepting connections and then resumed. But the
system load shown by uptime was low, and top didn't show sendmail,
mimedefang or any related stuff eating the cpu. Finally, netstat showed
that the sendmails had established connections and weren't doing
anything. It seems the bots are not closing the connection now when they
are rejected. The default in sendmail.cf is to wait an hour before
closing the connection, which seems archaic in this day and age. So, we
started diddling parameters in sendmail. Took the number of children way
down and greatly increased performance quality for our users. I believe
the most pertinent parameter for that particular issue was
Timeout.command. We took our number of children from 200 down to 20-50
almost instantly, by changing that from 1hr to 5m. Your volume is higher
than ours, so numbers will vary.



---------------

Chris Hoogendyk

-
   O__  ---- Systems Administrator
  c/ /'_ --- Biology & Geology Departments
 (*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst 

<hoogendyk@...>

--------------- 

Erd\ufffds 4