受信メールによる立証

Question

現在、民事請求訴訟をしてる原告です。被告から私宛に送信されたメールを証拠としたところ、被告は、私に対して金銭の支払を待って欲しい旨記載した自身に不利になる１０行、日本語で２３３文字の部分に付いては、自分は記載せず、後から加筆されたものだと主張してきました。そこで、裁判所からプロバイダーへ調査嘱託してもらい、ログの情報開示をしてもらった処、Messege-IDが私が事前に提出していたヘッダーと同一であるとの回答をもらいましたが、被告は、印刷されたヘッダーは証拠にならないと主張しています。ノートパソコンに受信したメールがそのまま残っているのですが、証拠としてそのノートパソコン、もしくは、メールがeml形式で保存されたFDを提出し裁判所が検討してもらうというのは可能でしょうか。本人訴訟していまして相談する人がいないので困っています。どうぞよろしくお願いします。

noname#11476 · Accepted Answer

初めてoutlookを動かして確認してみました。

*emlファイルをテキストエディタで開くと送られてきたメールそのものが見えるようですね。
その状態で文字数を確認してみて下さい。
そして、先ほど述べた開示してもらったログのサーバとそれ以降のサーバが付け加えたRecieved:フィールドか何byteか確認して下さい。
もしぴったり314byteならば、合理的に同一サイズであることを説明できますね。

よしんば数byte異なっていたとしても、後で加筆したのであれば日本語の文字は最低466byteは増えていないとおかしいですから、加筆したというのは無理がありますね。

メールのeml形式のファイルをFDとあとテキストファイルでプリントアウトして提出するのは意味があるでしょう。（メールサイズの証明にはこのファイルしかありません）
ただそれがどういう意味なのかはご自身で説明しないと行けません。裁判所は中立ですから自ら判定はしてくれません。

