gpt4 book ai didi

email - 正确响应 SMTP HELO

转载 作者:行者123 更新时间:2023-12-04 22:42:39 24 4
gpt4 key购买 nike

以下是 SMTP 事务示例的开始教科书计算机网络(第6国际版):

S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you

S:前缀表示是服务器发送的一行,C:表示是客户端发送的一行。维基百科页面 SMTP有一个SMTP对 HELO 有类似响应的示例。

服务器对 HELO 的响应是否符合规范? RFC 5321指定服务器对 HELO/EHLO 的响应:

ehlo-ok-rsp    = ( "250" SP Domain [ SP ehlo-greet ] CRLF )
/ ( "250-" Domain [ SP ehlo-greet ] CRLF
*( "250-" ehlo-line CRLF )
"250" SP ehlo-line CRLF )

根据我对规范的理解,上面例子中服务器的响应应该是

250 hamburger.edu

也就是说,它应该用 250 后跟它自己的主机名而不是客户端的主机名,当然不是显示的任意问候消息在示例中。

HELO 的正确响应是什么?计算机网络示例不正确吗?

最佳答案

简短的回答

由于 250 之后的杂散 Hello,该示例无效。但是.. 这可能并不重要。

长(呃)答案

首先让我们看一下客户端“HELO”的语法:

"HELO" SP Domain CRLF

客户端发送 HELO 后跟一个空格,然后是他的域名,然后是 CRLF。我怎么知道它是客户域?嗯:

The argument clause contains the fully-qualified domain name of the SMTP client, if one is available

现在响应:

ehlo-ok-rsp = ( "250" SP Domain [ SP ehlo-greet ] CRLF ) / ( "250-" Domain [ SP ehlo-greet ] CRLF *( "250-" ehlo-line CRLF ) "250" SP ehlo-line CRLF )

这里有两个选项:

  1. “250”SP 域 [SP ehlo-greet] CRLF
  2. ( "250-"域 [SP ehlo-greet] ...

它们都不适合,因为域名是预期的,而不是我们看到的 Hello

下面的 ehelo-greet 部分很好。 RFC 的下一页对此进行了解释:

ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127) ; string of any characters other than CR or LF

因此它可以是任何不包含\r\n 的字符串。字符串 , pleased to meet you 显然属于这一类。

为什么没关系

综上所述,请注意示例无效这一事实并不意味着它在实践中不会发生,或者发送此类示例的服务器无法正常工作。理论和实践是有区别的。例如,如果我们查看 Java 的官方 JavaMail ,在 SMTPTransport.java 的第 1662-1665 行,我们找到以下代码:

if (first) {    // skip first line which is the greeting
first = false;
continue;
}

这来自名为 ehlo(String domain) 的方法,该方法处理发送和接收 HELO 命令。 JavaMail 跳过了整个问候语,我怀疑其他客户端也可能这样做。

关于email - 正确响应 SMTP HELO,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/40059025/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com