Ok, this was a fun case and I never had such fun on a CDOSYS case & I am lying. I spent nearly all day in hunting down a Transport failure issue when sending emails using CDOSYS and Exchange 2007 as backend.
This was the configuration of the default Receive connector, pretty secured…huh??? Yeah!!!
Goal: Send secured emails using CDOSYS over TLS using BASIC authentication
Challenges: ‘80040213’ The transport failed to connect to the server.
I confirmed that the issue is not in connectivity and I could easily do a telnet to port 25 and get the banner and supported verbs lists. The problem was that I could not do STARTTLS… heck it was not listed in the verbs list. With my “Mr. Fix It” cap on I took an ETL trace and started debugging the issue.
I concluded that the certificates was the blocking issue, and I quickly turned back to the Event Viewer to see the following event log
Event Type: Error
Event Source: MSExchangeTransport
Event Category: TransportService
Event ID: 12014
Time: 6:26:25 PM
Microsoft Exchange couldn't find a certificate that contains the domain name msgex07.msglab.com in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector Default with a FQDN parameter of msgex07.msglab.com. If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Once I have resolved the Certificate issues, I can see the STARTTLS verb supported by the Exchange server.
If you do not see STARTTLS and DO see the event log entry then you need to verify the following things
1) The FQDN of the server which is specified in the code, abc.xyz.com MUST match with the FQDN of the certificate
2) The FQDN of the Receive Connector MUST match the FQDN of the certificate
3) The Certificate in itself should be a valid one (not expired or with missing root CA)
You can verify these details with the help of your Exchange Admin and the following Powershell Cmdlet
Get-ExchangeCertificate | fl
Enable-ExchangeCertificate –Services SMTP
See the below link for more information
I recently had couple of customer reporting that their existing/new OWA customization code is not working in Preview mode.
You will notice the following error message displayed instead..
"This type of message isn't fully supported in Conversation mode. Click here to open the full version, which may show you more details or features."
This same form should work in Exchange 2007.
I have two news here, first there has been changes to Registry.xml and there has been couple of new clients support added. Make sure you have all of them listed in your Registry.xml when you run the test on Exchange 2010
<Client Application="MSIE" MinimumVersion="7" Platform="Windows NT" /> <Client Application="MSIE" MinimumVersion="7" Platform="Windows 2000" /> <Client Application="MSIE" MinimumVersion="7" Platform="Windows 98; Win 9x 4.90" /> <Client Application="Safari" MinimumVersion="3" Platform="Macintosh" /> <Client Application="Firefox" MinimumVersion="3" Platform="Windows NT" /> <Client Application="Firefox" MinimumVersion="3" Platform="Windows 2000" /> <Client Application="Firefox" MinimumVersion="3" Platform="Windows 98; Win 9x 4.90" /> <Client Application="Firefox" MinimumVersion="3" Platform="Macintosh" /> <Client Application="Firefox" MinimumVersion="3" Platform="Linux" /> <Client Application="Chrome" MinimumVersion="1" Platform="Windows NT" />
Secondly, This issue is “by design” that the custom forms will not work in Conversation Mode for now.
This issue seems like something obvious that the product group will want to fix in the next major version. It is currently not under consideration for a service pack or rollup for Exchange 2010, but may be considered at some point based on customer feedback.
If this issue is causing troubles for you then I would request you to contact PSS.
This is just FYI that we know the limitation of System.Net.Mail classes and its incapability of sending secured emails over SSL / SMTPS.
The SmtpClient class only supports the SMTP Service Extension for Secure SMTP over Transport Layer Security as defined in RFC 3207. In this mode, the SMTP session begins on an unencrypted channel, then a STARTTLS command is issued by the client to the server to switch to secure communication using SSL. See RFC 3207 published by the Internet Engineering Task Force (IETF) for more information.
An alternate connection method is where an SSL session is established up front before any protocol commands are sent. This connection method is sometimes called SMTP/SSL, SMTP over SSL, or SMTPS and by default uses port 465. This alternate connection method using SSL is not currently supported.
This is the limitation of SmtpClient and publically documented here but often missed
You may also ask your service provider to see if they can support STARTTLS sessions, which is fairly secure and not too complex to implement.
You have an option to use either CDOSYS / System.Web.Mail from .Net 1.1 which internally uses CDOSYS to send out email. CDOSYS had this support but then the support was dropped in System.Net.Mail. Some may argue that why this downgrade, when CDOSYS had this support why System.Net.Mail drop this support – well this is not really a downgrade but a design decision that they made to support only one of the two optional ways to implement SSL while the SMTPS is used less commonly when compared to TLS.
Here is the sample code that can do the job for you, please do not forget to add a reference to System.Web.dll into your project for this to work. I have compiled it on VS2008 and found it working.
Please do proper testing before using this code in production and treat this piece of code just for the sake of educational purpose.
static void Main(string args)
MailMessage msg = new MailMessage();
msg.To = "email@example.com";
msg.From = "firstname.lastname@example.org";
msg.Subject = "This is a test email using System.Web.Mail";
msg.Body = "Hello There!!!";
msg.BodyFormat = MailFormat.Text;
// SMTP Server to use
// SMTP Port to use
// Send using Value, leave it to 2 for sending via SMTP Port specified
// Use SSL : 0 = False, 1 = True
// Authentication mode:
// 0 - Anonymous
// 1 - Basic
// 2 - NTLM
// Username and password to connect to the SMTP Server
We have an official release for the issue and if you are facing this problem then I would recommend you contacting PSS and refer to this blog
I am expected it to be released in a public KB in some time but for the time being you can request for the hotfix by contacting PSS
UPDATE - 7/21/2010
If you prefer not to contact PSS, you can download the hotfix by yourself from the following link.