Jeff Mincy wrote: > From: Bowie Bailey <bowie_bai...@buc.com> > Date: Thu, 26 Mar 2009 08:48:30 -0500 > > Brian J. Murrell wrote: > > On Wed, 2009-03-25 at 15:01 -0400, Michael Scheidell wrote: > > > > > > Match your MTA processes to the spamd children. Your MTA will > send > > 4xx 'busy now, come back to play later' message. Let the > sending > > MTA queue it back up (or zombies will just go away) > > > > I don't really see that as a socially responsible action. If my > > mailserver was completely loaded to the point of not even being > able > to queue a message, I'd buy pushing back on the sender with > a 4xx, > but the reality is that while I may have maxed out my > spamd children, > I can likely still receive and queue mail > locally. > > > The queueing up of mail to spamd really belongs on the local > server, > and should not become a burden on sending MTAs. > > This really depends on where you are running SA in the delivery > process. > I'm kinda gathering that this is not possible within > spamassassin > itself. Probably in fact it is for at least some > MTAs but how to > achieve it becomes MTA specific and OT here. > > SA is not capable of any sort of queuing. If you need that, you > will have to make your MTA do it one way or another. > > The spamassassin executable doesn't queue - it just starts up a new > process each time it scans a message. > > However, spamd queues connections when all of the children are busy > processing messages. > > From the spamd man page: > > -m number , --max-children=number > This option specifies the maximum number of children to > spawn. Spamd will spawn that number of children, then > sleep in the background until a child dies, wherein it > will go and spawn a new child. > > Incoming connections can still occur if all of the > children are busy, however those connections will be > queued waiting for a free child. The minimum value is 1, > the default value is 5. > > As long as messages are processed reasonably quickly everything will > be fine. If spamd takes too long to process messages then the MTA > will start timing out (like 2-10 minutes). What happens then is up to > the MTA. > -jeff
Ok, it does queue connections, but that is very limited. This thread is specifically talking about what happens when spamd is taking too long. If I'm reading the spamc man page correctly, it will wait 5 minutes for spamd to process the message, but it will only wait about 3 seconds for a connection to spamd (3 tries with 1 second sleep between them). That's not much of a queue. Or am I missing something? -- Bowie
