Intermittent SMTP issue

Hi,

Two users (out of 12) of a Windev22 application of mine are having intermittent problems sending emails. This started a couple of days ago. Sometimes they have to try and send an email 4 or 5 times before it goes. Until then they get this error screen. I can see that the error happens on the EmailStartSession command, but I can find no references at all in any PCSOFT documentation to any of the error codes shown.

Has anyone ever seen an error like the one shown in the attached file? Any clues would be really helpful.

Many thanks
Reg

Are you using SSL or TLS in the connection?
I had one problem using the smtp.office365.com SMTP server, i'm not sure if the error number was the same.
The problem was with the certifcates used in the smtp.office365.com server, in some computers the root CA wasn't in the trust CA list.

Regards

Paulo Oliveira

Hello Reg

Yes. One of my clients is reporting that error over the last week or so.
I think it is occurring prior to the smtpstartsession() as that process reports via errorinfo() and the messages from my clients are not from that

I think it is due to a Microsoft update as it is only affecting clients who use the smtp.office365.com server
This is with TLS, a username of noreply@domainname.com.au, a password and port 587

Clients who use domainname-com-au.mailprotection.outlook.com as the smtp server also with TLS but no password and port 25 are unaffected

Clients running on AWS servers inside a private network using an smtp server provided by the private network server are not affected.

I am sorry I can't offer a solution as I have handed the problem over to my client's IT support people
A reboot of the client server fixed the problem for a few days but then it reappeared.


Regards
Al

I don't konw if it helpls but in my case the certificate missing in the intermediate certifcation authorities was the Digicert Cloud Services CA-1

Regards

Paulo Oliveira

Hi Paulo,

I use TLS.

Cheers
Reg

Hi Al,

I've tried your option but the error's still coming up unfortunately. Thanks anyway...

Cheers
Reg

Hello Reg

Not sure if this is good news for you or not but I recompiled my app in V25 and the emailing worked fine.
As this is an intermittent thing I will try again over the next couple of days to confirm that it is really fixed

Regards
Al

Hi Al,

That would definitely be bad news for me, I'm planning to migrate away from PCSOFT so would ideally not be looking to upgrade any more.

Regards
Reg

Hello Reg

The client's IT company have created a work around but they are looking for a better solution because it is an unsecured solution.
The work around they came up with is :

Server name is domainname-com-countrycode.mail.protection.outlook.com
Password is blank
User Name is any legitimate email address for the domain
Session is unsecured
Port is 25

I am sure they have also done some changes in the domain records.

I will try and get more details.

Regards
Al

Microsoft is currently migrating all it's email infrastructure from one version of TLS to another one... and it seems it is done progressively...

This means that any email using microsoft infrastructure may be going through a server with the ols tls or the new one in a random fashion these days (similar problems are poping up on the french forum)

So one solution seems to be to change the tls option in the code, maybe all the time, maybe as a reaction to a first error.

Thanks Al

That would be great, thanks Al

Hi Argus,

That's very interesting, thanks for shedding some light on this, although I can't see an option in Windev (22) that allows me to set a version of TLS to be used.

Cheers
Reg

Hi Reg,

I work with version 24 and last few months I had the same trouble, not only with smtp.office365.com, but also with some other providers and yes it has to do with another version of TLS. I could not solve this within Windev so I started to use a commercial smtp-provider. No problems so far. Maybe you can use this option also, for good or temporary.

If you are interested I can give you more details.

Best regards,

Aad Gouka

Just for your interest, one of the providers told me that TLS 1.0 and TLS 1.1 were no longer supported. Maybe in newer versions of Windev this matter has been solved.

Did you try using EmailConfigure(emailParameterMode, 1)

I don't know what is the menaning of this but in some situations it helps.

Regards

Paulo Oliveira

Hi,

we use O365 (Pop3, SMTP) with WX26 and EmailConfigure(emailParameterMode, 1).
Works so far.

Fun fact:

Just today Pop3 Email Read hangs. The E-Mails looks like all others. We had to delete them and all then all works again.

I created a ticket for PC Soft.

Maybe thats the same problem as desriped in the list of patches at the french site:

WD260COM.DLL
Concerns WINDEV and WEBDEV
Email management
This update removes a possible lack of response from an application when reading or importing (EmailImportSource function) certain emails.
Incident reference: 123587
Available since: 12/10/2021
Request this
Module from the ST
Applies only to VI: 260101D

