REJECTされたメール
REJECTされたメールREJECTされたメールに対して、 原則として管理者は何もしません。
REJECTされたメールはメーリングリストの配送に比べると、
はるかに短時間で戻ります。
管理者はREJECTされたメールが多少頻繁に来ても気にしませんが、
REJECT
されたメールが再度送られて来ずにいることの方が気になります。
結論ですが、REJECTされた場合は該当箇所を修正して、
何度でもメールしてください。
メーリングリストへのメールがREJECTされた場合の原因と、
対処方法は以下の通りです。
メーリングリストへは予めメンバーとして登録したアドレス以外からは、 出すことはできません。発信者を登録したアドレスにするか、 他に発信したいアドレスを登録してください。
Internetの電子メールで使用する文字に半角片仮名は含まれていません。 返送されたメールには、該当の行が含まれています。 その行を直して再度送って下さい。半角片仮名(とその親戚)には、 以下の記号の文字(の半角版)が含まれます。
、。・「」ー゛゜
電子メールのヘッダはUS-ASCII(いわゆる半角の英数字)か、 MIMEヘッダ・エンコーディングという方法で変換された文字を使用できます。 メールのツールの設定に問題があると、 MIMEヘッダ・エンコーディングされず、 そのままになってしまう場合があります。 メールのツールの設定を適切に行ってください。 いわゆるアドレス帳に登録する名前に日本語を使用すると、 問題が起きるケースもあります。 また、 メールのツールに関する情報のページも参考にしてください。
Subjectにメーリングリストの名前や番号は入りません。 この処理は発信されたメールのヘッダの加工の一種と言えます。 Subjectの加工をすると、 メールのツールで一覧表示ですぐに見つけられて一見便利そうに見えます。 しかし、以下の様な問題点があるため、 明確な方針としてSubjectの加工は行っていません。
目でSubjectから発見できるというのは便利かもしれません。 しかし、メールのツールが賢い分類機能を持っていれば、 それを使った方がより便利です。 目で追うという原始的なことに頼るよりは、あるべき姿であると考えます。
発信者の意思を完全に損なうことなく、加工を行うことは不可能です。 メーリングリストの名前の表示の形式と、 同じパターンとなるSubjectは変更されてしまう恐れがあります。
メーリングリストのサーバはメンバーに配信するメッセージに、 必要最低限の処理だけを行うべきです。 これは配送のトラブルを減らす意味もあります。
以上を踏まえた上で完全な処理を行うことは困難ですし、 手間を掛けた割りに得るところが少ないため、 Subjectの加工は行っていません。
代わりというわけではありませんが、以下のヘッダの処理を行っています。
X-Delivered-Toの追加このヘッダにはメーリングリストのアドレスが入ります。 メールのツールによっては、これを使って効率の良い分類ができるでしょう。
X-Sequenceの追加このヘッダにはメーリングリストに出されたメールの連番が入ります。 但し、当初はまったく番号付を行っていなかったこともあって、 絶対的な値は正確ではありません。
Return-Pathヘッダの保存Return-Pathヘッダには、
到着した時点のエンベロープの送信者が入っています。
これをX-Return-Pathと名前を変えて残る様にしています。
Receivedヘッダの削除Receivedヘッダはメールサーバを経由する毎に付加されます。
そして、一部のメールサーバはReceivedヘッダの数で、
メールがループしてるかどうかを判断している場合があります。
このチェックに引っかかってエラーとならない様に、
ON THE ROADメーリングリストを処理するメールサーバに届くまでの
Receivedはヘッダを削除します。
但し、 最初に付加された(メールの中では最後に出て来る)
ReceivedヘッダはX-Receivedという名前に変更して残します。
Reply-Toにメーリングリストのアドレスが入るようにすると、 リプライがしやすくなるという主張をする方もいらっしゃいます。 これは以下の理由で行っていません。
メールのツールにReply-Toは非常に強い指示として働くこと
メールを送って来た発信者に返事をするか、 メーリングリストに答えるかを、 受け取った人が選択する余地をなくしてしまいます。
UNIXのもっとも基本的な機能しかないと言われている UCB Mailでさえ発信者に答えるか、 メーリングリスト(または宛先の全員)に答えるか、 いずれかを選択できます。 これは明らかにメールのツールとして必要な機能です。 Reply-Toを付ける過剰な処理は、 必要な基本的機能を持っていないツール(悪貨)を 広めることになっていまう恐れがあります。
メーリングリスト運営上に対する危険性の問題
世の中の電子メールは完全なSMTPだけありません。 電子メールの世界は、もっと広い範囲に渡っています。
エラー・メールを、 SMTPのエンベロープの送信者に正しく返せないメールの gatewayも存在し、そこでメールを読んでいる人もいます。
それらのメールのgatewayは、 エラー・メールをヘッダに書かれたアドレスに返します。 さらに悪いことに、 Reply-Toに書かれたアドレスに返すシステムも存在します。
メーリングリストの処理として、 これを防止する手段が全くないわけではありませんが、 効果的・確実・安全な方法はなかなかありません。 しかも問題を持ったシステムのために、 手間暇を掛けるのももったいないことです。
といった様々な問題があるため、Reply-Toヘッダは付けない様にしています。 但し、発信者の方が付けたものを削除することもしていません。
いわゆる「HTML形式のメール」には以下の問題点があります。
「HTML形式」を誰でも読めるわけではありません。
テキスト形式には通常のテキストとHTMLの2つの部分が、 1つのメールに含まれた形で送られます。
2つの部分は、若干の文字装飾等を除くと基本的にまったく同じ内容です。
元々テキスト・ベースを前提として来たInternetのメールに共通していることですが、 メーリングリストのやりとりの本質はテキスト・ベースの情報交換です。 将来は変わるかもしれませんが、少なくとも現時点ではそうですし、 当面は変わらないでしょう。
多少のサイズが増えるだけとも思えますが、
Internetを流れるときのトラフィックに与える影響
Dialupで接続してる方の接続時間に与える影響、特に従量性の場合
プロバイダに保持できるメールの大きさや数の制約がある場合
といったことも考慮しなければなりません。特にメーリングリストの場合は、
多数の参加者にメールが配送される。
ということを忘れてはいけません。例えば、ON THE ROADメーリングリストでは 800人以上の方に届きます。単なるテキストで済むものを、 「HTML形式」で送付することは無駄以外の何者でもありません。
もちろん、相手が納得ずくの上であるならHTML形式でも構いませんが、 そうでない場合は「単なるテキストでHTML形式と一緒に送るのは避けるべき」 というのが、 現状のInternetでの(日本だけではない)一般的なマナーと言えるでしょう。
困ったことにMicrosoftのツールは、 Internetの慣習を無視した設定がデフォルトであったり、 設定の変更で直しようがないといった困った作りのものが少なからず存在します。 これに関連して役立つと思われるURLへのささやかなリンクを、 メールのツールに関する情報のページに 用意しました。御参考にして頂けると幸いです。
Netscape Messangerにはメッセージカード(vCard)と言う、 ユーザの情報を添付する機能があります。 これに日本語を使用している場合に日本語がISO-2022-JP(JIS)にエンコードされず、 シフトJISそのままか何かで出てしまう様です。 そうでないバージョンもあるかもしれませんが、 「シフトJISそのまま」で送ると「メーリングリストのチェック」にひっかかります。
メッセージカード(vCard)は添付しない様にするのが、確実な解決方法です。