套接字之间的双工pipe道似乎在SMTP后面的NAT后面继续TLS,但有时只是

这是设置:

[Proxy/Relay Server] <---------[(SMTP TLS test client) Test server] ^ | (Internet) v --------------+----------------- | [Router] | | [ Home email appliance machine | (Home email server app (Node.js)) | (Postfix) ] 

所以这个小小的服务器就在家里的NAT后面。 使用外部服务器作为IMAP和SMTP的代理/中继。

  1. 家庭电子邮件设备应用程序连接到互联网上的代理/中继服务器。
  2. 家庭电子邮件设备应用程序连接到本地主机上的SMTP Postfix端口。
  3. 家庭电子邮件应用程序在两个连接之间创build一个双向pipe道。
  4. 从Internet上的testing服务器上,将支持TLS的SMTP客户端连接到代理/中继服务器。
  5. 代理/中继服务器在代理连接和来自家庭电子邮件设备的预先存在的连接之间传输数据。
  6. SMTP客户端执行STARTTLS协议。
  7. 家庭电子邮件设备应用程序通过pipe道在代理/中继和本地主机SMTP之间传输数据,以通过TLS执行SMTP。

我们使用openssl s_client来testing到代理/中继服务器的TL连接,该服务器将数据来回发送到NAT后面的客户端。

它对于纯文本非常有效,但是我不确定它是否对TLS始终如一的工作。 偶尔我会从openssl s_client命令中得到一个完整的输出,带有SSL证书等等,但通常它只是说CONNECTED并且在那里。 不知道这是在这种情况下工作。

基本上它的这个代码运行在具有Postfix的计算机上的NAT(路由器)后面(有一些安全的东西,但基本上是这样):

 proxyOutgoing = net.connect(proxyport, proxyhost) localSMTP = net.connect(587, 'localhost') localSMTP.pipe(proxyOutgoing).pipe(localSMTP) 

我想知道的是,是否有这样的基本思想,会导致openssl s_clienttesting或TLS在一般情况下似乎只是偶尔“工作”? 我需要以某种方式冲刷pipe道或奇怪的东西..它一直说连接(000003),但通常只是,没有证书信息。

一个理论是tlsmgr正在caching会话,这是为什么我没有看到STARTTLS的东西,因为它已经成立。

感谢任何有评论或想法的人。

答案基本上是第2步需要在第4步之后,否则不会收到来自本地SMTP / IMAP服务器的初始响应,而且由于STARTTLS协议testing客户机正在等待连接的标准问候,所以它们不起作用。 起初,本地邮件服务器早期连接的原始顺序似乎正在工作,因为纯文本SMTP命令经过后期,但通常客户端希望在连接时收到某些消息。