What do the SMTP Indy component security and authentication properties do?
delphi, indy, smtp
Solution
When using `STARTTLS`, the server's listening port is initially unencrypted upon connecting. When a client connects, it can send an optional `STARTTLS` command to the server, if the server supports it, to dynamically perform the SSL/TLS handshake at that time. This allows legacy non-SSL/TLS clients to continue connecting to that same port, while allowing newer SSL/TLS-enabled clients to use SSL/TLS if available on the server. This corresponds to `UseTLS=utUseExplicitTLS` in Indy. You need to set `UseEHLO` to True in order to use `UseTLS=utUseExplicitTLS`, as the `EHLO` command is how `TIdSMTP` discovers whether the server supports the `STARTTLS` command or not.
When using `SSL/TLS` instead of `STARTTLS`, the server's listening port is always using encryption and the client must initiate the SSL/TLS handshake immediately upon connecting before any other data can be exchanged. This corresponds to `UseTLS=utUseImplicitTLS` in Indy. There is no `STARTTLS` command used.
For authentication, `TIdSMTP` has two options - the old (and unsecure) `AUTH LOGIN` command that is defined by the original SMTP spec, and SMTP extensions for SASL-based hashing/encryption algorithms (Kerberos, GSSAPI, NTLM, etc are implemented as SASL algorithms).
To use SASL, set `TIdSMTP.AuthType` to `satSASL` and then fill in the `TIdSMTP.SASLMechanisms` collection to point at separate `TIdSASL`-derived components for the algorithms you want to support in your app. Indy has native SASL components for `DIGEST-MD5`, `CRAM-MD5`, `CRAM-SHA1`, `NTLM` (experimental), `ANONYMOUS`, `EXTERNAL`, `OTP`, `PLAIN`, `SKEY`, and `LOGIN` (SASL wrapper for `AUTH LOGIN`). If you need another algorithm (Kerberos or GSSAPI, for instance), you will have to write your own `TIdSASL`-derived component. For algorithms that use Username/Password, the values must be assigned to a separate `TIdUserPassProvider` component that is then assigned to the SASL components (the `TIdSMTP.UserName` and `TIdSMTP.Password` properties are not used with SASL). The more SASL algorithms you support, the wider the number of servers you will be able to support.
For servers that still support `AUTH LOGIN`, it can be used either by setting `TIdSMTP.AuthType` to `satDefault` (and optionally setting `TIdSMTP.ValidateAuthLoginCapability` to False if the server supports `AUTH LOGIN` but does not report it in response to the `EHLO` command) and then filling in the `TIdSMTP.UserName` and `TIdSMTP.Password` properties, or by including the `TIdSASLLogin` component in the `TIdSMTP.SASLMechanisms` collection.
`UseVerp` and `UseNagle` have nothing to do with security. `VERP` is an SMTP extension for detecting bouncing emails due to undeliverable errors. Nagle is a networking algorithm for optimizing network data packets.
Problem
I am using the indy components to implement emails in a delphi application. I am specifically using the TidSMTP component. I need to effectively support all major email servers. I use Mozilla Thunderbird as my email client and am comparing the smtp properties with those in the TidSMTP component. I have attempted to find documentation that describes the relationship between the TidSMTP properties, but have not been able to figure it out. Can someone explain how these compare and what they do: - In Thunderbird:Connection Security: (None, STARTTLS, SSL/TLS). In TidSMTP.UseTLS (utNoTLSSupport, utUseImplicitTLS, utUseRequireTLS, utUseExplicitTLS) In Thunderbird:Authentication method: (No Authentication, Normal Password, Encrypted Password, Kerberos/GSSAPI, NTLM) - In TidSMTP (username, password, with useAuthentication method) I also see other TidSMTP properties: UseEhlo, UseVerp, UseNagle. Do I need to be using these? What do they do?