[1]から[11] の知識があれば、トラブルの対処法が結構思いつくでしょう。
それでもまだ悩んでる人は、ここを読んでください。
まず、メールは沢山のマシンを経由している事を思い出してください。
相手側の問題かと思っていたら、実はこちら側の問題だったというような勘違いが珍しくありません。誤解の無いようにどこに原因があるのか見極める必要があるのです。
最初に、全てのメールヘッダを丹念に調べましょう。
特に、
Received: from XXX by XXX via XXX with XXX id XXX for XXX ; XXXMime-Version: 1.0Content-Type: XXX/XXX; charset=XXXContent-Transfer-Encoding: XXX
等は要注意です。
どの段階でどのヘッダが付けられたのか、良く考えながら調べてください。
本来、全てのメールヘッダは送信側(MUA)が付ける約束であり、メールサーバ(MTA)が付けるのは、Received:だけです。また、最後のサーバがReturn-Path:を付ける場合もあります。
しかし、実際にはそれ以外のヘッダを追加したり、書き換えを行なうMTAがあります。最近は、不完全なメールヘッダを直す機能を持ったMSAも登場してきています。
メールヘッダを確認したら、いよいよ原因を特定していきます。
という風に分類していくと、わかりやすいです。
メールソフトには膨大な種類があるので、ここでは説明出来ません。
ソフト別の情報に詳しいページを探すと、色々なソフトの説明が出てきますので、そちらをどうぞ。
メールヘッダをよ〜く探して、もしX-Mailer:があれば、わかるかもしれません。
[11] 文字化けするとこう見える！を、よーく見れば、文字コードの間違いが判定出来ますね。
いろんな文字コードを表示/変換するツールで直しましょう。
困ったときのツール集から、いくつかダウンロード出来ます。
という作業が必要になります。メールサーバに確信が持てない場合は、7ビットに変換してから送る必要があります。
例えば、Shift_JISをbase64で送るのなら、次の様なヘッダが付くはずです。
Content-Type: text/plain; charset=Shift_JISContent-Transfer-Encoding: base64
また、テキストファイルとして保存したものをuuencode, BinHex等で添付する方法も考えられます。
ただし、ファイルを自動で添付するソフトの場合、テキストはそのまんま送信してしまうソフトもあるようで、ちょっと心配です。この場合はあらかじめ圧縮しておけばバイナリになりますから、自動添付するとき確実に変換されると思います。
何にしろ、受信者が扱えるかどうか、十分な確認をしてください。
データが欠落してるんですから、どうしようもありません。
元の状態を予想して修復するツールも存在しますが、完全に復元できるとは限りません。
私はバイナリエディタで、先頭ビットを1に書き換えてみて、少しずつ修復しますが、大変手間がかかります。
送信者に文字コードをISO-2022-JP (JIS)に直してもらうのが先決でしょう。
なお、1ビット欠けたテキストのサンプルを色々テキストファイル集に入れておきました。
JIS X 0201のカタカナを使えないメールソフトに乗り換えるのが一番ですね。ソフトによっては、「JIS X 0201のカタカナを使わない」「半角カタカナを使わない」「1バイトカタカナを使わない」という設定があり、これを選ぶと良いらしいです。使えてしまうソフトの場合は、[6.2] ヤバイ文字を使わないコツを参考にしてください。
ISO-2022-JPには含まれていませんが、それなりに使えてしまうソフトは結構あるので問題なく使える場合もあります。受信者側で問題が起きないかどうか確認してください。
ところで、Shift_JISやEUC-JPならJIS X 0201のカタカナを含んでいます。テキストファイルとして添付する方法もあります。これについては[12.2.2]も読んでください。
普通のメールで行の扱いが違うことは稀ですが、添付されたファイルの行の区切りが違うことは珍しくないでしょう。
[11] 文字化けするとこう見える！をみれば、間違いが判定出来ますね。
行の区切りを変換するツールも存在します。
大抵、文字コードを変換するツールでも出来るようです。
圧縮ソフトやアーカイバにも変換機能がある場合があります。
ファイル名がASCII以外だと失敗するかもしれません。
最近のメールソフトだと自動でuudecodeやBinHexやMIMEのBase64等を変換してくれるのもあるみたいですが、対応していない場合は、自分で変換しなければなりません。ツールを困ったときのツール集に用意したので、色々試してみてください。
uuencode用のツールを何種類か用意して色々試しましょう。
一見正しいuudecodeファイルでも、変換出来ない場合は行の区切りが違うのかもしれないですね。
ファイル名が日本語になっていると失敗することがあります。
稀に、非互換のuuencodeがあることを確認しています。実際、xxencodeみたいなそっくりさんもあります。
また、複数のファイルが添付されている場合、最初のファイルしか元に戻さないソフトが存在します。送信側でメール自体を複数に分けるとか、アーカイバを使って一つにする等の配慮も必要かも。
BinHex用のツールを何種類か用意して色々試しましょう。
実は正しいBinHexなのに、あなたがマックバイナリの扱いを間違えているかもしれません。
ファイル名が日本語になっていると失敗することがあります。
行の区切りが違うのかもしれないですね。
また、複数のファイルが添付されている場合、最初のファイルしか元に戻さないソフトが存在します。
まず、base64のサンプルをよく見て、仕組みを理解してください。MIME用のツールを何種類か集めて、色々試してください。
MIMEに関する決まりは結構複雑なので、ツールによって動作が異なります。大きく分けて2種類あるようです。
(1)の場合、ちゃんとしたヘッダが付いていないと失敗します。だからヘッダが消えていたり間違っている場合は、テキストエディタを使って次のヘッダ類を自分で書いてからツールに読み込ませると成功するかもしれません。
Mime-Version: 1.0Content-Type:xxx/xxx; name="xxx"Content-Transfer-Encoding:xxxContent-Disposition: attachment; filename="xxx"
(2)の場合、データ部分以外の余計なヘッダや文章が混ざっていると失敗します。だから、データ部分だけをツールに読み込ませれば、成功するかもしれません。
あと、ファイル名が日本語になっていると失敗するかもしれません。テキストエディタで、何か適当なASCIIファイル名に書き換えてからツールに読み込ませれば、成功するかもしれません。
一見正しいMIMEファイルでも、変換出来ない場合は行の区切りが違うのかもしれないですね。
送信者の意図が確認できるまで、そのバイナリファイルを使ってはいけません。
ウイルスを混入させた悪質なメールかも知れないからです。
最近はワープロ文書や表計算文書に感染するウイルスもあります。
ウイルスについての詳しい情報は、リンク集から入手出来ます。
たとえ知り合いからのバイナリであっても、安心してはいけません。送信者が気付いていないだけであって、実はウイルスに感染しているかもしれないでしょう。
手持ちのウイルスチェッカで何も発見されなくても、安心してはいけません。そのウイルスチェッカよりも新しいウイルスがあるかもしれないでしょう。
バイナリをやり取りする限り、完全に防御する方法はない事を知っておいてください。
お互いに知り合いではない人のアドレスをTo:やCc:にまとめて書くと、怒られる事があります。。
ここに沢山アドレスを書くと全部みんなに見える訳です。「電話番号や住所録を勝手に配られたら迷惑なように、メールアドレスが知られるのも迷惑だ」という事でしょう。
そういう場合はBcc:を使うという方法があります。
メールヘッダのTo:にもCc:にも自分のアドレスが書かれていないのに、メールが届く場合があります。例えば、
等です。何故かというと、エンベロープのRCPT TO:に、あなたのアドレスが書かれていたからです。
メーリングリストの中には、自動的にReply-To:にそのメーリングリストのアドレスを付けるものがあります。こうすると、返信は必ずメーリングリスト宛に届くので便利なのです。
ところが、送信者が最初からReply-To:を付けて送ると、どっちのアドレスを優先するかという問題が出てきます。送信者のアドレスを優先してしまえば、それの返信はメーリングリストに届かないことになります。予めメーリングリスト管理者に問い合わせてください。
メールサーバが非常に混んでいたり、メンテナンス中だったりすると、届くのが遅れる場合があります。
メールヘッダのDate:とReceived:を丹念に読むと、どのサーバで遅れたかわかるかもしれません。
メールヘッダのDate:が変な場合、原因は6つ考えられます。
TZ」等の設定を自分の住んでる場所にしてください。例えば日本の場合、環境変数TZは、JST-9とかJapan等があるようです。Date:ヘッダは必須ですから、送信側で付けなければなりませんが、もし無かったりした場合、途中のサーバや受信側ソフトが付ける事があります。そのぶん時間がずれるでしょう。どっかにHost unknownとかhost not foundって書いてあったら、「メールホストがわかんねえ」という意味です。メールアドレスを間違えたか、ネットワークがトラブルを起こしてるか、どちらかでしょう。
どっかにUser unknownって書いてあったら、「そんな奴はしらねえ」という意味です。メールアドレスを間違ってるかもしません。
どっかにWARNINGって書いてあったら、それは警告です。英語で説明が書いてあるので一生懸命読みましょう。大抵、途中のサーバのトラブルでメールが渋滞しているようです。渋滞が解消したら、相手に届くとか書いてあるかもしれません。
どっかにERRORって書いてあったら、エラーなので届いていない可能性が高いです。英語の説明を一生懸命読みましょう。途中のサーバのトラブルかもしれません。メールアドレスを間違えてるかもしれません。メールが長過ぎて受け付けてくれない場合もあります。
「不幸の手紙」でも「幸福の手紙」でも、受け取ったからといって人に送ってはいけません。インターネットでは、これらをチェーンメールといって禁止しています。
ネチケットガイドライン (RFC1855)にも書かれていますが、ネットワークの利用権が無効になるかもしれません。
鼠講(ねずみこう)と同じ原理で、一気に世界中にメールが氾濫してメールの大渋滞になります。
あなたのところで止めて下さい。
時々、ウイルス情報のメールがありますが、結構デマである場合が多いようです。詳しい情報は、リンク集から入手出来ます。
年末年始は一部のメールサーバがお休みしており、この様なときに大量に発信されるとメールの大渋滞になる可能性があります。沢山のマシンを経由してメールが届くインターネットでは、これを避けなければなりません。
最悪の場合、数日遅れて届いたり、消えてなくなるかもしれません。世界のどこかのマシンがパンクするかもしれません。
特に画像等のバイナリデータをメールで送ったりすると、それはサイズが巨大ですから、状況は深刻になるでしょう。
しかし、最近は管理状態や回線速度やコンピュータの性能も良くなってきており、不安は減っているとも考えられます。
巨大画像を送るのではなく、「このURLを見てね」という短いメールを送るという方法があります。そのURLを見ると画像があるという仕組みです。この方法ならメール数は同じですが、負担は減ります。
ということが出来れば問題ないでしょう。
メールサーバの設定は管理者が行なっていますから、一般ユーザ側で対処するのは非常に難しい事です。
プロバイダやイントラネットによっては、メールの行数やサイズ、受信数等、様々な制限があるようです。制限の範囲内で確実に情報を伝える方法を考えてください。
メールサーバ自体に誤動作の疑いがあるならば、同じサーバを使用しているユーザに確認してみるのも手です。本当に誤動作している事を確認したら、管理者に連絡して対処してもらってください。
沢山の人宛に広告をメールで送ってくる団体や個人が存在します。
これを禁止する公式文書は見つけていませんが、大多数が迷惑に思っているようです。何度も裁判沙汰になっているのも事実です。「ジャンクメール対策室」等で詳しい情報が得られます。
鼠講まがいのメールが存在します。違法性が高いです。
もしかすると、ソフトのバグかもしれません。有名メーカのソフトでも、バグだらけのものがあります。
間違ったメールを送信してしまうソフトの場合、それを回避する方法を探してください。回避方法が見つからない場合は、別のソフトを探しましょう。
特に、MIMEの規則は結構ややこしいし曖昧な部分もあるので、怪しい動作をするソフトが沢山あります。
また、インストールに失敗してたり、大事なファイルが壊れて誤動作してたりすることがあります。ハードディスクをチェックしてから再インストールするとあっさり直ったりします。
Zenbu ASCII de kaitara doudesuka?
Koremo rippana NIHONGO desu.
フロッピーディスクやMO等で渡すとか、電話で話すとか、郵便で送るとか、Webページを持ってる人はそこにファイルを置いて見てもらうとか、色々ありますね。
メールで問題が出るなら、別の方法を考えましょう。