标题: 服务器响应,'451 qq trouble creating files in queue (#4.3.0),该怎么解决？ [打印本页] 作者: xlong 时间: 2004-7-20 20:15 标题: 服务器响应,'451 qq trouble creating files in queue (#4.3.0),该怎么解决？ 我在清除队列时，没有停止QMAIL，发邮件时出现这样的提示：<br>
出现未知错误。 主题 'test', 帐户: '172.16.1.4', 服务器: '172.16.1.4', 协议: SMTP, 服务器响应: '451 qq trouble creating files in queue (#4.3.0)', 端口: 25, 安全(SSL): 否, 服务器错误: 451, 错误号: 0x800CCC6A；<br>
该怎么解决？<br>
谢谢！作者: samfan 时间: 2004-7-21 18:00 标题: Re:服务器响应,'451 qq trouble creating files in queue (#4.3.0),该怎么解决？ 进入编译前源文件目录，make setup check即可<br> 作者: samfan 时间: 2004-7-21 18:02 标题: Re:服务器响应,'451 qq trouble creating files in queue (#4.3.0),该怎么解决？ 提供你一个国外的做法，具体差不多。不过更具体点：<br>
Your queue structure is clearly seriously messed up.<br>
<br>
Stop qmail, then move /var/qmail/queue to /var/qmail/badqueue and<br>
reinstall ("make setup check").<br>
<br>
Then have a look at the messages in the badqueue directory. Read the<br>
INTERNALS file, noting among other things that files under the mess<br>
subdirectory must have an inode number equal to their name. Did you<br>
perhaps violate this by restoring a queue from backup, for example?<br>
If so, messages need renumbering before you can move them back in the<br>
queue. Also, if queue files had their ownership changed, that must be<br>
fixed. The mess/*/* files should have owner qmailq, while ones under<br>
info/, local/, and remote/ should be owned by qmails.<br>
<br>
You may find it easier to just reinject messages in the queue based on<br>
what is in the info (envelope sender) and local and remote files. The<br>
qmail-queue man page explains what is needed; what goes to file<br>
descriptor 1 is the concatenation of the info file, then the remote<br>
and local files, with an extra NUL byte appended.<br>
<br>
Oh, actually, that would resend messages that were already<br>
delivered. Try instead the output of<br>
<br>
( cat info/$msg remote/$msg local/$msg | tr '\000' '\012'; echo ) |<br>
grep '^[FT]' | tr '\012' '\000'<br>
<br>
"Some assembly required." (No, not assembly *language*.)<br>
<br>
The latter approach has the advantage that you can restart the queue<br>
without waiting to stuff messages from the old queue into the new one.<br>