我目前正在尝试编写一个简单的Spring电子邮件验证微服务。我正在使用Apache SMTPClient API连接到SMTP服务器，并验证电子邮件地址是否存在(连接->登录->setSender->setRecipient->注销->断开连接)。当连接到大多数大型电子邮件提供商(gmail、雅虎等)时，没有问题，但对其他人来说，连接时会出现奇怪的5-20s延迟。例如，使用protonmail时，我有时会等待5秒的固定延迟，有时会在约150毫秒后正常连接。对于其他一些较小的服务，每次我尝试连接时都会有固定的延迟。由于我正在尽我所能减少此类验证所需的时间，这是一个相当大的问题，因为它通常需要<2s，当没有遇到此类问题时。
我试图找到延迟的原因，我遇到了两个潜在的解释：
- tarpitting-虽然它造成的延迟符合问题，但我正在发送一个单一的连接请求，而该机制应该防止垃圾邮件/批量电子邮件
- 被列入黑名单——这也可能是原因，但通常情况下，这些信息会被放入对我发送的SMTP命令之一的(否定)回复中
如果有任何关于延迟原因以及如何避免延迟的建议(如果可能的话)，我将不胜感激。
我与mail.protonmail.ch进行了几次SMTP连接，它肯定在做一些不寻常的事情。我认为他们正在实施柏油路的变体。
例如，有时在连接后，mail.protonmail.ch会立即用SMTP横幅(看起来很像220响应)进行响应：
220-mailin008.protonmail.ch ESMTP Postfix
然后，在看似随机的延迟之后，实际的220响应：
220 mailin008.protonmail.ch ESMTP Postfix
其他时候，在看似随机的延迟之后，它会以220响应，而不会首先发送横幅：
220 mailin025.protonmail.ch ESMTP Postfix
许多用于发送垃圾邮件的客户端SMTP程序没有正确实现SMTP。粗制滥造的程序可能会被mail.protonmail.ch的异常响应方式"愚弄"，并在应该发送EHLO之前发送。然后，假设客户端不是"真正的"SMTP MTA，mail.protonmail.ch可以断开连接。然而，真正的MTA会在发送EHLO之前等待"真正的"220响应。
在这种情况下，我可以通过简单地使用套接字来解决问题-如果你所需要做的只是通过发送RCPT TO命令来验证电子邮件的存在性，那么这是最好的方法。我个人找不到任何Java API既能避免的问题，又能方便地发送SMTP命令。