我应该期望Indy Imap SASL连接能够正常工作吗?

7
在我的电子邮件检查程序中,我同时支持POP3 SSL和IMAP SSL。虽然POP3 SSL使用SASL已经运行了一段时间,但我从未让使用SASL的IMAP SSL正常工作过,尽管SASL代码在POP3和IMAP之间应该非常相似。我的理解是,在修复此问题之前,我不应该期望它能正常工作。好吧,这个问题已经解决了,所以我想再次尝试使SASL适用于IMAP。我已经更新和重建了Indy,并取消注释了所有的SASL代码,现在我发现当我发出登录命令时,我在IdIMAP4中得到了读取超时(即使将超时设置为足够长的时间(大约20-30秒左右),大约比使用SASL进行身份验证要花费的时间长5倍)。通过调试器逐步执行代码,看起来导致读取超时的行是函数function PerformSASLLogin_IMAP(ASASL: TIdSASL; AEncoder: TIdEncoder;中的第1358行:
AClient.SendCmd(AClient.NewCmdCounter, 'AUTHENTICATE ' + String(ASASL.ServiceName), [], True); {Do not Localize} 

考虑到整个方法是在那个错误报告中指示的修订版中新出现的,我非常确定我已经成功更新了Indy,并且我设置SASL机制等逻辑与POP3非常相似(除了使用IMAP AuthType iatSASL而不是Pop3 AuthType patSASL之类的事情)。那么为什么我在这里会得到读取超时?我怎样才能排除是我的代码还是Indy本身出了问题呢?如果我将IMAP.AuthType更改为iatUserPass或DEF_IMAP4_AUTH,连接就会成功。除了暗示错误报告已关闭之外,我似乎找不到有关我是否应该期望IMAP中的SASL正在运行的最新信息。

编辑: 针对Remy在他的回复中提出的问题,以下是Wireshark捕获的TCP对话记录,当我将其设置为不使用SSL连接SASL时:

* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
C1 CAPABILITY
* CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS QUOTA STARTTLS AUTH=PLAIN AUTH=LOGIN
C1 OK Capability completed.
C2 AUTHENTICATE PLAIN
+
C3 LOGOUT
C2 NO [ALERT] Invalid base64 data in continued response
1个回答

5
据我所知,TIdIMAP SASL现在运行良好(考虑到我是实现它的人)。我没有访问任何使用SASL的IMAP服务器,因此我无法自己测试它,但这是过去几个月中存在的修复实现以来我第一次听到有关它的任何问题。
然而,如果没有看到实际的套接字流量,就无法知道服务器是否发送了任何回复,或者TIdIMAP是否只是没有正确读取回复。您能否提供命令/响应的实际日志记录?可以使用数据包嗅探器(如Wireshark),也可以将Indy的一个TIdLog...组件附加到TIdIMAP.Intercept属性上。
更新:这是TIdIMAP4.GetInternalResponse()中的一个错误。它没有正确处理+行。我已经在Indy的SVN中检查了一个修复程序。

OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot准备就绪。C1 CAPABILITY
  • CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS QUOTA STARTTLS AUTH=PLAIN AUTH=LOGIN
C1 OK Capability completed.C2 AUTHENTICATE PLAIN
C3 LOGOUTC2 NO [ALERT] 在连续响应中发现无效的base64数据。
- Jessica Brown
啊,那太难读了,我会编辑这个问题,把它格式化。 - Jessica Brown
通过将 IMAP 和 SASL 以及 POP3 和 SASL 进行比较,似乎缺少的是客户端未发送密码。 - Jessica Brown
问题在于TIdIMAP4.SendCmd()没有正确处理+行,因此它忽略了该行并尝试读取另一行,而实际上服务器并没有发送该行,因此出现了超时。我正在研究原因。 - Remy Lebeau
已经检查了一个错误修复。在使用提供的捕获进行测试时,SASL身份验证现在可以正常工作。 - Remy Lebeau
那个错误修复似乎起了作用。有了那个更新,我现在可以在IMAP连接上使用SASL进行身份验证了。 - Jessica Brown

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接