電子メールが「ベストエフォート」配信のみである場合、配信が保証された同様のプロトコルはありますか？

ファックスは、配達が「保証」されているために受け入れられる文書であるのに対し、法律ではしばしば確立されますが、電子メールは配達ができないためではありません。これは、FAXと同程度の配信を保証するTCPベースのプロトコルを求めているだけではありませんか？そのようなプロトコルは存在し、どの程度定着していますか？

1. ファックス配信は保証されていません-ファックスが失敗する多くの方法があります。いくつか例を挙げると：

   • 誤った番号
   • 紙からFAXを受信する（実現するほどスマートではない）
   • トナー切れのFAXを受信します（実現するほどスマートではありません）
   • FAXの送信時に用紙が逆さまにセットされた
   • FAXの受信は共有デバイスであり、受信したFAXは意図しない受信者によって取得され、破棄されます
     
     

2. SMTPは、IS TCPベースのプロトコル。RFC 821およびその後継RFC 2821およびRFC 5321を参照してください。
   基礎となるネットワークプロトコル（TCP / IP）は、信頼できる配信（アプリケーションプロトコルレベルの問題）とは関係ありません。

3. ほとんどのSMTPサーバーは、どのメッセージ（送信者/受信者/メッセージID）が通過したかのログを保持します。ログが改ざんされた可能性が低いことを証明できれば、裁判所で認めることができます。
   弁護士に相談してください。

4. 配信を保証するために、SMTPプロトコルと関連プログラムに接着されたメカニズムがあります（DSN、返品確認）。これら自体がベストエフォート/相互協力の拡張機能であることに注意してください（ほとんどのメールクライアントは、開封確認を送信しないことを選択できます。一部のクライアントは開封確認を発行できません。
   私はこれらの証拠能力のかどうか分からない-それは裁判所と任意の確立先例に依存するここでも、。弁護士に相談してください。

ファックスは、配達が「保証」されているため、受け入れられた文書であることが法律でしばしば確立されています

送信者と受信者からの電子メールサーバーログは、おそらくFAX受信確認よりも信頼性が高くなります。

確認は、単に「a」ファックスが文書に応答して受信したことを意味します。

サーバーログは、「その特定の」メールボックスに到達する前に、「その特定の」メールボックスが電子メールを受信し、サーバーA、B、およびCを通過したことを確認できます。

カナダでは、メールが法廷で受け入れられることを知っています。大規模な場合、民事訴訟では、サーバーログとメールボックスのコンテンツを押収するためにアントンピラー命令を実行することができます。

配信を保証する唯一の方法は、直接ピアツーピア配信です。送信者は受信者への直接接続を確立する必要があり、受信者は受信を確認する必要があります。メールでないピア・ツー・ピア・プロトコルが、ストア・アンド・フォワードプロトコル。したがって、法廷で受け入れられるような保証はありません。ただし、プロトコルが信頼できるものであることを確認し、チェーン内のすべてのサーバーが適切に機能する場合は信頼できます。

ただし、技術的な配信保証（実際の生活および電子メール/ファックス）では、メッセージの内容は保証されません。ログまたはエンベロープは、配信があったことのみを示しますが、メッセージの内容は表示できません。メッセージに署名しても、途中で操作されなかったことが保証されるだけです。ただし、元の署名済みコンテンツは「Hello world！」のままである可​​能性があります。「あなたは解雇されました！」の代わりに メッセージが送信されたという確認のみがあります。

これは、FAXと同程度の配信を保証するTCPベースのプロトコルを求めているだけではありませんか？そのようなプロトコルは存在し、どの程度定着していますか？

具体的に質問に答えるために-そのような[ネットワーク]プロトコルは存在しません。したがって、同様に前記プロトコルの確立はない。

ただし、このトピックに関連して、「配信」の「保証」の意味または可能性についての意味について、いくつかの重要なポイントがあります。

1. 送信者を認証する手段が必要です。ただし、FAXや電子メールのハンドシェイクプロセスにはこのような機能はありません。「from」FAX番号は、「from」メールアドレスが非常に多くのスパム/フィッシングメッセージに含まれているので、なりすましが可能です。
2. 送信されたものを証明するために転送中に変更されないように、メッセージ自体の否認防止を保証する手段が必要です。繰り返しますが、基礎となるプロトコルはそのような保証を行いません。PKI（電子メールでデジタル署名技術を使用しますが、複雑さ、証明書の期限切れなどにより未使用でもサポートされます）、対称暗号化およびメッセージハッシュと相まって、電子メールで否認防止を提供するのに大いに役立ちます。これらは十分に確立された方法ですが、電子メールのコミュニケーション空間全体に直接ではありません。
3. メッセージが実際に（実際に意図された）受信者に配信されたことを保証する手段が必要です。ログは、上記に関して何も保証せず、メールボックス（受信者ではない）へのおそらく配信を弱くしか注釈しないため、実際には不十分です。これは郵便配達よりもさらに弱いです。商取引法の統一商法（UCC）によれば、合意された住所への配達に加えて、[商品/メッセージ]が利用可能であることを意図した受取人への配達の通信が必要です。電子メールはメッセージをターゲットメールボックスにのみ保存しますが、これは受信者に到着が通知されたことを保証するものではありません。受信者は、メッセージが到着したかどうかを常に「確認」することが義務付けられています。

最後に、配信確認/受信をリクエスト（送信者）および送信（受信者）するためのオプションの（そして、クロスプラットフォームでサポートされていない）電子メールプロトコルがあります。ただし、これはめったに使用されず、保証されず、最後に受信者によるメッセージの受信を反証しません...むしろ、受信者が受信を確認しないことを選択したか、受信者が送信者または配信によって受信しなかった可能性がありますこのオプション機能の同じ/バージョンをサポートしない互換性のない電子メールシステム間で確認が失敗しました。

保証付き配送を必要とする多くの場所では、IBMのMQ SeriesまたはSterling Softwareの製品（IBMが最近購入した）を使用しています。