我的postfix服务器和Postini服务器的交付都有问题。Postfix开始报告以下错误:
postfix/smtp[18061]: fatal: watchdog timeout
postfix/qmgr[9746]: fatal: 69B063A536: timeout receiving delivery status from transport: smtp经过大量的调试,我们发现这些消息只发生在发送到postini服务器(*.psmtp.com)的邮件中。使用tcpdump,我们注意到Postini返回'571消息拒绝‘消息,但它只以CR \r (0d)结束,而不是以CRLF \r\n (0d0a)结束。由于linefeed从未由Postini发送,Postfix一直在等待消息的结束。最后,监视狗进程将终止后缀过程并导致上面的错误消息。
这将导致电子邮件停留在“活动”队列中,因此postfix将尝试另一次传递。这会导致后缀实例一次又一次挂起。我们试着安装一个更新的后缀版本(从2.5.5到2.8.3),但这并没有解决问题。当然,Postini有问题,它已经报告给谷歌,但我想知道是否有一个解决方案,后缀,以优雅地处理这一点?
tcpdump对Postini的答复:
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.发布于 2011-10-21 15:32:34
对不起,没有办法解决这个问题。后缀是非常符合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
(i.e., 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.https://serverfault.com/questions/323573
复制相似问题