Have Our Friends in Redmond put delay loops into the
SMTPMail.Send() method, or does it /really/ take almost a second
to send a mail message?
I've written a windows service that send emails. It was originally
intended for /small/ volume, direct communication with our clients.
Somebody, however, has decided they want to send a message to
the entire client-list - nearly 200,000 entries - and, at our current
throughput, this will take us several *days* to send (we're /peaking/
at around 60 message a /minute/ at the moment. We've tracked the
bottleneck down to the SMTPMail.Send( MailMessage ) method and,
monitoring the SMTP Server at the "other end", it looks as though the
Framework class is opening and closing a "connection" to the server for
each and every message, which is slowing things down tremendously.
(The SMTP Server is happily dealing with the actual send requests at
a rate equivalent to 10 message a second, if we could monopolise it).
So, are there any properties in the SMTPMail namespace (or /anything/
else that we could configure to improve our throughput, or am I going
to have to resort to using raw sockets and bounce through the SMTP
protocol myself?
TIA,
Phill W.