Minimizing Time to Send Email

Programmers using Chilkat to send email can do some simple things, and can avoid common mistakes to optimize the time it takes to send an email.

1) A common mistake is when a programmer calls mailman.VerifySmtpConnection and mailman.VerifySmtpLogin prior to actually sending the email. The intent of the Verify methods is for an application to examine connectivity and login success after a call to SendEmail returns a non-success status. The best option is to simply call SendEmail first. If successful, then all is good. If not, then first examine the mailman.SmtpFailReason property. It will provide a general reason for failure, and two of these reasons are ConnectFailed and AuthFailure.

Many mail servers are SLOW in the time it takes to respond to a login. For example, we’ve seen many cases where Office365 takes 3-4 seconds to respond to the AUTH command (i.e. the login). An application wouldn’t want to experience this delay twice for every email sent. This is what happens if VerifySmtpLogin is called prior to each call to SendEmail.

2) When SendEmail completes successfully, Chilkat leaves the authenticated connection with the SMTP server open so that a subsequent call to SendEmail will use the already-established connection. However, if the connection is idle for a long time, a mail server is likely to close the connection. This is no problem for Chilkat because if SendEmail finds the connection closed, it will automatically re-establish and re-authenticate and all is good — except for the time delay in performing the re-connect and re-authenticate, which can be large. Therefore, an application could periodically call mailman.SmtpNoop to prevent the connection from being idle for too long, and thus prevent the mail server from closing the connection. This way, it’s more likely that the next SendEmail will find a valid/authenticated connection.

3) The LastErrorText property is common to most Chilkat objects. A feature of the LastErrorText is that if VerboseLogging is turned on, then the elapsed time (in milliseconds) for each context is shown within LastErrorText. (For cases where a context takes less that 1 milliseconds, the elapsed time is omitted.) Thus an examination of the verbose mailman.LastErrorText can help identify where the time was spent in sending an email. One can identify the time spent in the TLS handshake, in the SMTP authentication, and in the sending of the DATA and waiting for the final SMTP status response.

4) Finally, if you’re using an old version of Chilkat (meaning years old), make sure to update to the latest version. Over the years Chilkat is always improving the internals for performance and memory usage. At this point in time, slowness in sending email is highly likely to be caused by server slowness or other external factors, and not something within Chilkat. (I would venture to say this is also the case for any client-side implementation of SMTP — the slowness is not likely to be caused by the client-side implementation.)

Email “Received” Headers

When an email is sent, it should contain no “Received” header fields. Each time the email is processed by a mail server along the delivery route, a new Received header field is prepended to the email. The very first Received header is added by the SMTP server that the SMTP client (such as your app or a program such as Outlook) connects to to send email.

A typical scenario is that an email will contain two Received headers when delivery is complete. The 1st is the Receive header added by your SMTP server. This may often be something like “localhost” and may show an internal IP address, such as “192.168.1.###”. Your SMTP server then relays the email to its destination, and the mail server at the destination (at the receiver) then adds its Received header.

The Received header has a syntax such as this:

        Received: from ? by ? via ? with ? id ? for ? ; date-time

Some mail servers may not include all the parts, and spammers often fake Received headers.

Sending Emails with Large Attachments


I have downloaded the Chilkat Email component for POP3/SMTP.  When I tried to send email by attaching a file of size of  2 MB,  the email is not been sent.  Could you please let me know how I can send large size attachments using the Chilkat component?


There is no limitation in the Chilkat Email component.  It can send emails with attachments of any size.  The limitation is most likely in the SMTP server, or in the receiving mail server (not accepting emails larger than a certain size).  I would recommend examining the contents of the mailman.LastErrorText property after calling SendEmail (or after calling whichever method is used to send the email).  If everything looks OK and the SendEmail was successful, then check your SMTP server logs.  If all seems OK there, then it may be a limitation in the destination (recipient) mail server, or perhaps a size limitation set for the recipients email account.

Sending SMS Text Messages via Email-to-SMS Gateways

ASP: Send SMS Message
SQL Server: Send SMS Message
C#: Send SMS Message
C++: Send SMS Message
MFC: Send SMS Message
C: Send SMS Message
Delphi: Send SMS Message
Visual FoxPro: Send SMS Message
Java: Send SMS Message
Perl: Send SMS Message
PHP: Send SMS Message
Python: Send SMS Message
Ruby: Send SMS Message
VB.NET: Send SMS Message
Visual Basic: Send SMS Message
VBScript: Send SMS Message

Understanding BCC (Blind Carbon Copy)

When an email is sent with BCC recipients, the BCC email addresses are not listed in the header.   The “To” recipients are listed in the “To” header field, and the “CC” recipients are listed in the “CC” header field, but the BCC recipients are intentionally left out.  This is what makes it a “blind” carbon copy — the recipients are unable to see the BCC recipients.  (It is by design.)  Otherwise the BCC recipients would be equivalent to “CC” recipients.  To understand how BCC recipients receive an email, I recommend reading this blog post: SMTP Protocol in a Nutshell.   The BCC recipients are passed to the SMTP server in “RCPT TO” commands.

SMTP over HTTP Proxy

ASP: SMTP using HTTP Proxy
SQL Server: SMTP using HTTP Proxy
C#: SMTP using HTTP Proxy
C++: SMTP using HTTP Proxy
MFC: SMTP using HTTP Proxy
C: SMTP using HTTP Proxy
Delphi: SMTP using HTTP Proxy
Visual FoxPro: SMTP using HTTP Proxy
Java: SMTP using HTTP Proxy
Perl: SMTP using HTTP Proxy
PHP: SMTP using HTTP Proxy
Python: SMTP using HTTP Proxy
Ruby: SMTP using HTTP Proxy
VB.NET: SMTP using HTTP Proxy
Visual Basic: SMTP using HTTP Proxy
VBScript: SMTP using HTTP Proxy

Mailman.VerifyRecipients — Caution.


I started using MailMan.VerifyRecipients to periodically check bad email addresses and within one week of using the method the server was blacklisted.

Is this something you have heard of? or just coincidence?

I haven’t heard of this before — thanks for letting me know.

I suspect the reason is that VerifyRecipients works by connecting to an SMTP server and issuing “RCPT TO” commands for the purpose of getting the server’s success/failure response, but it stops short of actually sending an email.  This must be a tactic used by spammers to determine good/bad email addresses — and I hadn’t thought of that.   I’m going to add a note to the reference documentation to warn programmers to avoid this method.  You can instead call mailman.GetBadEmailAddresses() to get the failed email addresses (if any) after SendEmail is called.  The mailman.AllOrNone property controls whether SendEmail will return a failed status if  some of the email addresses were indicated “bad” by the SMTP server.

Here is a link to a page with related information about validating email addresses: