286 views and no one else can test this huh?
The various reports about this problem finally intrigued me enough to find the time to do some poking about. To put it diplomatically, I suspected that a forum participant or two might know more about coding than about network communication.
The significance of port numbers is merely that they are used by SMTP mail servers (MTAs) to provide different protocols for different SMTP clients, which implement different protocols. The port number on which a particular server applications listen are de-facto standards, rather than ratified standards. Changing port numbers does not stop an application working. A client application which is not compatible with the server application, will of course fail to work whatever port it is listening on.Common SMTP Ports
1. Port 25 (SMTP) is plain text. The conversation between server and client is held entirely in plain text. This is where the majority of internet MTAs are and have been since SMTP was introduced. The big problem with plain text being that user credentials and passwords are easy to intercept by sniffing the transmission media.
2. Port 465 (SMTPS) is TLS encrypted. The conversation between server and client is held entirely in encrypted text. This is probably where the internet is headed; MTAs which are 100% encrypted from initial connection onwards.
3. Port 587 (STARTTLS) is a transitional hybrid. Think of it as a special interim measure between 1 and 2. Although 'interim' on the internet likely means the next decade or so. STARTTLS is an enhanced SMTP command; an optional extension to the SMTP protocol. STARTTLS allows the MTA and client to switch (one way) from plain text to TLS encrypted transmission. STARTTLS is often provisioned on Port 25 for compatibility with either
plain text or
encrypted transmission. When provisioned on port 587 it is implicitly a requirement that transmission must
become encrypted prior to authentication.Using the RS SecureSocket Classes
There has been some loose talk about 'bugs' in the RB classes. After spending about a day and a half experimenting with RB against an in house Exchange server and the GMAIL servers, my conclusion is that 'Limits' and 'Bugs' are being confused. A Bug
is when something does not behave as designed. A Limit
is when something does not do what it was not designed to do. You may argue with my definitions, but they are the ones I am using.
The RB SMTPSecureSocket is an SMTP mail client in a class. Message management and the underlying SMTP protocol is completely obscured by a couple of very high level methods. The good news is that developers using the class can easily automate sending of complex e-mail messages without having to implement the SMTP protocol directly, PROVIDED THE MAIL SERVER IS COMPATIBLE.
SMTPSecureSocket is compatible with 1 and 2. It is not compatible with 3, because the SMTPSocket control automates the entire SMTP send process from connection to transfer. The SMTP protocol is completely hidden from the developer's view or influence. When RS developed the control they did not implement support for the STARTTLS. There is no reliable way (I have found) for a developer to intervene in the automation, so there is no (reliable) way to use the control to transfer mail to an MTA which madates clients muct use STARTTLS.
If you want compatibility with 3. you need access to the SMTP protocol, to manually crank the transmission negotiation, authentication and message transfer. Contrary to what has been said on this thread to date, it is entirely feasible using the SSLSocket. You do however need to understand the gory detail of the SMTP protocol, specifically the STARTTLS and AUTH commands.
For testing purposes I developed using RB2009R2.1 Professional on Windows Vista. The (public) test target was smtp.gmail.com on ports 25, 465 and 587. What follows is a how to complete a STARTTLS negotiation using the SSLSocket connected to port 587 of a GMAIL server.
'Connect to the target MTA unencrypted
SSLSocket.Address = "smtp.gmail.com"
SSLSocket.Port = 587
SSLSocket.ConnectionType = SSLSocket.TLSv1
SSLSocket.Secure = False
'when connected request enhanced SMTP
SSLSocket.Write "EHLO " + cnMyHostName + chr(10)
'when response includes 250-STARTTLS
SSLSocket.Write "STARTTLS" +chr(10)
'When response includes 220 2.0.0 Ready to start TLS
SSLSocket.Secure = True
'simplified for illustration
If SSLSocket.SSLConnecting Then
'SSL is being negotiated
Loop Until SSLSocket.SSLConnected
The above code snippet produces an unencrypted connection which is switched to TLS transmission by implementing the STARTTLS SMTP command. From this point on the socket can be used to send the SMTP commands needed to complete authentication and message transfer (Google is your friend). RS provide the email class, which makes subclassing the SSLSocket into a STARTTLS capable SMTPSecureSocket pretty straight forward (but well beyond the scope of my tinkering).
RS are not (in my opinion) entirely off the hook. The SSLSocket documentation in the language reference is appalling.
No explanation or example is provided for using the CertificateFile and RejectionFile properties. What flippin use is "The file that contains the SSL certificate." to anyone? I also had SSL.Socket.Error firing when LastErrorCode = 301 or 303, and no mention I could find of codes > 108 in the LR. It is extremely poor on RS part, particularly as we have to pay a premium for the Pro version of RB for the privilege of using the secure socket classes.
Hope that helps and happy coding.