SMTP Indy组件安全和身份验证属性做什么？ [英] What do the SMTP Indy component security and authentication properties do?

问题描述

我正在使用indy组件在delphi应用程序中实现电子邮件。我专门使用TidSMTP组件。我需要有效地支持所有主要的电子邮件服务器。我使用Mozilla Thunderbird作为我的电子邮件客户端，并将smtp属性与TidSMTP组件中的属性进行比较。我试图找到描述TidSMTP属性之间的关系的文档，但无法弄清楚。

有人可以解释这些比较和他们做什么：

• 在Thunderbird中：连接安全性：（无，STARTTLS，SSL / TLS）

<在tidSMTP.UseTLS（utNoTLSSupport，utUseImplicitTLS，utUseRequireTLS，utUseExplicitTLS）



• 在Thunderbird：验证方法:(无验证，普通密码，加密密码，



• 在TidSMTP（用户名，密码，使用验证方法）中

我也看到其他TidSMTP属性：UseEhlo，UseVerp，UseNagle。我需要使用这些吗？他们做什么？

解决方案

使用 STARTTLS 时，服务器的收听端口在连接时最初未加密。当客户端连接时，如果服务器支持，它可以向服务器发送一个可选的 STARTTLS 命令来动态地执行SSL / TLS握手。这允许传统的非SSL / TLS客户端继续连接到同一端口，同时允许较新的启用SSL / TLS的客户端使用SSL / TLS（如果服务器上可用）。这对应于Indy中的 UseTLS = utUseExplicitTLS 。为了使用 UseTLS = utUseExplicitTLS ，您需要设置 UseEHLO 为 EHLO 命令是如何 TIdSMTP 发现服务器是否支持 STARTTLS 命令。 p>

当使用 SSL / TLS 而不是 STARTTLS 时，服务器监听端口始终使用加密，客户端必须在连接之前立即启动SSL / TLS握手，才能交换任何其他数据。这对应于Indy中的 UseTLS = utUseImplicitTLS 。没有使用 STARTTLS 命令。

对于身份验证， TIdSMTP 有两个选项 - 由原始SMTP规范定义的旧的（和不安全的） AUTH LOGIN 命令，以及基于SASL的散列/加密算法的SMTP扩展（Kerberos ，GSSAPI，NTLM等实现为SASL算法）。

要使用SASL，请将 TIdSMTP.AuthType 设置为 satSASL ，然后填写 TIdSMTP.SASLMechanisms 集合，指向单独的 TIdSASL 衍生的组件，用于您要在应用程序中支持的算法。 Indy具有 DIGEST-MD5 ， CRAM-MD5 ， CRAM-SHA1 ， NTLM （实验）， ANONYMOUS ， EXTERNAL ， OTP ， PLAIN ， SKEY 和 LOGIN （SASL包装器 AUTH LOGIN ）。如果您需要另一种算法（例如，Kerberos或GSSAPI），则必须编写自己的 TIdSASL 衍生组件。对于使用Username / Password的算法，这些值必须分配给单独的 TIdUserPassProvider 组件，然后将其分配给SASL组件（ TIdSMTP.UserName 和 TIdSMTP.Password 属性不与SASL一起使用）。您支持的SASL算法越多，您将能够支持的服务器数量越多。

对于仍然支持 AUTH LOGIN ，可以通过将 TIdSMTP.AuthType 设置为 satDefault （也可以设置 TIdSMTP.ValidateAuthLoginCapability 如果服务器支持 AUTH LOGIN ，但不报告以响应 EHLO 命令），然后填写 TIdSMTP.UserName 和 TIdSMTP.Password 属性，或者在 TIdSMTP.SASLMechanisms 集合中包含 TIdSASLLogin 组件。

UseVerp 和 UseNagle 与安全性无关。 VERP 是一个SMTP扩展，用于检测由于无法投递的错误而导致的弹跳电子邮件。 Nagle是用于优化网络数据包的网络算法。

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?

解决方案

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.

这篇关于SMTP Indy组件安全和身份验证属性做什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！