emlファイルをテキストエディタ（制御コードもそのまま表示できるもの。たとえば秀丸エディタとか）でみると、日本語の部分が他の文字の羅列（つまり文字化け状態のよう）になっているのがわかりますね。
これは、その前に
charset="iso-2022-jp"
というのがあるはずで、これがキャラクタセットを決めています。
そして、日本語の文は、<ESC>$Bで始まり、<ESC>(Bで終わるという形になっていたりします。
<ESC>は一文字で、エスケープシーケンスです。
多分相手もoutlookだとMIMEで multi-part message になっているかもしれません。

あと、上記のサイズの話を持ち出す前に、相手に日本語２３２文字より前の文章は自分が書いた物であり、自分はそれ以上なにも書いていない＝つまりあくまで新たに付け加えた物であるとの主張を確認することが大事ですね。

プロバイダのサーバにメールが残っているというのは普通考えられません。
outlookの設定でサーバに残す設定をしていなければ消えています。
メールは出入りが激しいですから、通常トラブルに対してはRAIDに頼っているだけです。

和解勧告が出されるとの事ですので、ご質問者の納得行く結果であればよし、駄目であれば上記のような戦法でしょうね。

bship · Answer

zzZさん#11でのつっこみありがとうございます。
被告が、「俺の送ったメールはこれだ」と送信メールを出してきているのであれば、それと原告の持つメールの差異とサイズからいけそうですが、被告は、「そのようなメールは書いたが、この部分は全く覚えがない」と言っているのではないでしょうか。
つまり、他の部分は全く同じだとまでは言っていないでしょうから、「文章を追加して、その分オリジナルの文章を意味を変えずに短くすることは可能である」と主張できるのではないでしょうか。
プロバイダは、せいぜい「サイズ的にあってます」と言う以上は証言できませんよね。
（繰り返しますが、被告が送信したメールを出してきているのであれば別ですね）
もう一方のプロバイダにもメール本体ないのでしょうかね...
（そもそも和解案まで来ていて証拠云々の話ってまだ意味あるのでしょうか？）

laing · Answer

＞現在、５回目の口頭弁論（原告、被告の本人尋問）が終わり、次回は和解案を裁判官が提案すると言っていました。

この裁判ですが、もうそこまで来てるのですか？
（始まったばかりかと思っていました）
結局、どちらも弁護士がいない。
裁判官は技術的なことが分からない。
この状況では和解勧告を勧められるでしょうね。

質問者様は和解には断固として応じないということです
か？裁判官が出す内容にもよるのでしょうが。
和解は負ける訳ではないので、質問者様のお気持ち
次第ですが・・・

立証に関しては技術的に相手がおかしいことを陳述して
いることを指摘できればというところでしょうが。
現実問題として補充主張してくれる弁護士もいないと
いうことですと思い通りにはいかないですよ。
状況的に・・・

回答になってなくてすみません。

noname#11476 · Answer

訂正:
>size や message-idの記録のラインに同時に from= にサーバ名があるはずです。 

「プロバイダが提出した記録の」size や message-idの記録のラインに同時に from= にサーバ名があるはずです。

noname#11476 · Answer

sizeから求める方法ですね。裁判でとなると、正しく計算したかどうかが重要になりますので、誰かに証明してもらわないと行けませんね。
刑法違反であれば警察には専門の人がいますが、、、民事は多分駄目でしょうね。

プロバイダのサーバーを管理している人であれば、ご質問者のパソコンに入っているメールのサイズがプロバイダのサーバに残っているメールサイズが同じであることは証明できます。

>プロバイダは3205、私が保存しているOutlook Express メール メッセージのソースの容量は3519バイトです。
この差 3519-3205 = 314 byte はエンベロープの違いがあります。
メールというのは、まず送信もとでmessage-idが決められてサーバに送られます。
それ以降、サーバ間を何度も転送されて行き、最終的にご質問者のメールを管理するサーバにたどり着きます。
この転送過程で、サーバはメールのヘッダ部分に転送記録を書き込みます。これをエンベロープと呼んでいます。
たとえば、

Received: from hogehoge.meramera.co.jp (tikitiki.meramera.co.jp [192.165.1.1])
     by mugumugu.kaikai.co.jp (8.10.1/2.4W) with ESMTP id h5ICD5b3014513
     for <petapeta@mugumugu.***.co.jp>; Wed, 18 Jun 2003 20:25:05 +0900 (JST)
Received: ～（略）
　　　　　～（略）
Received: ～（略）

というReceived: の行が複数あります。
これ一つ一つがサーバ間の転送記録です。
from に書かれているサーバからやってきて、by は受け取ったサーバ名です。
for は最終アドレスです。

つまり、初めの3205 byte は、そのサーバが受け取ったときのサイズであり、その後まずそのサーバは自分の受診記録を Recieved: ～　として書き込みます。
そこが最終であればそれであとは別のpopというプロトコルでメーラーに読み込まれますし、場合によっては更にご質問者のメールサーバに歳転送されて、Recieved:がもう一つ追加されて、そこでご質問者のメーラー(outlook)に読み込まれた可能性もあります。
size や message-idの記録のラインに同時に from= にサーバ名があるはずです。
そのサーバ名に一致するRecieved : のfrom のサーバ名があるはずです。
サーバに記録されるメールサイズはそのRecieved:が記入される「前」のサイズです。
Recieved:は新しい物が一番先頭に来ますので、そのRecieved: を含めて、それよりも上位にあるRecieved:は全部サーバで受診した後に追加されたものですから、その文字数が314文字であればぴったしかんかんとなります。
ただ、POPでサーバよりoutlookなどで呼び出すときに、場合によってはヘッダの一部を追加／変更することがありますから、ぴったりと一致するかどうかはちょっとわかりません。ずれても20byte以内程度だと思いますけど。

あと、もう一つはoutlookが受け取ったときに文字コードを変換していて、返還後のファイルサイズになっていると多少異なります。（この話は後で）

裁判所経由でmessage-idを照会できたのですから、ついでにメールファイルのサイズがサーバで受け取った物と同一かどうかという問い合わせをしてみると良さそうですね。
つまり314byteの違いを説明できれば、本文に加筆されていないことを証明したことになりますので。

>メッセージのソースの文字数を数えましたところ1298文字（半角英数）でした。
これ本当に全部でしょうか？
outlookは個人的に危険を感じていて（利用者が多いのでウイルスの標的になっていますから）一切使っていないのでわかりませんが、メールソフトは大抵エンベロープなどの情報は出ないようになっていたりします。
あるいは一部ヘッダ部を削除・変更している可能性もあるし、メールソフトによって文字コード変換などが行われている可能性もあります。
1298byteというのは食い違いが大きすぎますので。

日本語の場合はJIS code(厳密には異なるがここでは便宜的にそう呼ばせて下さい） で送られますので（最近は違うのもあるようですが）、簡単に文字数を計算できません。
というのも昔はメールは7bit code しか通さなくて、今でも8bitだとトラブルが起きることがあるので。
日本語文字はShit-JISでは2byteと数えれば良いだけですが、JISだとキャラクターセット定義コードや切替コードなどが入りますので、大変複雑で、簡単にはいきません。
実際に送信した文章を使ってJIS変換してどうなるかを見てみないと。
少なくともサーバに記録されているサイズはJIS code の時のサイズだと思われます。
ですから、本文と、題名(subject)に使われているであろう日本語は一度変換されているはずです。

以上こんなところです。

なんせインターネット関係のサーバー管理者（メール、WWW、ニュース、etc.)をしていたのは少し昔のことなので、多少上記書き込みに細かな間違いはあるかもしれませんので、その節はご容赦の程を。（大枠は間違っていません）

noname#134955 · Answer

いちおう#10への反論です。
相手が、「金額の1と書いたのを3に改竄された」と主張しているのではなく、「この部分全体が加筆」と主張している以上、 size が合致することさえ示せば良いのではないでしょうか。相手の嘘さえ示せばいいと思います。同一 size での改竄という可能性は、今回は気にしなくてよいのではないでしょうか。

やはり#7の方法がポイントになります。

bship · Answer

サイズの問題ではありません。
改竄する上でサイズはいくらでも調整できます。
プロバイダにメール本体が残っていない以上
内容の改竄有無の判断は不可能です。
暗号技術を応用した電子署名しかその証明ができません。
いくら専門家でもある程度前提条件が整っていないと改竄の有無は判らないのです。
信頼できる第三者であるプロバイダがそのメール本体を持っていない以上、あとは水掛論です。
署名無し電子メールでは残念ながらどうしようもありません。ただ、相手のいう主張は「技術的には」変です。
印刷データが改竄可能なんていってたら、「ワープロによる契約書は信用できない」ということになってしまいます。

noname#134955 · Answer

#8続き。
思い当たる鑑定先が無ければ、 size 情報を出したプロバイダーあたりでしょうか? 少なくとも計算する能力を持った技術者はいるはずです。鑑定してくれるかどうかは別として。

noname#134955 · Answer

#6です。
こういう話になると、やはり弁護士が欲しいですね。
計算&鑑定に限って言えば、インターネット関連の技術者であれば、可能です。計算できる人の数は多いでしょう。しかし、誰が鑑定すれば、証拠として強いのか、という裁判面での強さは、私にはわかりません。

laing · Answer

＃３です。

証書で、立証してしまえばいんです。
専門家にメールの加筆の有無を判定して貰ったものに
日付、署名、捺印をしていただいて、それを提出
するんです。

相手が言い逃れをしてるのなら、むしろ確固たる証拠は
後出しが有利です。

証拠はタイミングを見て提出するのがお決まりです。
被告の出方を見ながら頑張ってみて下さい。
証書＋貴方の陳述書で十分なんです。
原告は立証出来ないと敗訴しますから、専門家に
にしっかり見て貰って下さい。

ところで相手も本人訴訟ですか？
ネットに詳しい弁護士がついてると厄介だと思ったので。
ちょっと気になりました。

受信メールによる立証

初めてoutlookを動かして確認してみました。

この回答への補足

zzZさん#11でのつっこみありがとうございます。

＞現在、５回目の口頭弁論（原告、被告の本人尋問）が終わり、次回は和解案を裁判官が提案すると言っていました。

訂正:

sizeから求める方法ですね。

いちおう#10への反論です。

サイズの問題ではありません。

#8続き。

#6です。

＃３です。

この回答への補足

似たような質問が見つかりました

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング