Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
A bug in new version of Indy in TIdSMTP
#3
Actually the problem is deeper than that.

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. I thought it was exception issue but the exception is not the problem here but now when I understand what is going on here the UseTLS parameter logic is the problem - there is more to this but I'll get to that later.

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. 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();

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. 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.

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:

- With regard to Charter.net - I know that they should be using explicit TLS on port 587. I agree with you on that. Problem is they don't. Now, I cannot just go and complain to them because I am not even their user - but they have probably hundreds of thousands of users. Maybe if I complain to them they would change that. Maybe that initial setup was done by incompetent administrator by mistake. But now after years have passed, they have a problem - they have to explain to hundreds of thousands of (technically challenged) users what the correct setup of ports should be and what is implicit and explicit TLS. The users will have no idea what explicit TLS is, they don't even know what TLS is. That is why they probably won't do it in the first place and the non-standard setup of port + implicit TLS will remain there. This is a real world scenario as opposed to idealistic scenario. Thus, any Indy programmer will have similar issue if they have to deal with Charter.net SMTP server.

- Some providers don't use standard setup and I've seen the cases of port 80 and 2525 being used for outgoing port. Sometimes this is used to avoid antiviruses blocking port 25. So any assumptions that certain ports should be used with certain setups here too falls apart.

- Take an example of a user having a local antivirus which requires the user to modify the port and then uses implicit TLS (locally) to scan for viruses before sending to servers. This is not a random example, some antiviruses really work like that. In such case it is not safe to assume that certain ports or explicit/implicit connection would be used. It can be any combination and SMTP component should be able to accept any combinations of parameters (within the valid port ranges that is).

From my perspective, the TIdSMTP component should accept parameters in any order before you actually connect. Only then parameters can be fixed. But by having this change to modify port when setting UseTLS you mislead the programmer into thinking he/she has set the port to their specification when in reality Indy has modified the port after changing UseTLS. In fact, in my own code I logged the connection to port 587, when in reality Indy was using port 465. Or in case of port 25, it would use port 587 instead using first piece of code shown above. That code logic is a bit flawed (and I don't mean this as criticism, just a constructive suggestion). If you don't want programmers to set parameters in any order then use Connect() with parameters. Then they can set it only in 1 order and no combinations or possible coding errors will occur.
Reply


Messages In This Thread
RE: A bug in new version of Indy in TIdSMTP - by johnmay - 05-08-2018, 09:56 AM

Forum Jump:


Users browsing this thread: 1 Guest(s)