仮想エイリアシングが完了すると、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についてほとんど何も知りませんが、ログを見て2回の書き換えを実行し、2回の連続で同じ結果が得られた後にのみ最終受信者アドレスを決定します。ローカルアカウントの解釈を防ぐ方法ユーザーBとしてメールアドレス ユーザーB@私の目的地[0]?ローカルを見つけたらすぐに停止したいです。ユーザーBそれでは彼にください。

上場できませんか?@mydestination[0]/etc/postfix/virtualで?これは私の現在の問題を解決することができますが(このユーザーはシステムの実際のUnixユーザーなので、メールが正しい場所に移動するため)、Postfixはまだ考えています。[Eメール保護]最終受信者です。これは私にとって間違っているようです。それはただ知る必要があります。ユーザーBそれはUnixアカウントであり、それがすべてです。

答え1

技術的にはこれは答えではありませんが、おそらく得られる最高の答えです。私は長年にわたって多くのsendmailマッピングを使用してきました。最良の方法はそれを分解し、より簡単にすることです。マップにドメインの 1 つだけを含めて、そのドメインにワイルドカードを適用し、そこからビルドします。

sendmail -bv フラグなどの sendmail 診断フラグを使用すると、簡単に作成できます。

答え2

そのため、質問の最後に提案した方法で問題を解決できましたが、仮想ドメインを避けることが正しいアプローチである可能性があるという結論もありました。

まず、最初に提案された解決策は、ファイルへの参照をa.com削除することです。virtual

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

これを実行した後のダミーの翻訳b.comc.org生成[Eメール保護]そして[Eメール保護]やはり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ドメインを使用せずに包括アドレスを持つことができます。

関連情報