[1]から[11] の知識があれば、トラブルの対処法が結構思いつくでしょう。
それでもまだ悩んでる人は、ここを読んでください。
まず、メールは沢山のマシンを経由している事を思い出してください。
相手側の問題かと思っていたら、実はこちら側の問題だったというような勘違いが珍しくありません。誤解の無いようにどこに原因があるのか見極める必要があるのです。
最初に、ヘッダの全てのフィールドを丹念に調べましょう。
特に、
Received: from XXX by XXX via XXX with XXX id XXX for XXX ; XXX
Mime-Version: 1.0
Content-Type: XXX/XXX; charset=XXX
Content-Transfer-Encoding: XXX
等のフィールドは要注意です。
どの段階でどのフィールドが付けられたのか、良く考えながら調べてください。
基本的には、フィールドを付けるのは送信側(MUA)の仕事であり、メールサーバ(MTA)が付けるのは、Received:だけです。また、最後のサーバがReturn-Path:を付ける場合もあります。
しかし、実際にはそれ以外のヘッダを追加したり、書き換えを行なうMTAがあります。最近は、不完全なフィールドを直す機能を持ったMSAもあります。
メールヘッダを確認したら、いよいよ原因を特定していきます。
という風に分類していくと、わかりやすいです。
メールソフトは少なくとも数100種類あります。実際に数えたので本当です。
それら全てを説明するのは不可能です。まず、マニュアルやヘルプ類を読んでください。
プロバイダがサポートページを用意している場合も多いです。作者自身やユーザがサポートページを用意している場合も多いです。
ソフト別の情報に詳しいページを探すと、色々なソフトの説明が出てきますので、そちらをどうぞ。
メールソフトの名前を知らせる決まりはありませんから、本来はわかりません。本人に尋ねるのが一番でしょう。
ただし、多くのメールソフトは何らかの特徴があります。特にメールヘッダに特徴を残すものが多いです。X-Mailer:やUser-Agent:といったフィールドがあれば、わかるかもしれません。
[11] 文字化けするとこう見える！を、よーく見れば、文字コードの間違いが判定出来ますね。
いろんな文字コードを表示/変換するツールで直しましょう。
困ったときのツール集から、いくつかダウンロード出来ます。
という作業が必要になります。メールサーバに確信が持てない場合は、7ビットに変換してから送る必要があります。
例えば、Shift_JISを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]も読んでください。
普通のメールで行の扱いが間違っていてトラブルが起きるケースは少ないです。希にCRやLFのまま送信してしまうソフトもありますが、途中のメールサーバがCR LFに直してしまい、問題すら気付かないケースもあります。
ただし、添付されたファイルの行の区切りが違うことは珍しくないでしょう。
[11] 文字化けするとこう見える！をみれば、間違いが判定出来ますね。
行の区切りを変換するツールも存在します。
大抵、文字コードを変換するツールでも出来るようです。
圧縮ソフトやアーカイバにも変換機能がある場合があります。
メールを全部ASCIIで書いていれば文字化けする事はない筈です。
にもかかわらず、読めないといわれるケースがたまにあります。原因は色々考えられます。
円記号を使っていませんか？日本語フォントの場合、円記号で表示される場合とバックスラッシュで表示される場合がありますが、英語フォントだとバックスラッシュだけです。
あと、ASCIIではなくJISの文字が混入していませんか？JISにもアルファベットが入っています。ASCIIのアルファベットと区別するには、等幅フォントでの表示をお勧めします。
なお、特にJISの記号類「，」「．」「．」「：」「；」「 」(空白)等は気付きにくいので注意してください。等幅フォントで表示してカーソルをその文字の前後に移動してみる、あるいはマウスで選択してみると、幅が広いので確認出来るでしょう。
署名(signature)が日本語になっていないでしょうか？メールソフトによっては、予め用意しておいた署名を自動的につけるので、ついうっかり日本語だという事を忘れていませんか？
また、メールソフト側の問題も考えられます。一部のソフトは、全部ASCIIで書いていても、
というフィールドを決め打ちにしているソフトがあります。受信側のソフトが日本語に対応してない場合、このフィールドを見て処理できないと判断してしまう可能性があります。
本来は、
となるか、またはcharset=が付いてない、またはContent-Type:自体が付いていないのが正しいです。
日本国外に住んでる人が日本語メールの事情に詳しい筈もないので、色々と問題のあるケースが多いです。
ISO-2022-JP以外の文字コードになっていないか確認してください。Shift_JISとかEUC-JPとかUTF-8になってる可能性があります。日本語未対応のソフトで無理矢理日本語を書いているケースも多くあります。
米国やヨーロッパ等のラテン言語圏からのメールでありがちなのは、ヘッダが次のようになっているケースです。
何とか無理してISO-2022-JP、EUC-JP、Shift_JISで書いたはいいが、メールソフトが「少なくともUS-ASCIIじゃないのでISO-8859-1だろう」と判断したのでしょう。受信者が自力で文字コード変換してやれば、読めるかもしれません。または、ヘッダのiso-8859-1の部分を手で書き直すとか。
アジア等の漢字文化圏からのメールだと、もうちょっと違う現象があります。ヘッダが次のようになっていないでしょうか。
韓国で使われている文字コードISO-2022-KRやEUC-KRにはハングル(Hangul)と漢字(Hanja)の他にひらがなとカタカナが含まれています。charset=ks_c_5601-1987になってる事がありますが、これはcharset=euc-krの間違いです。
中文簡体字用のGB2312にも漢字(simplified Chinese character)の他にひらがなとカタカナが含まれています。
中文繁体字用のBig5は様々な亜流があり、漢字(traditional Chinese character)の他にひらがなとカタカナが含まれているものもあります。
だから、これらの文字コードを使ってもある程度の日本語が書けるのです。ただし、それらを読むためにはそれらの文字コードに対応したソフトとフォントが必要です。多言語対応ソフトでなんとかなるかもしれません。
また、charset=iso-8859-1になってるのに本当の文字コードはEUC-KRやGB2312になっているケースもあります。EUCはISO-8859-1と区別しにくいので送信側のソフトが自動判別に失敗したのでしょう。
英語はASCIIで、日本語はISO-2022-JPで書けますが、それ以外の言語だと別の文字コードを使う必要があります。送信側と受信側の双方がその文字コードに対応したメールソフトを持っていなければなりません。フォントも用意する必要があるかもしれません。
私は日本語メールしか調査していないので、それ以外の言語ではどの文字コードが一般的なのか良く知りません。良く聞く話では次のようになりますが、未確認です。間違ってたら教えて下さい。
ヨーロッパの言語(Latin系言語)だと、ISO-8859-1やISO-8859-2等を使う。
韓国語だとヘッダはEUC-KRの"B"または"Q" encodingを使い、本文はISO-2022-KRを使う事になっているが、本文でもEUC-KRが使われるようになってきている。
中国語では繁体字と簡体字の2種類があるので両方使えるようにしておかないと不便だ。繁体字ではBig5、簡体字ではGB2312が一般的だ。HZ-GB-2312というのもあるが、これは中国語圏というよりもむしろヨーロッパ主体のネットワークで中国語を使おうとして考えられた。ISO-2022-CN、ISO-2022-CN-EXTというのもあるが、実際にはほとんど使われていない。
ロシア語(キリル文字)はKOI8-Rらしい。
なお、ISO-2022-JPにはギリシャ文字「ΑΒΓΔΕαβγδε…」とキリル文字「АБВГДабвгд…」が一通り入っていますが、これを使って書いたからといってギリシャ語用ソフトやロシア語用ソフトで読めるわけではありません。
結論から書くと、名案はありません。
ISO-2022-JPは英語と日本語しか使えません。ギリシャ文字「ΑΒΓΔΕαβγδε…」とキリル文字「АБВГДабвгд…」なら入っており日本語用メールソフトで扱えますが、ギリシャ人やロシア人の持ってるメールソフトで必ず表示出来るというわけではないです。
多言語を使うには、多言語用の文字コードを使う事になります。ISO-2022-JP-2という文字コードなら多くの文字コードを混在出来ますが、これに対応しているメールソフトは極一部です。
Unicode系の文字コード(UTF-7やUTF-8等)なら多言語を扱えますが、完全に普及したわけではありません。
送信側と受信側の双方が多言語文字コードに対応したメールソフトを用意する必要があります。フォントも用意する必要があるかもしれません。
ファイル名がASCII以外だと失敗するかもしれません。
最近のメールソフトだと自動でuudecodeやBinHexやMIMEのBase64等を変換してくれるのもあるみたいですが、対応していない場合は、自分で変換しなければなりません。ツールを困ったときのツール集に用意したので、色々試してみてください。
uuencode用のツールを何種類か用意して色々試しましょう。
一見正しいuudecodeファイルでも、変換出来ない場合は行の区切りが違うのかもしれないですね。
ファイル名が日本語になっていると失敗することがあります。
稀に、非互換のuuencodeがあることを確認しています。実際、xxencodeみたいなそっくりさんもあります。
また、複数のファイルが添付されている場合、最初のファイルしか元に戻さないソフトが存在します。送信側でメール自体を複数に分けるとか、アーカイバを使って一つにする等の配慮も必要かも。
BinHex用のツールを何種類か用意して色々試しましょう。
実は正しいBinHexなのに、あなたがマックバイナリの扱いを間違えているかもしれません。
ファイル名が日本語になっていると失敗することがあります。
行の区切りが違うのかもしれないですね。
また、複数のファイルが添付されている場合、最初のファイルしか元に戻さないソフトが存在します。
まず、base64のサンプルをよく見て、仕組みを理解してください。MIME用のツールを何種類か集めて、色々試してください。
MIMEに関する決まりは結構複雑なので、ツールによって動作が異なります。大きく分けて2種類あるようです。
(1)の場合、ちゃんとしたヘッダが付いていないと失敗します。だからヘッダが消えていたり間違っている場合は、テキストエディタを使って次のフィールド類を自分で書いてからツールに読み込ませると成功するかもしれません。
Mime-Version: 1.0
Content-Type: xxx/xxx; name="xxx"
Content-Transfer-Encoding: xxx
Content-Disposition: attachment; filename="xxx"
(2)の場合、データ部分以外の余計なヘッダや文章が混ざっていると失敗します。だから、データ部分だけをツールに読み込ませれば、成功するかもしれません。
あと、ファイル名が日本語になっていると失敗するかもしれません。テキストエディタで、何か適当なASCIIファイル名に書き換えてからツールに読み込ませれば、成功するかもしれません。
一見正しいMIMEファイルでも、変換出来ない場合は行の区切りが違うのかもしれないですね。
送信者の意図が確認できるまで、そのバイナリファイルを使ってはいけません。
ウイルスを混入させた悪質なメールかも知れないからです。
最近はワープロ文書や表計算文書に感染するウイルスもあります。
ウイルスについての詳しい情報は、リンク集から入手出来ます。
たとえ知り合いからのバイナリであっても、安心してはいけません。送信者が気付いていないだけであって、実はウイルスに感染しているかもしれないでしょう。悪意のある/なしに関わらず、ウイルスは広がるのです。
手持ちのウイルスチェッカで何も発見されなくても、安心してはいけません。そのウイルスチェッカよりも新しいウイルスがあるかもしれないでしょう。
バイナリをやり取りする限り、完全に防御する方法はない事を知っておいてください。
お互いに知り合いではない人のアドレスをTo:やCc:にまとめて書くと、怒られる事があります。
ここに沢山アドレスを書くと全部みんなに見える訳です。「電話番号や住所録を勝手に配られたら迷惑なように、メールアドレスが知られるのも迷惑だ」という事でしょう。
そういう場合はBcc:を使うという方法があります。
メールヘッダのTo:にもCc:にも自分のアドレスが書かれていないのに、メールが届く場合があります。例えば、
等です。何故かというと、エンベロープのRCPT TO:に、あなたのアドレスが書かれていたからです。
メーリングリストの中には、自動的にReply-To:にそのメーリングリストのアドレスを付けるものがあります。こうすると、返信は必ずメーリングリスト宛に届くので便利なのです。
ところが、送信者が最初からReply-To:を付けて送ると、どっちのアドレスを優先するかという問題が出てきます。送信者のアドレスを優先してしまえば、それの返信はメーリングリストに届かないことになります。予めそのメーリングリストのルールを確認しておいてください。
メールサーバが非常に混んでいたり、メンテナンス中だったりすると、届くのが遅れる場合があります。UUCPで転送されてる場合は結構時間がかかります。
メールヘッダのDate:とReceived:を丹念に読むと、どのサーバで遅れたかわかるかもしれません。
メールヘッダのDate:が変な場合、原因は色々考えられます。
TZ」等の設定を自分の住んでる場所にしてください。例えば日本の場合、環境変数TZは、JST-9とかJapan等があるようです。Date:ヘッダは必須ですから、送信側で付けなければなりませんが、もし無かったりした場合、途中のサーバや受信側ソフトが付ける事があります。そのぶん時間がずれるでしょう。JSTとしているソフトがありますが、これは認められていません。+0900が正しいです。通知メールを戻って来させる手法がいくつかありますが、どれも確実とはいえません。また、通知メールが来ても確実とは言えません。ソフトで自動的に取り込んだだけで、実際には目を通していないかもしれないのです。せいぜい返信を待つしかないでしょう。
Return-Receipt-To:フィールドを使うと、相手側のサーバに届いたときや、相手が開いたときに通知メールが返ってくる事があります。ただし非標準フィールドなので最近はサポートされない場合が多いです。もし通知が来ても、まだ人間が目を通していないかもしれません。
MDN (Message Disposition Notification)という方式では、Disposition-Notification-To:フィールドを付けて送ると、相手がメールを開いた時に通知メールが返ってくる事があります。ただしサポートしないソフトも沢山あるし、サポートしていても通知しない設定にしているかもしれません。
SMTPの拡張機能(ESMTP)のひとつにDSNというのがあります。途中のサーバ全てが対応していれば、一番最後に受け取ったサーバが通知を返してきます。途中に対応してないサーバがあると、その手前のサーバが通知を返してくるだけなので確実ではないです。一番最初に渡すサーバが対応してなければ通知自体が来ません。また、通知が来たとしても、サーバまで届いたというだけであって、メールソフトで取り込んでいるとは限りません。
また、一部のメールソフトは独自の形式を使って通知を返してきますが、送受信者が同じソフトを使っていなければ機能しないでしょう。
なお、配送に失敗した場合はちゃんと通知が来る筈です。SMTPサーバには配送に失敗した場合にエンベロープのMAIL FROM:に書いてあるアドレスに通知を送る義務があるからです。
また、Errors-To:フィールドにエラー通知して欲しいアドレスを書いておくという手法もありますが、これは非標準なのでサポートされないケースが多いです。
どっかにHost unknownとかhost not foundって書いてあったら、「メールホストがわかんねえ」という意味です。メールアドレスを間違えたか、ネットワークがトラブルを起こしてるか、どちらかでしょう。
どっかにUser unknownって書いてあったら、「そんな奴はしらねえ」という意味です。メールアドレスを間違ってるかもしません。
どっかにWARNINGって書いてあったら、それは警告です。英語で説明が書いてあるので一生懸命読みましょう。大抵、途中のサーバのトラブルでメールが渋滞しているようです。渋滞が解消したら、相手に届くとか書いてあるかもしれません。
どっかにERRORって書いてあったら、エラーなので届いていない可能性が高いです。英語の説明を一生懸命読みましょう。途中のサーバのトラブルかもしれません。メールアドレスを間違えてるかもしれません。メールが長過ぎて受け付けてくれない場合もあります。
「不幸の手紙」でも「幸福の手紙」でも、受け取ったからといって人に送ってはいけません。インターネットでは、これらをチェーンメールといって禁止しています。
ネチケットガイドライン (RFC1855)にも書かれていますが、ネットワークの利用権が無効になるかもしれません。
鼠講(ねずみこう)と同じ原理で、一気に世界中にメールが氾濫してメールの大渋滞になります。
あなたのところで止めて下さい。
時々、ウイルス情報のメールがありますが、結構デマである場合が多いようです。詳しい情報は、リンク集から入手出来ます。
年末年始は一部のメールサーバがお休みしており、この様なときに大量に発信されるとメールの大渋滞になる可能性があります。沢山のマシンを経由してメールが届くインターネットでは、これを避けなければなりません。
最悪の場合、数日遅れて届いたり、消えてなくなるかもしれません。世界のどこかのマシンがパンクするかもしれません。
特に画像等のバイナリデータをメールで送ったりすると、それはサイズが巨大ですから、状況は深刻になるでしょう。
しかし、最近は管理状態や回線速度やコンピュータの性能も良くなってきており、不安は減っているとも考えられます。
巨大画像を送るのではなく、「このURLを見てね」という短いメールを送るという方法があります。そのURLを見ると画像があるという仕組みです。この方法ならメール数は同じですが、負担は減ります。
ということが出来れば問題ないでしょう。
メールサーバの設定は管理者が行なっていますから、一般ユーザ側で対処するのは非常に難しい事です。
ネットワークによってはメールの行数やサイズ、受信数等、様々な制限があります。制限の範囲内で確実に情報を伝える方法を考えてください。
メールサーバ自体に誤動作の疑いがあるならば、同じサーバを使用しているユーザに確認してみるのも手です。本当に誤動作している事を確認したら、管理者に連絡して対処してもらってください。
沢山の人宛に広告をメールで送ってくる団体や個人が存在します。
国によって対応が違いますが、例えば日本ではこれを制限する法律が出来ました。
「迷惑メール対策」等のページで詳しい情報が得られます。
鼠講まがいのメールが存在します。違法性が高いです。
普通、メールを受信するにはパスワードを入力する必要がありますから、他人が勝手に読むことは出来ないでしょう。しかし、それも場合によります。他人の目に触れるケースも考えられるので、「封書というよりはハガキだ」という人もいます。
もしかすると、ソフトのバグかもしれません。有名メーカのソフトだからといって過信しないでください。操作が楽な事と、バグの多さは無関係です。
間違ったメールを送信してしまうソフトの場合、それを回避する方法を探してください。回避方法が見つからない場合は、別のソフトを探しましょう。
特に、MIMEの規則は結構ややこしいし曖昧な部分もあるので、怪しい動作をするソフトが沢山あります。
また、インストールに失敗してたり、重要なファイルが壊れて誤動作してたりすることがあります。設定ファイルが壊れている場合、それを削除してから設定をやり直すとよいかもしれません。ハードディスクをチェックしてから再インストールするとあっさり直ったりするケースもあります。
Zenbu ASCII de kaitara doudesuka?
Koremo rippana NIHONGO desu.
電話で話すとか、郵便で送るとか、Webページを持ってる人はそこにファイルを置いて見てもらうとか、色々ありますね。
メールで問題が出るなら、別の方法を考えましょう。
なお、フロッピーディスク、MO、CD-R等で渡すという手法もありますが、フォーマットが違うと読み込めないという事もあります。十分に申し合わせしてください。
それはメールの問題ではありません。
人間関係の問題です。