.png)
共有ドメイン用のメール サーバーを設定しようとしています。メールボックスの半分は Gmail でホストされ、残りの半分はローカル サーバーでホストされます。
iRedMail 1.6.0 をインストールし、解決されていないすべての @example.com ユーザーをローカル サーバーに送信するように Gmail を設定しました。送信者が @example.com でない場合は機能しましたが、@example.com の場合は、認証されていない接続のためメールが拒否されました。すべての Gmail サブネットを mynetworks (main.cf と settings.py の両方) に追加することで、この問題は解決しました (もっと良い解決策はありますか?)。
実際の問題は、メールボックスがリモートでホストされているときに、メールをローカルの postfix から送信することでした。
「rcpt to:」コマンドを回避するには、リモート メールボックス リストを使用して仮想メールボックス マップを作成する必要がありました (ひどい解決策です)。それでもしばらくすると、配信不能レポートを受け取りました。
アクション: 失敗 ステータス: 5.1.1 診断コード: x-unix; ユーザ不明
少し苦労した後、仮想メールボックス マップとほぼ同じデータを持つトランスポート マップ (トランスポート マップにはローカル トランスポート ルールもあります) を追加すると、問題がなくなり、メールが正しく流れることがわかりました。
現在、同じジョブに 2 つの異なるアドレス リストを使用するのは、さらにひどい状況です。Gmail で行っているように、「解決されていない @example.com のメールを ... に転送する」などの、より洗練されたソリューションを探しています。何か提案はありますか?
ありがとう、ダリオ
答え1
ドメインを次のように設定した場合地元オンプレミスドメイン（バーチャル）、使用してみてくださいfallback_transportまたはfallback_transport_maps。次のように設定します ( 内main.cf):
fallback_transport = smtp:gmail.com
（gmail.comのMX検索を実行し、その結果を使用します。Gmailでホストされているドメインとgmail.comアドレスのMXサーバーのリストは同じであると想定しています）。以下を読むことを検討してください。男5輸送右側部分のフォーマットをさらに詳しく知りたい場合。
オンプレミス側で「未解決のメールをすべて Gmail に送信」し、Gmail 側で「未解決のメールをすべてオンプレミスに送信」するというアイデアは非常に悪いです。メッセージが両側で解決されない場合、そのメールは無期限にピンポン状態になり、最終的には Gmail でサーバーが禁止されます。これを回避するには、2 つのリストを維持する必要があります。Gmail では、オンプレミスに存在するメール アドレスの正確なリストを把握する必要があり、オンプレミスでは、Gmail に存在するメール アドレスの正確なリストを把握する必要があります。fallback_transport_maps既知のリモート メールボックスには、前に提案したのと同じものを返し、不明なメールボックスには何も返さないような方法で使用して、Postfix がメールを早期に拒否するようにします。常にできるだけ早く拒否する必要があります。これは電子メールの良い点です。また、同様の理由で、Gmail がオンプレミスに実際にあるメールのみを転送するようにした方がよいでしょう。文句を言う必要はありません。これは、このような設定の代償です。
もしあなたがバーチャルセットアップでは、この目的に使用しようとするかもしれませんtransport_mapsが、細心の注意を払って行う必要があります。オープンリレーを作成しないでください。
このソリューションのもう1つの問題は、送信者の一部が制限的なDMARCポリシーを持っている可能性があることです（これは良い（私はもっと多くの送信者がそうしてくれることを望みます。そうすれば、インターネット上のメールスパムはずっと少なくなるでしょう）。彼らがあなたのサーバーをSPFレコードで代理送信を許可されているサーバーとしてリストすることはまずありません。そのため、そのようなメールがあなたのサーバーに入り、Gmailにリダイレクトすることに決めた場合、Gmailは意思それを拒否すると、何もできなくなります。私の知る限り、これは解決不可能です。