But there is no patch for the english version yet:-(

regards Michael

I'm only on V22 Michael, so I doubt they would patch that anyway.

I'm going to use my own smtp server from a reputable mail services company, that way Google and Microsoft can muck around as much as they like without it messing up my software

Hi,

FYI: I got the patch from PC Soft:

Fortunately a fix is already available. Use this link to download the upgrade for WinDev 26 version "Update 1 niveau 1" (260101D):

[stg.webdev.info]

This upgrade includes:

- \programs\framework\win32x86\wd260com.dll (4,94 Mo) - 26.0.321.10
- \programs\framework\win64x86\wd260com64.dll (6,16 Mo) - 26.0.321.10

Make sure the upgrade file is unzipped keeping the folder tree (path) into the \Programs\ folder for WinDev 26 and if asked accept to replace any existing files. Then create a new EXE for your application in order to deploy it with the new framework update.

This upgrade is about blocking email management on some EML, we do apologize for the inconvenience.

regards Michael

Hello Reg

I believe this link explains the problem.

aka.ms/smtp_auth_tls

Quote

Exchange Online ended support for TLS1.0 and TLS1.1 in October 2020.
New submission error speedbump to be introduced
We are fully aware that many customers will not have noticed the multiple Message Center posts and blog posts, and are not aware of clients or devices that are still using TLS1.0 to submit messages. With this in mind, starting in September 2021, we will reject a small percentage of connections that use TLS1.0 for SMTP AUTH. Clients should retry as with any other temporary errors that can occur during submission. Over time we will increase the percentage of rejected connections, causing delays in sending that more and more customers should notice. The error will be:

421 4.7.66 TLS 1.0 and 1.1 are not supported. Please upgrade/update your client to support TLS 1.2. Visit [aka.ms].

I have looked in the help but cannot find any mention of the version of TLS that PCSoft support in the EmailStartSMTPSession() function

I am running V24 and getting the error so It would seem that at the least all versions prior to that would also face the issue.

Does anyone know what versions of TLS are supported in versions 25 and 26 ?
I have version 26 but am trying top stay away from it as the interface is just unworkable for me.

Regards
Al

Hi Al,

That's very interesting, thanks for the information. I have switched affected customers over to an SMTP service that I have had set up for my main software product to get around this.

Have you raised the TLS question with PCSOFT?

Cheers
Reg

Hello Reg

Yes I asked them which versions they support in V25/26 as the earlier versions seem to only support TLS1.0

I think your solution of different smtp server is the best option and I will be moving affected clients over to the smtp server provided by their ISP.
This is actually the preferred option in the EmailStartSMTPSession() help

Quote

Notes:
•In most cases, the SMTP server to use is the SMTP server of Internet provider (and not the one of email account). For example, if you have Internet access via Orange and a Free email account, you must use the SMTP server of Orange (and not the one of Free).

Regards
Al

Best of luck

Hello Reg

I have received a quick and comprehensive reply from PCSoft Tech Support

Quote
PCSoft Tech Support
By default in Windows, emails are sent via the Windows "wininet" module in SSL mode (optionSSL constant) or in STARTTLS mode (emailOptionSécuriséTLS constant).

In this case, it is this Windows layer which performs the negotiation of the TLS protocol used, so it depends on the version of Windows used and its updates.

In this case, you must have at least Windows Vista / Windows 2008 Server to have support for TLS 1.1 and 1.2, and you must have activated these protocols in the settings of the Internet options of the workstation:

[blogs.msdn.microsoft.com]

To be independent of the Windows version and the protocols activated on the machine, since version 23 it is possible to use EmailParameter (emailParameterMode, 1):

[doc.windev.com]

In this case, the functions for managing the emails use an implementation managing the cross-platform internal to the WINDEV / WEBDEV framework. Thus, the management of emails is the same for your Windows, Linux and mobile (Android / iOS) platforms, and TLS 1.1 and TLS 1.2 are managed since version 23.

Regards
Al

Well, I checked one of the servers where this intermittent failure was a problem, but TLS1.2 is already activated as a protocol, so I'm not sure this entirely explains it. The emailParameterMode looks useful, but I'm not updating my versions anymore as I'm moving away from PCSOFT.

Thanks for the info though, it's all been very enlightening.

Cheers
Reg

You can use the EmailParameter (emailParameterMode, 1) in WINDEV22, for WEBDEV this is only available in V23.

Regards

Paulo Oliveira

Clients who use domainname-com-au.mailprotection.outlook.com as the smtp server also with TLS but no password and port 25 are unaffected

Clients running on AWS servers inside a private network using an smtp server provided by the private network server are not affected.

I am sorry I can't offer a solution as I have handed the problem over to my client's IT support people
A reboot of the client server fixed the problem for a few days but then it reappeared.


——————————————————————————————————————————
superstar



Edited 1 time(s). Last edit at 11/24/2021 08:01AM by WoodrowClarissa.

Hi,

I couldn't get the domainname-com-au ... method to work, maybe down to my lack of understanding. If the email domain I was working with was solutionj.co.uk, what would be the exact smtp server value I would use given that construct?

Cheers
Reg

Yes, this is a deliberate act by Microsoft but it only affects he use of Outlook when using SMTP.

Apparently you can get around this and avoid any program alterations by :-

Using PowerShell (as Admin) to run the Set-TransportConfig cmdlet in the Exchange Online management module:

Set-TransportConfig -AllowLegacyTLSClients $True

Then configure a new SMTP endpoint of smtp-legacy.office365.com

If anyone can get this working then I would like to know as I got stuck at Exchange Online. I trust that you need to use the Business version to access it and not the standard Office 365.

I have an application in Windev 21 that has been working faultlessly with only minor updates for the last five years and this is the first issue that might require a Windev version update. Fortunately I wrote in routines to send emails using either SMTP, Outlook or MAPI - so as long as Outlook is set up and working then this can be chosen as an alternative option to send emails.

Update 21/12/2021 - I set up relaying using Google Gmail (which allowed me to use my original email address) and swapped to smtp.gmail.com instead of smtp.office365.com and the problem no longer occurred.

All the emails coming out of my program when using Outlook under SMTP show TLS 1.2 in their source and those sent under Gmail also show the same, so it is a little bit confusing.



Edited 3 time(s). Last edit at 01/02/2022 12:39PM by attlebax.