🚀 go-pugleaf

"BrianV" <bvanmatre_remove_@yahoo.com> wrote in message 
news:47bf8bb4$1@newsgroups.borland.com...

> I'm using indy 10.1.5, the version that ships with C++ Builder 2007.

Then you are using an outdated version of Indy.  What shipped with BCB 2007 
(and 2006, for that matter) was NOT the latest version of Indy.

> First off, the definitions of utUseExplicitTLS, utUseImplicitTLS, 
> utUseRequireTLS, and utNoTLSSupport aren't very clear to me.
> Can someone explain in any detail what these options would be
> used for

utUseExplicitTLS = SSL/TLS is not automatically enabled when the connection 
is initially opened.  The protocol being used must expose an explicit 
command, such as "STARTTLS" or "STLS", that the component can send to the 
server to begin negotiating a new SSL/TLS session when it is ready to do so, 
such as before sending sensitive information (username/password, etc).  If 
the protocol does not expose such a command that Indy recognizes, the 
component triggers its OnTLSNotAvailable event, allowing you to decide 
whether to continue using an unsecure connection or not.  If no event 
handler is assigned, or it returns False, then the connection is closed and 
an exception is raised.

utUseImplicitTLS = SSL/TLS is enabled at the very beginning when connecting 
to a dedicated SSL/TLS-enabled port on the server.  No explicit SSL/TLS 
command is used in the protocol to begin a new secure session, as it must be 
established before the first protocol-level command can be issued.  If the 
port does not support SSL/TLS, the connection fails and an exception is 
raised.

utUseRequireTLS = This is effectively the same as utExplicitTLS, with one 
difference - the component is not allowed to continue with an unsecure 
connection if an SSL/TLS session fails to be established.  The 
OnTLSNotAvailable event is not triggered.  The connection is immediately 
closed and an exception is raised.

utNoTLSSupport = TLS is disabled, and the connection is used normally and 
unsecured.

> Also, the implementation is confusing as well.  In my
> version of Indy, the code that sets these options looks like
> (in IdExplicitTLSClientServerBase.pas, line 399):

You are only looking at a small piece of the puzzle.  The UseTLS property is 
not handled by TIdExplicitTLSClient alone.  Each descendant component uses 
the UseTLS property differently than other components.  They also override 
the SupportsTLS property getter in order to verify protocol-specific 
conditions.

> If you set the value to utUseRequireTLS, then, the code changes
> your Port value to FRegularProtPort (which is defined as 25) at
> point A.

See my explanation above about how utUseRequireTLS and utImplicitTLS differ. 
That will explain why TIdExplicitTLSClient has to swap the ports around.

> Further, the behavior of this method is dependent on the order in
> which you call things. For example if you set your port first, it will
> get changed to 25.  If you set your port after setting TLS option, it
> stays the same.

The Port property is the definitive authority over where the connection 
ultimately connects to.  You can set it after setting the UseTLS property 
and it will override accordingly.  RFCs for standardized protocols dictate 
what the default Port values are.  The UseTLS setter uses those values 
internally (via the FRegularProtPort and FImplicitTLSProtPort members) if 
you have not overriden the Port property value beforehand.

> If anyone has been able to get a TIdSMTP component in indy 10
> to work right with the TLS options, I'd love to hear of any tricks.

See above.


Gambit