当sendmail守护进程收到一个kill -15（SIGTERM）请求时，它做了什么？ 这如何影响传输中的消息？

Sendmail和所有其他正确编写的MTA都是这样编写的，所以只有两种可能性：

1. 该消息首先写入磁盘，然后确认发送MTA
2. 该消息未被确认

用这种方法，发生错误时有三个结果：

1. 在接收sendmail试图确认之前发生错误。 发送方重试。
2. 发送错误发生在收到的sendmail已经尝试确认之后，但在发送方收到确认之前。 如果确认包在networking上丢失，这基本上就会发生。 发送方重试，但接收方将处理邮件。 该消息将被复制。
3. 发送方收到确认后会发生错误。 接收方有责任正确处理邮件。

因此，故障模式是“故障安全”的：如果发送方不能确定消息的责任是否已成功传送给接收方，则它将再次发送，即使这可能导致邮件的重复收件人的收件箱。

消息可能丢失的唯一情况是服务器发生严重故障（磁盘故障或机器永久丢失），而邮件负责。

我刚刚在sendmail 8.14.9上进行了testing，当我执行一个/etc/init.d/sendmail stop，在这台机器上执行killall ${SENDMAIL_HOME}/bin/sendmail ，发送kill -15正在询问，目前在DATA阶段传入的邮件被中止。 TCP会话由服务器closures。

在这台机器上， restart是通过stop ; start来实现的stop ; start stop ; start ，所以你的问题的答案是，不，重新启动不是优雅的，但是（当然） ，只要它们被SMTP发送或符合RFC标准的实现，就不会丢失邮件。

这听起来像是永远不会发生，但是（比方说）使用一些SMTP邮件库发送到他们的智能主机的PHP或Java应用程序将收到一个错误，然后由该应用程序再次发送邮件。 扰码警报：通常不会，但效果与邮件服务器在尝试发送时已closures的效果相同。

我喜欢@ Law29的回应，并可能select它作为这个问题的最佳答案。 这就是说，如果有人在这篇文章中绊倒，这里是蝙蝠本书的权威答案 ：

SIGTERM

清理并退出sendmail信号。

每当sendmail收到一个SIGTERM信号（如果系统正在closures的话），它会试图干脆退出。

首先，它解锁正在处理的任何排队文件。 这具有取消传送的效果，以便在系统恢复时再次尝试该消息。 然后，sendmail将其身份重置为最初运行的身份。 这会导致会计logging正确地显示与退出相同的用户sendmail。 最后，sendmail以EX_OK退出，不pipe怎样，这样在closures的时候就不会产生错误。