Leaderboard

In June 2022 Google stopped accepting traditional authentication methods for it's SMTP and POP3 email servers, instead requiring OAuth2, and I believe Microsoft is doing the same from October 2022. The main different with OAuth2 is the application does not store the account password so is unable to share it. Instead the user is directed to a sign-in web page from Google or Microsoft where the account details are entered and the application receives limited life tokens that are used instead of the password. For this to work, the developer needs an application account at Google or Microsoft to obtain a application client ID and secret, which need to saved securely and sent as part of the OAuth2 sign-in. In theory, Google and Microsoft need to approve applications using the account client details, and will give warnings during sign-in after a grace period. If sign-in works, the application receives an access token usually with a life of a few hours, and a refresh token that may be stored securely like a password and may have a life of several months and which may be used to obtain a new access token without a new sign-in. Note the refresh token may be cancelled at any time requiring a new sign-in. The refresh token may also be shared between different applications using the same client details and email account, for instance with servers where interaction is not possible. ICS added support for OAuth2 with version V8.65 in November 2020 to the TSslSmtpCli, TSslPop3Cli and TIcsMailQueue email components, by adding the TIcsRestEmail component to projects with some extra code, as illustrated in the samples OverbyteIcsMailQuTst, OverbyteIcsSslMailSnd and OverbyteIcsSslMailRcv. But the ICS server samples using email were not updated at the time, so have now been done for the forthcoming V8.70 release which is available from SVN and the overnight zip, OverbyteIcsSslMultiWebServ, OverbyteIcsDDWebService and OverbyteIcsSslMultiFtpServ. Since other developers may similarly need to add OAuth2 support for email applications, this is a quick guide. 1 - For the TSslSmtpCli, TSslPop3Cli or TIcsMailQueue component, add an onOATokenEvent handler. 2 - Drop a TIcsRestEmail component named IcsRestEmail and add onEmailNewTokenEvent and onEmailProgEvent handlers. The LoginTimeout property defines how long the component will wait for an interactive browser OAuth2 login, if necessary, defaulting to 30 seconds. If this happens the onEmailNewTokenEvent is called allowing the application to save the new refresh token to avoid further interaction. 3 - In the onOATokenEvent event, call the IcsRestEmail.GetNewToken method and set the handler properties Token, TokExpireDT and TokAccount, see any of the samples. 4 - Set the IcsRestEmail component properties RestEmailType, ClientId, ClientSecret, and RefrToken, there is a function IcsLoadRestEmailFromIni that does this from an INI file for the server samples (without encryption). 5 - Set SMTP AuthType to smtpAuthXOAuth2 or POP3 AuthType to popAuthXOAuth2 with the appropriate host. This causes onOATokenEvent to be called when an access token is needed. Angus

That can be simplified: Application.ShowMainForm := (Pos('-NOSHOW', UpperCase(CmdLine)) = 0); Or: Application.ShowMainForm := not FindCmdLineSwitch('NOSHOW'); I wouldn't even bother calling Terminate() and Run() in that case, just exit immediately instead: begin Application.Initialize; Application.Title := 'Some App'; Application.CreateForm(TfrmMainForm, frmMainForm); if (not frmMainForm.DoLogonScreen) then Exit; Application.Run; end. Or: begin Application.Initialize; Application.Title := 'Some App'; Application.CreateForm(TfrmMainForm, frmMainForm); if frmMainForm.DoLogonScreen then Application.Run; end. Of course, it would be better to not even create the MainForm at all if you are not going to use it, eg: begin Application.Initialize; Application.Title := 'Some App'; if DoLogonScreen then begin Application.CreateForm(TfrmMainForm, frmMainForm); Application.Run; end; end.

As you likely noticed, Delphi 11 officially does not support Windows XP anymore. You can make your application compatible with XP again by simple set. In Project Options|Building|Delphi Compiler|Linking set "Set OS Version fields in PE Headers" and "Set SubSystem Version fields in PE Headers" to "5.1". Unless your application uses System.Threading.pas (TTask etc) you should run it under Windows XP with no problems. But if so, then you have to tweak this unit. Threading objects actually use in their internals new TThread.GetTickCount64 method, which is hardwired to Windows API GetTickCount64 which is not available in Windows XP API. Take this unit from "source\rtl\common" folder in Delphi 11 installation. Declare new local function in the beginning of implementation section of this unit like this: function _GetTickCount64: UInt64; begin if TOSVersion.Major<6 then Result := TThread.GetTickCount else Result := TThread.GetTickCount64; end; and replace all occurrences of TThread.GetTickCount64 calls with _GetTickCount64. For Win32 applications then copy this modified unit to \lib\win32\debug and \lib\win32\release folders in Delphi 11 installation and rename original System.Threading.dcu to e.g. _System.Threading.dcu. Then build your project which uses System.Threading with Debug and Release configuration. New System.Threading.dcu should be created in mentioned folders. After this you should remove modified System.Threading.pas from these folders to prevent its recurrent compilation. Now your Delphi 11 Win32 applications should run under Windows XP with no External Exception crash.

Just on a side note: the RTL has a FindCmdLineSwitch() function in the SyUtils unit: if FindCmdLineSwitch('NOSHOW') then

Although that is technically correct, that has no bearing on this issue. Skrim is able to send emails in general, so they already have valid authentication. The issue is just that some of the emails are being rejected while others are not. That has nothing to do with authentication.

It happens in Delphi 10.3 and above. I suspect something in the VCL style drawing of the hint text.

I watched the sneak peak webinar and Marco mentioned that apps would no longer run on XP and also described the workaround in the original post here. So yes, this is intentional, and submitting a QP report would be kind of pointless. However, if you want there to be one you could do it yourself, rather than ask somebody else to do it.

There's too many "should run" in there. Neither the IDE, nor the produced Win32 binaries are intended to be run on Windows XP, MS-DOS or Enigma. Is there a guarantee it will run on those platforms, just by not importing GetTickCount64? That just doesn't sound safe enough to promise my customers the same.

They explicitly don't want to keep on supporting these old versions. Why? Emba have done all this intentionally.