我在使用Postfix服务器时遇到了与Postfix服务器结合的问题。 Postfix开始报告以下错误：
postfix/smtp[18061]: fatal: watchdog timeout postfix/qmgr[9746]: fatal: 69B063A536: timeout receiving delivery status from transport: smtp 经过大量的时间debugging，我们发现这些消息只发生在邮件发送到postini服务器（* .psmtp.com）。 使用tcpdump，我们注意到Postini返回'571消息被拒绝'的消息，但它仅以CR \ r（0d）而不是以CRLF \ r \ n（0d0a）结束。 由于换行从不由Postini发送，Postfix一直在等待消息的结束。 最后，看门狗进程将终止后缀处理并导致上面的错误消息。
这会导致电子邮件停留在“活动”队列中，因此postfix将尝试另一个传送。 这会导致一个后置的实例会一直重复。 我们尝试安装一个较新的后缀版本（从2.5.5到2.8.3），但没有解决问题。 当然，Postini已经向Google报告了一些问题，但是我想知道是否有一个解决scheme可以让postfix优雅地处理这个问题？
Postini响应的tcpdump：
10:31:56.889372 IP 207.126.154.12.25 > xx.xx.xx.xxx.40923: P 263:283(20) ack 13624 win 8544 <nop,nop,timestamp 1885723084 20871864> 0x0000: 4500 0048 8faa 4000 3b06 91e1 cf7e 9a0c E..H..@.;....~.. 0x0010: 5511 5f88 0019 9fdb 2897 59cb 02d2 3032 U._.....(.Y...02 0x0020: 8018 2160 9d93 0000 0101 080a 7065 d9cc ..!`........pe.. 0x0030: 013e 7ab8 3537 3120 4d65 7373 6167 6520 .>z.571.Message. 0x0040: 5265 6675 7365 640d Refused.
对不起，没有解决方法。 后缀是非常符合RFC，并坚持要收到正确的答复。
有一些方法可以将回复重写为完全不同的东西，但是对于这个回复则必须实际发生。 在你的情况下没有答复（在Postfix和RFC 5321眼中），所以发生超时。
为了完整起见，RFC 5321第2.3.0节的摘录：
Lines consist of zero or more data characters terminated by the sequence ASCII character "CR" (hex value 0D) followed immediately by ASCII character "LF" (hex value 0A). This termination sequence is denoted as <CRLF> in this document. Conforming implementations MUST NOT recognize or generate any other character or character sequence as a line terminator. Limits MAY be imposed on line lengths by servers (see Section 4). In addition, the appearance of "bare" "CR" or "LF" characters in text (ie, either without the other) has a long history of causing problems in mail implementations and applications that use the mail system as a tool. SMTP client implementations MUST NOT transmit these characters except when they are intended as line terminators and then MUST, as indicated above, transmit them only as a <CRLF> sequence.