Hey Igor, Igor Morgado wrote: > == On antivirus/antispam configuration == > > If bongoqueue cannot contact antivirus or antispam server in specified > timeout? what is the default behavior? ALLOW mail or DENY?
The way the queue currently works is that agents register with it, and when they register they then get to handle mail. If they time out, their registration lapses, and the queue stops sending them mail. Ergo, the default behaviour is basically "allow". I consider this a bug for a number of reasons; I think the way we should handle this for now is that agent registration becomes a fixed configuration document. At that point, a timed out agent would simply stay timed out, and mail would freeze in the queue until the agent re-awoke. We can't send messages back to the sender at that point, so I imagine that if the queue became frozen for too long we'd try to alert the administrator somehow. > If I add more than one host in antivirus/antispam configuration, it > does round robin? or check all sources (example: to check the message > with more than 1 antivirus program). > > In antivirus configuration there is 3 parameters 127.0.0.1:3310:1, > what is that :1 ? :1 is "weight" or preference. If you have more than one host, it tries each in order of preference. I believe that entries with the same weight should be round-robined; at least, that's the theory. It doesn't check more than once. I think if we wanted to do that, we'd hook into mailscanner or something which already does that. > What means Max MX servers? > I believe this is the number of MX servers the SMTP client will try before it gives up. I think the RFC recommends 10 or something. > == On imap/pop/smtp/smtpc == > > One connection is handled with one thread? or there is more threads > per connection? a thread keeps alive after end of connection? I want > to know if 50 (example only), means 50 simultaneous conections or not. > If dont, how can I know/limit the maximum simultaneous connections? One thread per connection, yes. The thread will usually stay alive after a connection in some manner. I don't think at the moment you can limit the number of connections, and I'm not really sure that's something we'll want to do - I can't think of a good reason you'd actually want to limit resources which are pretty lightweight, especially since we use internal connections so often it would be meaningless anyway. What we probably do want is some kind of natural work limiter which acts to ensure that load on a Bongo server doesn't become too high. Cheers, Alex. _______________________________________________ Bongo-devel mailing list [email protected] https://mail.gna.org/listinfo/bongo-devel
