免責事項:私はここや他の場所でSendmailのヘッダー書き換えに関する質問や記事をいくつか読みました。他の質問は主に次の内容に関するものなので、以下の質問に対する答えは見つかりませんでした。書き直しヘッダーを追加する代わりに、ほとんどすべてがアウトバウンドメッセージと封筒送信者(封筒の受取人の代わりに)
こうは言っても:
私は Debian jessie で Sendmail 8.14.4 を使用してメール サーバーを実行しています。
同じ O/S ユーザー アカウントにマップされている電子メール受信者アドレスがいくつかあります。それぞれの O/S ユーザーがメッセージを読むとき、メッセージが元々どの電子メール アドレスに送信されたのかを判別できません。
したがって、Sendmail ですべての受信電子メール メッセージにエンベロープ受信者を含むカスタム ヘッダーを追加したいと思います。
私の問題を例で説明するともっと分かりやすいと思います:
[email protected]
と という2 つの電子メール アドレスがあるとします。[email protected]
どちらも O/S ユーザー アカウント にマップされていますoffers
。これまでのところ、これは正常に機能しています。O/S ユーザーがoffers
自分の電子メールを取得すると、[email protected]
とに送信されたすべてのメッセージが表示されます[email protected]
。
ここで問題となるのは、各メッセージが元々どのメール アドレスに送信されたのかを判断できないことです。つまり、両方のメール アドレスに送信されたすべてのメッセージは表示されていますが、特定のメッセージが元々 に送信されたのか、[email protected]
に送信されたのかはわかりません[email protected]
。
したがって、各受信メッセージに次のようなカスタム ヘッダーを追加したいと思いますX-Envelope-Recipient: <Original envelope recipient>
。
これを行う最も簡単な方法は何でしょうか?
昔、私は Sendmail 用の簡単なカスタム ルールをいくつか書いたことがあります。しかし、あれから 15 年近く経っているので、もうそんなことはしたくないので、簡単な解決策があるか、誰かが正しい方向を指し示してくれることを願っています。正直に言うと、私の問題を解決するために milter を書くことは、Sendmail のルール構文をもう一度学ぶよりも、今のところは簡単だと思います...
編集1
@AnFi のリクエストに応じて、sendmail.cf からのローカル メーラー定義を次に示します。
Mlocal, P=/usr/lib/sm.bin/mail.local, F=lsDFMAw5:/|@qPSXnz9, S=EnvFromSMTP/HdrFromL, R=EnvToL/HdrToL,
T=DNS/RFC822/SMTP,
A=mail.local -l -h inbox
答え1
あなたの質問は Sendmail.org FAQ 3.29 で解決されます
3.29 仮想ドメイン内の複数のユーザーが 1 つのメールボックスにアクセスする場合、実際の受信者を指定するヘッダーを追加するにはどうすればよいですか?
短縮版: virtusertableを使用し、~offers/.procmailrc
virtuserテーブル:
[email protected] offers+offer1
[email protected] offers+offer2
~offers/.procmailrc
で「詳細を追加」する必要があります$1
。
または
カスタムヘッダーで$h(+detailに設定)を使用できます
警告: 両方宛てのメッセージの2つのコピーを取得/処理します[email protected]
。[email protected]
答え2
あなたが提案していることはSMTPプロトコルに反するでしょう。またはヘッダーRCPT TO
に存在しないにもかかわらず、コマンドにアドレスを追加する正当な理由があります。To:
Cc:
RFC 5321 7.2.「ブラインド」コピー(強調は私による):
メッセージ ヘッダー セクションに表示されないアドレスが、SMTP サーバーへの RCPT コマンドに表示される理由はいくつかあります。最も一般的な 2 つの理由は、メール アドレスを「リスト エクスプローダ」(1 つのアドレスが複数のアドレスに解決される) として使用することと、「ブラインド コピー」が表示されることです。特に、複数の RCPT コマンドが存在する場合、これらのメカニズムの目的の一部が損なわれないようにするために、SMTPクライアントとサーバーは、トレースヘッダーフィールドの一部として、または情報ヘッダーフィールドまたはプライベート拡張ヘッダーフィールドとして、RCPTコマンド引数の完全なセットをヘッダーセクションにコピーしないでください。このルールは実際にはしばしば違反され、強制することもできないため、「bcc」の使用を認識している送信 SMTP システムでは、各ブラインド コピーを 1 つの RCPT コマンドのみを含む個別のメッセージ トランザクションとして送信すると便利である場合があります。
SMTP トランザクション (「エンベロープ」) 内の「逆方向」(MAIL、SAML などのコマンドから) または「転送」(RCPT) アドレスとヘッダー セクション内のアドレスの間には、固有の関係はありません。受信システムは、このような関係を推測して、配信用のメッセージのヘッダー セクションを変更するために使用しないでください。 一般的な
Apparently-to
ヘッダー フィールドは、この原則に違反しているだけでなく、意図しない情報漏洩の一般的な原因でもあるため、使用しないでください。
非推奨のApparently-to
ヘッダーはオプションで制御されますNoRecipientAction=action
。
メッセージに受信者ヘッダー (
To:
、Cc:
または )がない場合の動作をアクションに設定します。Bcc:
none
メッセージは変更されず、add-to
To:
封筒の受信者を記載したヘッダーを追加します。add-apparently-to
Apparently-To:
封筒の受信者を記載したヘッダーを追加します。add-bcc
空のBcc:
ヘッダーを追加し、add-to-undisclosed
というヘッダーを追加します'To: undisclosed-recipients:;'
。
通常、元の受信者アドレスはTo:
またはCc:
ヘッダーにすでに含まれていることにご注意ください。ユーザー アカウント名 に変更してはならないため、 、または hidden のoffers
いずれかになります。ヘッダーの書き換えは、DKIM 署名が破損する可能性があるため、さらに危険になっています。唯一の合理的な使用例は、ローカル オリジン (宛て) のメールのアドレス書き換えです。[email protected]
[email protected]
user
[email protected]
すべてのアドレスのリストを追加するとRCPT TO
プロトコルに違反しますが、実際には単一のオリジナルRCPT TO
アドレスメールが配信されたユーザー。Sendmailでこれを実現する方法はわかりませんが、ポストフィックス(デフォルト設定の場合)追加するX-Original-To:
まさにそれを含むヘッダーと、さらにDelivered-To:
内部の宛先メールボックス ( [email protected]
) を含むヘッダーがあります。