使用主机的Postfix从Docker容器发送邮件

因为你有一个工作的解决scheme，在这里我将尝试解释当你telnet到postfix（SMTP）和当你使用sendmail（非SMTP）时的不同行为。

仅供参考，OpenDKIM将由具有Milter机制的postfix调用。 你可以通过这个官方文档得到一些信息在postfix中是如何实现的。 这里是后缀中的milter hook的图。

  SMTP-only non-SMTP filters filters ^ | ^ | | v | | Network -> smtpd(8) | | \ | V Network -> qmqpd(8) -> cleanup(8) -> incoming / pickup(8) : Local -> sendmail(1) 

您可以看到sendmail-way（非SMTP）和telnet-way（SMTP）具有不同的处理顺序。

• 非SMTP邮件在注入之前会被清理处理。 清理守护进程负责添加丢失的标题： （Resent-）From：，To：，Message-Id：和Date ：。 因此，即使原始电子邮件的标题不完整，您的电子邮件也会在注入OpenDKIM milter时具有完整标题。

• 在发生任何清理处理之前，SMTP电子邮件将被注入OpenDKIM。 因此，如果您的原始电子邮件标题不完整，那么opendkim可能会拒绝签署电子邮件。 From：头是强制性的（参见RFC 6376 ），如果电子邮件没有，OpenDKIM将拒绝签署电子邮件并给你一个警告

   can't determine message sender; accepting 

因为我从来没有使用泊坞窗，比我不知道在一个容器内的sendmail /皮卡有什么限制。 我认为大卫·格雷森的解决方法是足够安全的，以确保OpenDKIM签名的消息。

我决定容器发送邮件的方式是把它写到一个特定目录的文件中，这个文件可以作为Docker的“容量”从容器和主机上访问。

我创build了一个名为mailsender.sh的shell脚本，它从指定的目录读取邮件，将它们发送到sendmail，然后删除它们：

 #!/bin/bash # Runs on the host system, reading mails files from a directory # and piping them to sendmail -t and then deleting them. DIR=$1 if [ \! \( -d "$DIR" -a -w "$DIR" \) ] then echo "Invalid directory given: $DIR" exit 1 fi echo "`date`: Starting mailsender on directory $DIR" cd $DIR while : do for file in `find . -maxdepth 1 -type f` do echo "`date`: Sending $file" sendmail -t < $file rm $file done sleep 1 done 

Ubuntu使用了新手，所以我创build了一个名为/etc/init/mailsender.conf的文件，将这个脚本变成一个守护进程：

 description "sends mails from directory" start on stopped rc RUNLEVEL=[2345] stop on runlevel[!2345] respawn exec start-stop-daemon --start --make-pidfile --pidfile /var/run/mailsender.pid --exec /path/to/mailsender.sh /var/mailsend 

我可以通过start mailsender启动服务，并stop mailsender 。 我可以查看/var/log/upstart/mailsender.log中的日志，当然我可以使用PID文件来监视它。

您需要创build/var/mailsend目录，然后通过将参数-v /var/mailsend:/var/mailsend到您的-v /var/mailsend:/var/mailsend docker run命令，从Docker容器访问它。

这是一个半回答，或者至less是一个半testing，因为我目前正在通过同样的问题。 我希望有人能够帮助充实我错过的东西。

OP（David Grayson）的回答听起来像是重新发明了postdrop mail-spool，但是使用这个邮件服务器听起来像是一个很有前途的方法，所以这里就是我所知道的。

由postfix提供的/ usr / bin / sendmail兼容性接口将邮件传递到postdrop，这是postgrid，允许它将邮件存储到/ var / spool / postfix / maildrop的maildrop队列中。 这应该在docker容器中发生。 后缀的其余部分应该有希望不必在容器中运行。

所以，我主机挂载/ var / spool / postfix / maildrop和/ var / spool / postfix / public。 我可以在主机环境中将邮件发送到/ var / spool / postfix / maildrop，因为我已经挂载了maildrop队列目录。 因为我已经挂载了/var/spool/postfix/public ， maildrop可以通过信号pickup来从队列中收集邮件。 不幸的是，除非我处理这些问题，否则uids和gids会涉及到，这意味着主机目录中的拾取无法读取假脱机文件，而且更糟糕的是，后缀安装会混淆主机环境中maildrop目录的权限。

不过，这似乎工作：

 $ cat Dockerfile FROM debian:jessie # Ids from parent environment RUN groupadd -g 124 postfix && \ groupadd -g 125 postdrop && \ useradd -u 116 -g 124 postfix RUN apt-get update && \ DEBIAN_FRONTEND=noninteractive apt-get install --no-install-recommends -y \ postfix \ bsd-mailx CMD echo test mail | mail [email protected] $ sudo docker build . ... Successfully built 16316fcd44b6 $ sudo docker run -v /var/spool/postfix/maildrop:/var/spool/postfix/maildrop \ -v /var/spool/postfix/public:/var/spool/postfix/public 16316fcd44b6 

虽然它起作用了，但我并不满意于编码uid和gid。 这意味着同一个容器不能统计到处都是一样的。 我认为，如果不是从主机挂载卷，而是从运行postfix的容器挂载它，那么它永远不会发生冲突，我只需要一个postfix安装从多个容器中获取邮件。 我将这些uid和gid设置为一个基本的图像，所有的容器都从这个图像inheritance而来。

我想知道这是否是一个很好的方法。 有了这样一个简单的邮件configuration，并且没有在容器上使用守护进程来重新尝试传递，像msmtp这样简单的本地MTA可能更合适。 它将通过TCP传送到同一主机上的一个继电器，在那里发生假脱机。

对msmtp方法的担忧包括：

• 如果它发送到smtp中继不可用，更多的可能性丢失邮件。 如果这是同一主机上的中继，那么networking问题的可能性很低，但我必须小心如何重新启动中继容器。
• 性能？
• 如果大量的邮件通过，邮件开始丢弃？

通常，共享后缀假脱机方法似乎更容易成为脆弱的configuration，但在运行时不太可能失败（中继不可用，因此邮件被丢弃）。

您必须将inet_interfaces指向inet_interfaces bridge（ docker0 ），位于/etc/postfix/main.cf中的postfixconfiguration文件中

 inet_interfaces = <docker0_ip> 

更多的内部工作细节在发送电子邮件从docker到后缀安装在主机上