Recomnended Email and Webserver Components

[Trow23 0]

Currently have a product programmed using Delphi 2010.  Have used Indy components to provide email sending and receiving and a webserver  In recent years its getting more difficult to support email services and from what I can tell Indy does not support the likes of two factor authntication like gmail.  Also the Webserver components don't seem very well supported for the latest SSL.  This could be because I have not found a suitable site that hosts up to date indy components.

 

If Indy is no longer supported what components would provide similar up to date functionality for use on a Windows 10/11 platform.

 

Thanks for any help.

[mjustin 19]

Regarding support for the latst TLS/SSL, TLS 1.3 is not included in the trunk version of Indy, but there is a pull request which adds TLS 1.3 support (see https://github.com/IndySockets/Indy/pull/299). Other options to enable 1.3 are available by attaching a commercial SSLHandler.

 

Regarding GMail: two-factor authentication input is usually performed using the system browser. Indy's HTTP server is not involved in this step. Maybe you can be more specific what you are missing in Indy?

 

Indy is definitely still supported, and included in all versions of Delphi and working on Windows 10/11. You may download it from GitHub: https://github.com/IndySockets/Indy

 

p.s. regarding TLS/SSL webservers: you may place the (Indy-based) HTTP server behind a reverse proxy such as nginx or Apache HTTPD. The reverse proxy will do all the encryption work, while Indy still only uses HTTP. The reverse proxy must be configured so the clients will communicate with the proxy only. This has many advantages (think of automated certificate renewal for Let's Encrypt).

 

 

[esegece 46]

If you need to send gmail authentication using OAuth2 you can try this open source project which implements this type of authentication using the Indy components:

 

https://github.com/geoffsmith82/GmailAuthSMTP/blob/master/README.md

 

Additionally, I offer a commercial product called sgcWebSockets that includes support for Indy servers with support for HTTPs with the latest openSSL using a custom library with support for the latest TLS 1.3 (openSSL 1.1.1 and 3.0.0). OAuth2 authentication is also supported on server and client components, Indy IOCP Server for high performance servers... and much more features, you can check in the following link:

 

https://www.esegece.com/websockets

 

Kind Regards,

Sergio

[Fr0sT.Brutal 897]

ICS does all that and even includes login form using a browser

[Trow23 0]

Thank you for your replies.  I will check them out.

 

regards

 

Viv

[FPiette 367]

18 hours ago, Trow23 said:

what components would provide similar up to date functionality for use on a Windows 10/11 platform.

ICS (Internet Component Suite) will do everything you ask. ICS is freeware with full source code. If you need help for using ICS, there is a dedicated forum on this website : https://en.delphipraxis.net/forum/37-ics-internet-component-suite/

[Remy Lebeau 1260]

On 1/29/2023 at 8:20 AM, Trow23 said:

from what I can tell Indy does not support the likes of two factor authntication like gmail.

Indy does not implement OAuth at this time, that is true.  There are open tickets for adding that feature.  However, Indy does work fine with GMail if you enable 2FA and use an app-specific password.

On 1/29/2023 at 8:20 AM, Trow23 said:

Also the Webserver components don't seem very well supported for the latest SSL.

Indy has WIP support for OpenSSL 1.1+/TLS 1.3 in this GitHub pull request: https://github.com/indySockets/indy/pull/299

On 1/29/2023 at 8:20 AM, Trow23 said:

This could be because I have not found a suitable site that hosts up to date indy components.

Indy's official GitHub repo has the latest version: https://github.com/IndySockets/Indy/

On 1/29/2023 at 8:20 AM, Trow23 said:

If Indy is no longer supported

Indy is still supported (by me).  Though, development of new feature for it tends to be a bit on the slow side, for a number of reasons, namely that I'm a sole developer, I don't have a lot of free time, I don't have a working IDE right now, etc etc etc.  However, Indy is open-source, users are always free and encouraged to submit new code.  Most don't, though.

[Fr0sT.Brutal 897]

13 hours ago, Remy Lebeau said:

However, Indy is open-source, users are always free and encouraged to submit new code.  Most don't, though.

Plz don't take as offense or criticism, but one user have done the big ready-to-merge PR almost 3 years ago that is still pending 🙂

[Remy Lebeau 1260]

9 hours ago, Fr0sT.Brutal said:

Plz don't take as offense or criticism, but one user have done the big ready-to-merge PR almost 3 years ago that is still pending 🙂

None taken,  and yes, there are several PRs that have been pending for too long.  But, during that time, there have also been several other user-submitted PRs and non-PR changes alike that have been merged.  So, it is not like I'm ignoring everything that gets submitted to me.

 

Regarding the PRs that are still pending, most of them were not ready-to-merge as-is at the time they were submitted, which is why I didn't just blindly merge them.  Looking at them now, I can probably merge the smaller ones soon, but if the "big" PR you are referring to is the OpenSSL 1.1+ one, that is a HUGE PR to merge - 246 changed files, and 200 comments/commits trying to iron out its issues.  I haven't reviewed its code in full yet.

Edited January 31, 2023 by Remy Lebeau

[Fr0sT.Brutal 897]

13 hours ago, Remy Lebeau said:

that is a HUGE PR to merge

Yeah, I looked at it yesterday and was shocked. Probably that's because the author made completely separate engine? Updating existing OpenSSL engine to new version shouldn't touch so much code.

[Remy Lebeau 1260]

13 hours ago, Fr0sT.Brutal said:

Yeah, I looked at it yesterday and was shocked. Probably that's because the author made completely separate engine?

Yes.

13 hours ago, Fr0sT.Brutal said:

Updating existing OpenSSL engine to new version shouldn't touch so much code.

Unfortunately, it still would have been a big update, since OpenSSL basically redesigned their API in v1.1.0.  All of the structures were changed, and many functions were either renamed or dropped.  So, while making the existing SSLIOHandler component be more version-aware to support both pre-1.1.0 and post-1.1.0 libraries would have been ideal, the API changes really warranted new SSLIOHandler components to keep the two API designs separate.  But, to be fair, I wasn't involved in the development of the new components, so I couldn't say if the new design is actually overkill or not.

[Fr0sT.Brutal 897]

Well, probably older OpenSSL support should be dropped then. Unless they abandon some env's (like Win7) I doubt anyone wants to stick to older version

[Remy Lebeau 1260]

8 hours ago, Fr0sT.Brutal said:

Well, probably older OpenSSL support should be dropped then.

I'm aware of that. Though, there are still environments that do use old versions. And Indy does still support old compilers for now.  Indy 11 will drop the old compilers, so maybe at that time, or maybe in Indy 12, we'll drop old OpenSSL, too

[Fr0sT.Brutal 897]

My point was that updating OpenSSL libs is far not so painful than updating to a newer compiler or env (unless OpenSSL drops support of old env's).