SMTP over SSL

Hello all,

after a good deal of work we have a solution for the topic:

  1. According to Application note “SMTP over SSL” (2170049-2.0) page 1 to send an email over SSL an SMTP Client communicates with a local TCP Server which in turn sends the SMTP data to an SSL Client which in turn communicates with the remote SMTP Server. It is essential to install the local TCP Server correct as bridge according to the sample code smtp.c (AppliEntryPoint()). The TCP Server reads from both SMTP and SSL Clients!

  2. When creating the SSL Client it is usefull to use the option WIP_COPT_FINALIZER with a FINALIZER handler to close the SSL Client correct when the email is sent. This allows repeated sending emails without having to reset the system.

  3. The sample smtp.c shows an SMTP Client handler, which uses a „while (dataLength>0)“ loop in the WIP_CEV_WRITE case (function smtp_ClientTestDataWriteHandler()) to write data to the local TCP server. In case the email has more than about 5kB, this won’t work. Instead the TCP Server handler must use a flag in its WIP_CEV_READ event to distinguish between SMTP Client writes and SSL Client writes. Writes from SMTP Client should be stored in an array and sent to the SSL Client not before the SMTP Client has sent all data. Therefore the SMTP Client should signal End Of Mail by means of another flag to the TCP Server. When that flag is set, the TCP Server can write all the email data to the SSL Client.

  4. The SMTP Client handler must not write all data to the TCP Server in a „while (dataLength>0)“ loop, but should respond to the WIP_CEV_WRITE event with sending blocks of data (wip_write to DataChannel with correcting dataLength and pointer to dataBuffer). When all data are written it should raise the End Of Mail flag to start the TCP Server sending data to the SSL Client.

  5. When the TCP Server handler WIP_CEV_WRITE event sees the End Of Mail flag, it should write all buffered data with wip_write() to the SSL Client. This wip_write()s will have a result of „-1 bytes written“, which should not be regarded as error! The WIP_CEV_WRITE event will be called several times – until one wip_write() will return with all bytes written. Now the email is handed over completely to the SSL Client.

  6. The remote SMTP Server will end the session when it has received all email data. In this case the SSL Client will send an WIP_CEV_INVALID error to the TCP Server. Now it is time to close all closable connections. It starts with wip_close(SSLClient). This in turn starts the FINALIZER handler which should call wip_SSLClose(), wip_bearerStop(), wip_bearerClose() and wip_netExit(). With this done, another email can be sent without trouble.

Two questions remain:

  1. We have to use a root certificate to check the SMTP Server authentication. The certificate of the SMTP Server is certified by an intermediate service provider. The certificate of this intermediate service provider is not sufficient to check the SMTP Server certificate. Not until it is checked with the root certificate the check will succeed. Why?

  2. To create the SSL Client the clock is speeded up. It is set to normal speed, when the SSL Client handler receives its event WIP_OPEN. Despite that to open the channel lasts extremely long, some 40 seconds or so. Why?

The sample smtp.c seems somehow skimpy. The restriction to 5840B (i.e. WIP_COPT_RCV_BUFSIZE) data should have been discovered by its author.
It seems as if the SSL Client in the wip_ssl library also is somehow skimpy. The question in the „TCP/IP, Internet and Security libraries“ forum (wip_write returns -1) of the error -1 at the wip_write() to it is not answered yet. (https://forum.sierrawireless.com/t/wip-write-returns-1/7336/1)
The structure of the sample is not easy to see through. The use of an unpredictable while() loop in the context of an operating system is at the very least – dubious.
The lack of support in this topic is not future-oriented, as this topic will get more and more relevance in consideration of Stuxnet or the Snowden case. Or has Sierra Wireless indeed made yet a genuflexion before some „authorities“ to let the customers’ private data be inspected by them? Or why does it take so long a time to open the SSL channel?