This is advice for sending email to a list, such as for a newsletter, using the Chilkat MailMan object.
In app that intends to send many emails, you'll want to explicitly and carefully control the lifetime of the mailman object, and perhaps the number of emails sent in a single connection.
Creating a new mailman object for each email to be sent requires the overhead of establishing a new connection, authenticating, and then sending. This is generally too time consuming. (The disconnect from the SMTP server would happen whenever the object instance is destroyed, or if the CloseSmtpConnection method is called.) Depending on your programming language, the object instance destruction can occur at (1) garbage collection, or (2) when the last reference is removed, or (3) when the mailman is explicitly deleted/destroyed by the application code. This corresponds to three models: garbage collection (such as C# or Java), reference counting (such as ActiveX or Objective-C), or explicit delete/free (such as C/C++).
If too many objects with open connections accumulate, then the SMTP server will likely (eventually) hit a limit and refuse additional connections. On the other hand, SMTP servers often have limits as to how many emails can be sent on a single connection. Therefore, you may wish to explicitly close the connection (CloseSmtpConnection) and re-open it (OpenSmtpConnection) after every N emails sent.
The SmtpPipelining feature may be used to enhance performance. You might test w/ and without this feature turned on.
Also, if the MailMan's SmtpHost or other connection-related properties, or login/password related properties are changed, then the next call to SendEmail will automatically disconnect and automatically re-connect and re-authenticate using the new connection/authentication settings. Rather than rely on MailMan to do it automatically, you may wish to have your program explicitly do it.
Also.. the MailMan.SendEmail method will always automatically connect/authenticate w/ the current property settings if it has no established valid connection. The OpenSmtpConnection method can be called to explicitly establish the connection beforehand.
In summary, I would structure an application code so that:
1) The lifetime of the MailMan object is explicitly controlled. You may choose to use a single MailMan instance for a complete mailing.
2) The lifetime of the connection to the SMTP server is controlled. You can explicitly close it and re-open it every N emails.
3) You can experiment with SmtpPipelining (on or off) to see if it's worth doing.