虚拟别名完成后,Postfix trivial-rewrite 会错误地扩展收件人

虚拟别名完成后,Postfix trivial-rewrite 会错误地扩展收件人

我在一个机器(Linux、Ubuntu 13.x)上托管了一些域,并尝试使用 Postfix 2.10.2-1 将邮件路由到它们。 (过去 10 年我一直使用 sendmail,所以这对我来说是新的。)我的所有MX记录均已相应设置,因此外部邮件可以正常到达邮箱。

我遵循了各种在线教程,并在我的配置中有以下相关行:

main.cf
-------
myhostname            = foo.a.com
myorigin              = /etc/mailname     # this just has 'a.com' inside it
mydestination         = a.com localhost.localdomain localhost
virtual_alias_domains = b.com c.org
virtual_alias_maps    = hash:/etc/postfix/virtual

目前,我只希望所有发送给任何域的邮政管理员的邮件都转到邮政管理员帐户,并且所有发送给任何域的其他任何人的邮件都转到关联的帐户。

virtual
-------
[email protected]  postmaster
@a.com            userA
[email protected]  postmaster
@b.com            userB
[email protected]  postmaster
@c.org            userC

不幸的是,所有发送给这些域中任何人的邮件都会被路由到用户A。在我启用详细日志记录之前,我认为虚拟域没有受到尊重。然而,启用详细日志记录后,我发现每封传入的邮件都会发生这种情况:

mail.log
--------
...
postfix/cleanup: maps_find: virtual_alias_maps: hash:/etc/postfix/virtual(0.lock|fold_fix): @b.com = userB
postfix/cleanup: mail_addr_find: [email protected] -> userB
postfix/cleanup: send attr request = rewrite
postfix/cleanup: send attr rule = local
postfix/cleanup: send attr address = userB

但随后 trivial-rewrite 再次运行(大约第 80 次处理该特定邮件)并决定用户B不是真正的最终 Unix 帐户收件人,而是代表以下地址的邮件地址:肌源(或者也许它正在选择第一个元素我的目的地...这会更有意义)。

postfix/trivial-rewrite: master_notify: status 0
postfix/trivial-rewrite: rewrite socket: wanted attribute: request
postfix/trivial-rewrite: input attribute name: request
...
postfix/trivial-rewrite: 'local' 'userB' -> '[email protected]'  # <-- d'oh!
postfix/trivial-rewrite: send attr flags = 0
postfix/trivial-rewrite: send attr address = [email protected]
postfix/trivial-rewrite: master_notify: status 1

然后postfix/cleanup接管

postfix/cleanup: maps_find: virtual_alias_maps: hash:/etc/postfix/virtual(0.lock|fold_fix): @a.com = userA
postfix/cleanup: mail_addr_find: [email protected] -> userA
postfix/cleanup: send attr request = rewrite
postfix/cleanup: send attr rule = local
postfix/cleanup: send attr address = userA

并得出结论:用户A是真正的 Unix 帐户接收者。

我对Postfix几乎一无所知,但从日志来看,它只是在运行两次重写并连续两次得到相同结果后才决定最终的收件人地址。如何防止它解释本地帐户用户B作为一个邮件地址 用户B@mydestination[0]?我希望它一找到本地就停止用户B然后把它交给他。

难道我不被允许列出吗@我的目的地[0]在 /etc/postfix/virtual 中?虽然这也许可以解决我当前的问题(因为这些用户是机器上真正的 Unix 用户,因此邮件会到达正确的位置),但 Postfix 仍然会认为[电子邮件受保护]是最终的接收者。这对我来说似乎是错误的。它应该只知道用户B是一个 Unix 帐户,就到此为止。

答案1

从技术上讲,这不是一个答案,但它可能是您得到的最好答案。多年来我使用了大量的 sendmail 映射。最好的办法就是分解它,让它变得更简单。使地图仅包含您的一个域,让通配符适用于该域,然后从那里进行构建。

使用 sendmail 诊断标志可以让您更轻松,例如 sendmail -bv 标志。

答案2

因此,我能够按照我在问题末尾所建议的方式解决我的问题,但我也得出结论,避免虚拟域可能是正确的方法。

首先,最初提出的解决方案:a.comvirtual文件中删除对的引用。

virtual
-------
#[email protected]  postmaster
#@a.com            userA
[email protected]  postmaster
@b.com            userB
[email protected]  postmaster
@c.org            userC

在我这样做之后,虚拟翻译b.comc.org生成[电子邮件受保护][电子邮件受保护]正如预期的那样,因为a.com是条目之一mydestination后缀/本地尽职尽责地交付用户B的邮件至/var/mail/userB用户C的邮件至/var/mail/userC.

当然,正如我在最初的问题中所担心的那样,它仍然得出这样的结论:a.com是所有这些用户的最终主域,这对我来说感觉很奇怪。那么,显而易见的解决方案就是根本不使用虚拟域——虚拟域的全部意义在于接受以下地址的邮件:不是系统上的实际 Unix 用户。但由于我所有的包罗万象的用户系统上的实际 Unix 用户,我应该只使用本地别名:

/etc/aliases
------------
admin: postmaster
www: postmaster
@a.com: userA
@b.com: userB
@c.com: userC

我仍然可以拥有包罗万象的地址,而无需使用virtual域。

相关内容