"MLに送信したけれど自分には送信されない"
とある NPO のサーバーの維持管理の仕事を手伝っていて、タイトルのような声を聴くことがありました。サーバーはレンタルサーバで、OS は UNIX、メール環境は sendmail、その上に fml が載っています。この分野を苦手とする自分にとって呼ばれたくない状況ではありましたが、気付いてみると上にも下にも隣にも人影が薄いという人手不足の中、何とかせざるを得ないことになってしまいました。
そもそも fml の中を覗いたこともない自分にとって、ネットで何か情報が無いかと調べていて、最初に気づいたのは「古い」ということ。歴史と実績はあるものの、もはやトレンドの技術ではなさそうだということです。レンタルサーバで使われている理由は実績と信頼性、そして技術者の確保がし易いせいかと．．．
そんな評論家的な気分に浸っている場合ではないので、見つけた「fml バイブル」という本を入手することにしました。ところが、2001 年出版ということで、もはや古本しかありません。図書館を検索して、やっと手にすることができました。
おおよその構成を把握してから、FTP ソフトで、関連する制御ファィルをダウンロードして、本を脇に置いて内容を調べていきます。以下、そこで分かったことを備忘録的に書き留めていきます。かなり個人的・主観的記述になっているため、あくまでも参考程度に、未熟者のメモ書きとしてお読みください。
制御ファィル（config.ph）から見えるMLの動作
MLへの送信側のクライアント、サーバー、受信側のクライアントの関係はつぎのようになります。
Fig.1 メーリングリストの標準的な形
member に登録されたアドレスからの送信を受け、それを active に登録されているアドレスに配信するという単純な動作が基本になります。
おおよその構成を把握してから、FTP ソフトで、関連する制御ファィルをダウンロードして、本を脇に置いて内容を確認していきます。設定ファイル config.ph の 670 行付近にメールのセッセージ ID の処理に関する記述があります。ML の member に登録されているアドレスから ML 宛に発信されたメールのメール ID と、ML から active に登録されているアドレス宛に発信されるメールのメール ID の関係を規定するパラメータです。次の文です。
# Message-Id: use original Message-Id or Server Defined Message-Id ?
# if 1, original and
# if 0, fml generates a message-id like $day.FMLAAA.$pid.$MAIL_LIST
# value: 1/0
# $USE_ORIGINAL_MESSAGE_ID = 1;
この一群の文の最後の行によってメッセージ ID が次のように変わります。
・「$USE_ORIGINAL_MESSAGE_ID = 1;」の場合(デフォルト設定)
①→②のメールのセッセージ ID がそのまま②→③のメールのメッセージ ID として設定されます。
・「$USE_ORIGINAL_MESSAGE_ID = 0;」の場合
②→③のメールのメッセージ ID は fml の規定する様式で新規に生成されます。
デフォルトの「$USE_ORIGINAL_MESSAGE_ID = 1;」で ML 宛にメールを送信すると、member から受信したメールのメッセージ ID と、active 宛に送信するメールのメッセージ ID は同じものになります。
今までは、それで、何ら不都合が無かったのですが、gmail の場合は動作が異なります。次の図のように gmail のアドレスから ML に送信された場合を見ていきましょう。
Fig.2 gmail から ML に送信された場合
この図も基本的には Fig.1 と変わらないのですが、アドレスが Gmail になったことで、gmail の制御方式が関係してきます。①クライアントの中でどのような処理が行われているかが問題になります。
gmailの制御
Google の公式見解を確認したわけではありませんが、G メールは同じメール ID を持つメールが複数着信した場合、最初のものを残して後続のものは全て（無警告で）捨てているようです。つまり、fml は①のパソコンに対して配信をしているものの、①のパソコンの中でそのメールが捨てられているということになります。
それでは、②→③のメッセージ ID を fml 独自のものに置き換えてはどうでしょうか。テストの結果、メールは A.***@***.gmail に配信されることが確認できました。しかし、gmail の受信トレイには思いっきり目立つ警告文が表示されます（googleの抵抗?）。
Fig.3 gmail 受信トレイに表示された警告文
この警告文は「問題ない」をクリックすれば消えるのですが、使い勝手を大きく損ねることになります。ただ、google の考え方からすれば、セキュリティ上重要かつ不可欠な措置になるのだと思います。
メッセージ ID を変えても、なおもチェックされる理由は、メールアドレス（アカウント）によるものと思われます。つまり、google は自分宛にメールを出すことを想定していないということと思います。
ML に送信したメールは、自分の送信済トレイに残っており、わざわざ自分あてのメールを受信する必要がないという考え方かと思います。
結局、どうすれば良いのか
もう一つの考え方として、fml の設定を、member と一致する active に対しては配信しないようにするという方法があります（正確には"ありました"）。
fml の過去のバージョンではこのカスタマイズ機能がありました（fml バイブル 392 ページ）が、新しいバージョン（ fml8 ）では廃止されています。このあたりの経緯も不明です。（google 仕様を受け入れた ? ）
config.ph の最終段落 1511 行付近に「LOCAL CONFIG」があり、「See doc/tutorial's chapter "HOOKS"」とされています。これは、サーバーへの fml のインストール時に使用する機能と思われ、レンタルサーバのディレクトリを確認しても「fml/doc」というディレクトリはありません。
結論として、G メールとそれ以外のメーラーの違いを明示し、利用者の理解を得ながら現状の仕組みのままとするのがベストであると思われます。
変化の始まり？
HTML5 / CSS3 という規格が廃止され、Living．．．になったとか。既存の規格に対するチャレンジャーが、IT 技術のさらなる進歩に貢献するのは望ましいことと思います。一企業の独善的な主張に基づくチャレンジではなく、コミュニティーの根を張った活動の結果が日の目を見る形でのチャレンジであることに希望を見出したいと思います。
※ 「fml バイブル」は結局 amazon で入手しました。古本とはいえ 1500 円、名著なんですね。書棚の真ん中に鎮座しています。