(05-08-2018, 09:56 AM)johnmay Wrote: This code also causes Socket Error # 10060 Connection timed out
Code:
IdSMTP1->Host = "smtp.charter.net";
IdSMTP1->Port = 25;
IdSMTP1->UseTLS = utUseExplicitTLS;
IdSMTP1->Connect();
And you wrote above that it is OK to use explicit TLS on port 25. Apparently, using code above, it is not.
Yes, it is OK. But you are not actually connecting to port 25, you are really connecting to port 587 instead, and apparently that Charter server doesn't use port 587, it uses port 25 instead, hence the tiimeout error on connect. So again, because you are setting the
Port property to a standardized port 25
before setting the
UseTLS property, the
UseTLS property setter will
change the Port property from 25 to 587 because of
utUseExplicitTLS. You need to swap the order of the assignments:
Code:
IdSMTP1->Host = "smtp.charter.net";
IdSMTP1->UseTLS = utUseExplicitTLS; // <-- do this first
IdSMTP1->Port = 25; // <-- do this second
IdSMTP1->Connect();
Or, use
utNoTLSSupport instead (which is the default):
Code:
IdSMTP1->Host = "smtp.charter.net";
IdSMTP1->Port = 25;
IdSMTP1->UseTLS = utNoTLSSupport;
IdSMTP1->Connect();
(05-08-2018, 09:56 AM)johnmay Wrote: This means that any provider which uses port 25 will now get Connection timed out if SMTP is setup with perfectly valid setup shown above.
No, that is not what it means. The only reason this is failing is because you use are using the
UseTLS property but Charter is not using the standard Explicit TLS port. This is not a problem for most providers, who use standard ports the right way.
(05-08-2018, 09:56 AM)johnmay Wrote: If the order of setup is reversed it works as expected:
Code:
IdSMTP1->Host = "smtp.charter.net";
IdSMTP1->UseTLS = utUseExplicitTLS;
IdSMTP1->Port = 25;
IdSMTP1->Connect();
Only because you are using the
UseTLS property, and Charter is using a non-standard setup on their end. Letting
UseTLS manage the
Port property is OK for MOST providers, who use standard port setups the right way.
(05-08-2018, 09:56 AM)johnmay Wrote: So in other words, now TIdSMTP expects the programmer to issue commands in certain order because it modifies the internal port when UseTLS property is changed.
Yes, and that logic has been in place for a very long time, this is not new functionality. The swapping of implicit and non-implicit ports was implemented well over a decade ago. The swapping of explicit and non-explicit ports was added almost 2 years.
Besides, this only affects protocols that implement standardized ports (and for good reason), it does not affect non-standardized ports.
(05-08-2018, 09:56 AM)johnmay Wrote: I expect that you will receive many more questions about this behavior because the above code which uses both port 25 and explicit TLS is not unusual setup and can be used by a number of providers.
Actually, no. This behavior has been in place for a long time, and I've had very few questions on it, because it "just works" for most people. It is the people that run into special situations that end up asking questions, and that has been few. Also, port 25 is deprecated anyway, most providers that support explicit TLS use port 587 instead (as they should be), and that is what most 3rd party email software expect. So again, swapping port 25 with port 587 when enabling explicit TLS "just works" for most people.
Why Charter is not following standard rules, I have no idea. But as I have explained, there is a workaround available to handle their non-standard behavior. You are not the first person to need to use it, and you probably won't be the last, but the situations that need it are few and far apart.
(05-08-2018, 09:56 AM)johnmay Wrote: I made a change by setting port later and now my code works back as expected so thank you for pointing that out. But the problem here is having some assumptions about server setup and I'll explain some of the cases below why these assumptions should not be made:
Thank you. But I'm not changing Indy's behavior at this point. The current behavior was added for a reason, and it serves its purpose well under normal conditions. Charter doesn't want to play by the same rules that everyone else follows, then they should expect to break someone's code along the way.
(05-08-2018, 09:56 AM)johnmay Wrote: - Some providers don't use standard setup and I've seen the cases of port 80 and 2525 being used for outgoing port.
And those are perfectly fine, and the
UseTLS property setter will not change the Port property in those cases. It is only STANDARD PORTS that get changed around (for SMTP, ports 25, 465, and 587 only).
(05-08-2018, 09:56 AM)johnmay Wrote: From my perspective, the TIdSMTP component should accept parameters in any order before you actually connect.
And for the most part, it does. But Ports are a specific use case, and they need to follow certain rules. If you don't like the outcome, just overwrite the result.
If you don't like what Indy does, feel free to change it. The
UseTLS property setter is virtual, you can override it to bypass the
Port swapping logic if you want. There is a reason why all of Indy's internal data members are declared as
protected instead of
private, and why a good deal of its class methods are
virtual - user customization.