Steve Atkins wrote:
Mailserver concurrency seems to be a significant problem at large
receivers.
+1. But its an issue with all SMTP software developer/vendor to be
able to handle it for any receiver. Bad guys are not prejudice.
Scaling up as opposed to scaling out or both with a lesser of scaling
out (more threads per machine) is on the raise. Efficiency,
performance, loading an connection balancing is important.
It's not the bytes so much as the ports multiplied
by the seconds. Receiving the mail and throwing it away saves
you on IO bandwidth and memory, but it still ties up that
valuable delivery slot for the entire duration of the message
delivery.
Right. I find the issue is mostly how fast you can rid of the
lingering clients waiting to be processed.
Depending the socket stack SOMAXCONN value or socket provider limit,
coupled with connect/load balancing in the SMTP receiver, it is not
uncommon to see regular spurts of concurrent blasting where the
non-compliant SMTP client is just sitting there waiting for a "220 ".
A good way to see this is add a multi-line system policy display at
the connection server welcome response. The client is not expecting
the first line to contain "220-" like AOL.COM will show.
I explored ways to accelerate releasing the waiting clients, but SMTP
prohibits this because a DROP will cause the clients to retry. So the
only thing you can do is use the connection limit as a way to issue a
welcome response of
421 domain.com, Service busy. Try again later
But as you implied, the smtp "residence time" is still there waiting
for a client to drop or time out taking up a connection slots.
--
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html