☰

Sendmail/procmail/Exchange メールの切り捨て

tag-icon • tag-icon sendmail procmail exchange
Sendmail/procmail/Exchange メールの切り捨て

同僚は私を新しい狂気の深さから救うパターンを見つけるようにインスピレーションを与えました。ここでいくつかのシンクタンクが今、その理由を教えてくれることを願っています...

現場：元の受信者に基づいてメールを再配布するためのprocmail設定を含む複数の汎用メールIDがあります。たとえば、generic_ID1に送信された電子メールはStaff1、Staff2に送信され、generic_ID2に送信された電子メールはStaff3、Staff4などに送信されます。

GENERIC_ID1_RECIPIENTS="staff1@domain,staff2@domain"

:0
* ^TO.*generic_ID1
! $GENERIC_ID1_RECIPIENTS

質問：メッセージが切り捨てられ、ランダムに表示されます。最終的に発見されたパターンは、文が76列でピリオドとハードリターンで終わったときに起こったことを示しています。 75列または77列にはなく、76列にはより多くのテキストがあります。同じ行。この期間以降のすべてのテキストは失われます。

付録：ちょうど226列にピリオドで再び現れるのを見ました。びっくりしました。

再配信する前にメッセージをコピーして、procmailがメッセージ全体を受信したことを確認できます。

:0c                       # note: 'c'
* ^TO.*generic_ID1
! $GENERIC_ID1_RECIPIENTS

私はsendmailが再送信時にそれを切り取ることができると思いますが、これを診断または証明する方法がわかりません。 （私はsendmail管理者ではなく、単にprocmailユーザーです。）

問題は完全に再現可能です。

質問：なぜこれが起こり、どのように解決するのですか？

とても感謝しています。

編集：タイトルとタグを更新しました。解決方法はコメントにあります。

答え1

(質問コメントから変換)

この方程式は、実際には sendmail、procmail、Exchange の 3 つの部分で構成されます。

  • 交換：配信用にメッセージを受け入れると、プレーンテキストメッセージの形式を再指定し、行をエンコードし、75文字に改行するように見えます。

  • メールを送信：このメッセージでは、古代の（しかし既知の）動作に従います。ここでは、単一行の単一ピリオドをメッセージの終わりとして解釈してから渡し、実際のメッセージ本文を効果的に切り捨てます。

  • プログラムメール：文書によると、ピリオドを無視するように強制するフラグを使用してsendmailを呼び出す必要があります。これは行われず、明示的な構成ファイルディレクティブに従わないことに注意してください。短期ソリューション：すべての再送信レシピに-oi -OIgnoreDots = Tを渡します。長期的な解決策：今、設定設定をサポートし、ネイキッドサイクルを無視するようにサイトのprocmailインストールをアップグレードします（転送されたフラグはもう必要ありません）。

ハードラッピングが使用される理由は、Exchangeが以前にプレーンテキストメッセージをエンコードしたときに=20ピリオドが自動的にラップされ、1行に残る機能が導入されたためです。

関連情報