My IT colleague, Tony Jimenez, acquired a paid-for copy of West Wind Client Tools 6.0 for me a few weeks ago. I’ve run into a serious problem, and have yet to resolve it despite tackling it from many different angles.
Our current application is written in VFP 9.2 and is processing email using by instantiating an older version of Outlook. This approach will not work when our Exchange Servers are upgraded in the next few weeks, so I looked to WW60 to handle emails in a cleaner, native manner.
WW60 works well on the older Exchange Server, but not on the newer one we’re migrating to. With the newer Exchange Server, WW60 returns an error (documented below under the current test code I’m working with).
If this issue cannot be addressed through VFP 9.2, note that I do own a copy of Visual Studio 2015 with C# 6.0 and that .NET 4.5 or 4.6 is installed here. I know my way around VFP quite well but am a relative neophyte at C# (and posted solutions dealing with the ServicePointManager seem to lean on C#, as it doesn’t appear obvious how to instantiate an object from that .NET class via wwDotNetBridge).
If this needs to be handled as paid support, please advise.
SET DEFAULT TO c:\wwclient60 SET PATH TO classes; tools; console; additive DO c:\wwclient60\classes\wwHTTP.prg DO c:\wwclient60\classes\wwDotNetBridge DO wwSmtp && load libraries PUBLIC loBridge as wwDotnetBridge loBridge = CREATEOBJECT("wwDotnetBridge","V4") public loSMTP as wwSmtp loSmtp=CREATEOBJECT("wwSmtp",0) loSmtp.cMailServer="10.254.1.31” && works on earlier Exchange at 10.24.1.30 loSmtp.cSenderEmail="firstname.lastname@example.org" loSmtp.cSenderName="Omega" loSmtp.cUsername = "omega" loSmtp.cPassword = “*******" && Obfuscated due to public posting loSmtp.lUseSsl = .T. loSmtp.cRecipient="email@example.com" loSmtp.cSubject="wwSmtp Test Message" loSmtp.cContentType = "text/html" loSmtp.cMessage="Who said this had to be <b>difficult</b>?" loSmtp.cAlternateContentType = "text/plain" loSmtp.cAlternateText = "Plain text can go here." llResult = loSmtp.sendmail()
Mail is sent successfully through earlier version of Exchange Server with the above test code (the password is obfuscated). For more recent Exchange Server versions (to which we’re migrating very shortly), the code above returns the following error:
“The remote certificate is invalid according to the validation procedure.”
There is indeed a certificate name mismatch which Outlook overlooks, but that WW60 does not. Aye, there’s the rub.
Sorry for stating the obvious, but you'll need to fix the server certificate. ??
No way around that as the connection simply won't go through and there's no way that I know of to make a connection with an invalid certificate in place on the server. I doubt you'll have any more luck with other email clients either.
My guess is outlook overlooks this because it's probably a private certificate and outlook automatically installs and uses the private certificate through the Exchange protocol used to connect to the server. However, over the ESMTP connection that won't work.
So ultimately the way to fix this to have a proper open certificate that is recognized without custom protocol cnventions.
+++ Rick ---