電子メールが「ベストエフォート」配信のみの場合、配信が保証された同様のプロトコルはありますか？
ファックスはその配達が「保証」されているために受け入れられる文書であるのに対し、電子メールはその配達が保証されていないためではないということが法律で確立されていることがよくあります。これは、ファックスと同じ程度の配信を保証するTCPベースのプロトコルに物乞いしているだけではありませんか？そのようなプロトコルは存在しますか、そしてそれはどの程度定着していますか？
FAXの配信は保証されません-FAXが失敗する原因はたくさんあります。いくつか例を挙げると：
- 誤ダイヤルした番号
- 紙からファックスを受信する（そして実現するほど賢くない）
- トナーからFAXを受信する（実現するほど賢くない）
- ファックス送信時に用紙が逆さまにセットされた
- FAXの受信は共有デバイスであり、受信したFAXは意図しない受信者によって取得および破棄されます
SMTP[〜＃〜]は[〜＃〜]TCPベースのプロトコルです。 RFC 821 およびその後継者 RFC 2821 および RFC 5321 を参照してください。
基礎となるネットワークプロトコル（TCP/IP）は、信頼性の高い配信（アプリケーションプロトコルレベルのもの）とは何の関係もありません。ほとんどのSMTPサーバーは、それらを通過したメッセージ（送信者/受信者/メッセージID）のログを保持します。これは、ログが改ざんされていない可能性があることを証明できれば、法廷で認められます。
弁護士に相談してください。SMTPプロトコルと、配信を確実にするための関連プログラム（DSN、Return Receipts）に接着されたメカニズムがあります。これら自体がベストエフォート/相互協力の拡張機能であることに注意してください（ほとんどのメールクライアントでは、開封確認メッセージを送信しないように選択できます。また、一部のクライアントは開封確認メッセージを発行できません。一部のMTAは、配信確認メッセージを発行できません。
私はこれらの許容性について確信がありません-それは裁判所と確立された判例に依存するでしょう。繰り返しますが、弁護士に相談してください。
ファックスの配達が「保証されている」ため、ファックスを受け入れることが法律で確立されていることがよくあります
送信者と受信者からの電子メールサーバーログは、おそらくFAX受信確認よりも信頼性が高くなります。
確認は単に、 "a"ファックスがドキュメントに応答して受信したことを意味します。
サーバーログは、「その特定の」メールボックスが電子メールを受信し、「その特定の」メールボックスに入る前にサーバーA、B、Cを通過したことを確認できます。
カナダでは、法廷でメールが受け入れられることを知っています。多くの場合、民事訴訟では Anton Piller Order を実行して、サーバーログとメールボックスのコンテンツを押収することができます。
配信を保証する唯一の方法は、直接のピアツーピア配信です。送信者は受信者への直接接続を確立する必要があり、受信者は受信を確認する必要があります。電子メールはnotピアツーピアプロトコルですが、ストアアンドフォワードプロトコルです。したがって、法廷で受け入れられるような保証はありません。ただし、プロトコルが信頼できるものであることを確認し、チェーン内のすべてのサーバーが適切に機能する場合はis信頼できることを確認してください。
ただし、技術的な配信の保証（実生活および電子メール/ファックス）では、メッセージの内容は保証されません。ログまたはエンベロープは、配信があったことのみを示し、メッセージの内容は表示できません。メッセージに署名しても、途中で操作されなかったことが保証されるだけです。ただし、署名された元のコンテンツはまだ「Hello world！」である可能性があります。 「解雇された」の代わりにaメッセージが送信されたという確認のみが表示されます。
これは、ファックスと同じ程度の配信を保証するTCPベースのプロトコルに物乞いしているだけではありませんか？そのようなプロトコルは存在しますか、そしてそれはどの程度定着していますか？
具体的に質問に答えるために-そのような[ネットワーク]プロトコルは存在しません。したがって、同様に前記プロトコルの固定はありません。
ただし、このトピックに関連して、[配信]が何を意味するか、または可能であるかについて、「保証」の意味についていくつかの重要な点があります。
- 送信者を認証する手段が必要です。ただし、FAXやメールのハンドシェイクプロセスにはそのような機能はありません。 「差出人」のFAX番号は、「差出人」の電子メールアドレスが多くのスパム/フィッシングメッセージに含まれているため、偽装される可能性があります。
- whatが送信されたことを証明するために送信中に変更されないように、メッセージ自体の否認防止を確実にするいくつかの手段が必要です。繰り返しになりますが、基礎となるプロトコルはそのような保証をしません。対称暗号化とメッセージハッシュを組み合わせたPKI（電子メールでデジタル署名技術を使用しますが、これはサポートされないこともありますが、複雑なため有効ではありません）は、電子メールで否認防止を提供するのに役立ちます。これらは十分に定着している方法ですが、電子メール通信スペース全体では直接使用できません。
- メッセージが実際に（実際に意図された）受信者に配信されたことを保証する何らかの手段が必要です。ログは上記に関して何の保証もしないため、実際には不十分であり、メールボックス（受信者ではない）におそらく入札された配信に弱い注釈を付けるだけです。これは郵便配達よりも弱いです。商取引法の制服商法（UCC）によると、合意された住所への配達に加えて、[商品/メッセージ]が利用可能であるという意図された受取人への配達の連絡が必要です。電子メールはターゲットメールボックスにメッセージを保存するだけですが、これは受信者にその到着が通知されたことを保証するものではありません。メッセージが到着したかどうかを絶えず「チェック」するのは受信者の義務です。
最後に、配信確認/受信を要求（送信者）および送信（受信者）するためのオプションの（そして大部分はクロスプラットフォームでサポートされていない）電子メールプロトコルがあります。ただし、これはめったに使用されず、保証されておらず、最後に受信者によるメッセージの受信を否定しません...むしろ、受信を確認しないことを選択したか、受信者が送信者または配信によって受信されなかった可能性があります。このオプション機能の同じ/バージョンをサポートしない互換性のない電子メールシステム間で確認に失敗しました。
保証付き配送が必要な多くの場所では、IBMのMQシリーズまたはSterling Softwareの製品（最近IBMが購入）を使用しています。