By queue runners do you mean TCP connections to your destination server?

I don't think you can limit/set this in SF, but I'd have thought you should be able to do this on your receiving server - ie set the maximum number of listening threads. If they're all in use, SF will queue the emails it couldn't send through and retry after n minutes set under 'Process queue every n minutes' under Settings/Configuration.

AndrewD,

SpamFilter has a limit on the maximum number of concurrent incoming connections (on the Settings - Configuration tab).

When it comes to forwarding queued emails to your destination SMTP server, SpamFilter will use one half of that value to calculate the number of maximum concurrent connections to your server.

AndrewD,

SpamFilter will forward any "clean" email it receives immediately in real-timeas it arrives. So assuming a listserver is sending massive legitimate emails to your users, and the incoming limit in SpamFilter is 40, in theory SpamFilter could have 40 concurrent incoming connections from that listserver. in this case, as emails are forwarded in real-time, SpamFilter will also have 40 outgoing concurrent connections to your destination mail server.

The only time when emails will be queued up is if your destination SMTP server is offline. In that case SpamFilter will queue the clean emails, and will attempt delivery on regular intervals. When your server will come back online, then in this case SpamFilter will forward all the queued emails to your destination SMTP server, using a number of concurrent threads equal to one half of the "Max incoming connection".

SpamFilter should forward as many emails as it can when flushing the queue, as when this happens it will be because your server was down. If it was down for several hours, there may potentially be hundred of thousands of clean emails queued for delivery, and they need to be processed as fast as possible to avoid further delays to end users.

You should size the value of "Max incoming connections" to a value that your destination SMTP server can handle.

Hi Again,

The reason for reducing threads is that the SMTP standard supports multiple smtp transactions in a single TCP connection (one after the after).  This is what the RFC dictates, and every other good MTA I have used follows these rules.

Typically you will have connections from all over the world (slow) being forwarded to a few internal severs. You also have the luxury of queuing internally (for a few seconds if needed).  It makes sense to follow the standards and not just spew TCP connections through, but instead group them by destination server and pass through seqentially (with additional queue runners if needed).

If you take this approach (and follow the standards) there is no bottle-neck, and things actually run much more efficiently on both ends).  I have worked on some exceptionally high volume mail systems (in the millions/day) - and this is the only good way to approach the situation.

I am not trying to be overly critical of this product, instead pointing out a weaknesses that could be improved upon.  I just can't see your product being used in a high volume isp environment.

Thanks,
Andrew.

lyndonje wrote: Hi Andrew, If SF was hadling 40 incomming connections, but only passing out 5, assuming your inbound feed was constant you'd end up with a bottleneck on SF. Why would you want that? Also, if SF is receiving 40 incomming connections, what would happen if you didn't have SF? Your destination server would only have to process the 40 concurrent connections anyway, plus processing the spam. If you inbound load is too high for your destination server to handle, you need to upgrade or introduce a second for load balancing. If you can limit the number of inbound connections on your destination server, which I assume by your earlier comment "It is possible to set this in every other MTA that I have used" that you can, why don't you do this? That way you'll have a bottleneck on your SF, which would be the same as if what you wanted to achieve was possible.