技術者以外のユーザーは、メッセージが「安全に」送信されたことをどのように確認できますか？ ...またはTLSを介して？
B2BおよびB2C通信を安全に送信し、ほとんどのSMTPハイジャッカーに表示されないようにする必要がある状況です。私は陰謀説やNSA=スタイルの攻撃は気にしませんが、能力の低い攻撃者にPIIデータが公開されることを望まない個人に適切なセキュリティを提供したいと考えています。
このビジネス要件はマサチューセッツ州のデータプライバシー法に由来しており、技術的要件をこれ以上詳しく説明することなく、居住者のPIIを「暗号化」して送信する必要があります。
私たちのクライアントのビジネスは、Eメールと生命保険、健康保険、その他の金融商品のPIIを送信する機能に大きく依存しています。
そのため、私はTLSを使用して、その遍在性、使いやすさ、および金融コンプライアンス要件とうまく連携していることから、このセキュリティを提供するつもりです。私は、パートナーのMTAと私たちのMTAの間に直接TLSトンネルを作成することを想定しています。 （強制TLSは便宜的ではありません）
問題は、TLSの「セキュリティ」がSMTPヘッダーに埋め込まれており、理解が困難であり、管理の境界を明確にすることが難しいことです。例えば.
company1 ----> MSFT Hosted Relay --> [TLS between providers] ----> Google Hosted --> Company 2
company1 ----> Proofpoint --> [TLS between providers] ----> Google Hosted --> Company 2
質問
保険会社が電子メールメッセージ（本文または添付ファイル）でSSNを送信する必要があると仮定します。ネクストホップMTAは、Gmail、Yahoo、またはその他の信頼できるプライベートMTAです。
メッセージがTLS経由で安全に送信されたことを受信者に確信させるにはどうすればよいですか？
この保証を得るのに役立つ代替の技術的ソリューションまたはRFCは何ですか？ （おそらくDMARC/DKIM + TLSのバリアント？）
あなたの目的はねじを打ち込むことであり、ハンマーが1つあり、使いやすいのでハンマーを使用したいと考えています。最も可能性の高い結果は痛みです。
TLSは基本的にポイントツーポイントのセキュリティに関するものです。データではなく、接続にのみアタッチされます。一方、電子メールは基本的に複数のホップを跳ね返すように設計されています。ホップはそれらのアクションを追跡するスタンプを残しますが、悪意を持たない（各ホップはその前任者のスタンプを含むメッセージ全体を偽造できる）、だまされない（たとえば、前任者を誤って認証する）のはホストに依存します。そして、あなたが期待する切手を残すこと。
送信者が作成した署名付きの暗号化されたメッセージを配信することにより、メッセージが安全に送信されたことを受信者に信頼させることができます。 TLSはこれには役立ちません。あなたに役立つRFC RFC 3156 、 RFC 488 （OpenPGPメッセージ形式）、 RFC 575 および RFC 5751 （S/MIME）。
つまり、PGPまたはS/MIMEを使用します。
実際、どのような場合でも実際に保証を与えることはできません。 guarantee特定の電子メールwillが各ホップでTLSによって保護されることは確実ではありません。これは、関連するサーバーが日和見的に行い、関連するサーバーのリストが予告なく変更される可能性があるためです（動的ルーティングは、SMTPレベルでも、高度に使用されるサーバーでは一般的です。 wasが送信された電子メールの場合でも、関連するサーバーがそれを示すのに十分親切である限り、接続がTLSで保護されていたかどうかを確認できます（そして、Received:ヘッダーのみで） ）、そして同じように、同じサーバーがlieについて親切でない場合に限ります。
Received:ヘッダー内のデータの形式は純粋に従来のものであり、標準ではなく、すべてのサーバーが同じ形式を使用するわけではありません。このヘッダーは、少なくとも初期のRFCライターの社会環境に一致する「人間」の概念では、人間が読めるようにすることを目的としています。お気づきのように、すべての顧客が「そのような人間」であると期待できるわけではありません。
さらに重要な点は、Received:ヘッダーは、が受信された電子メールでのみ表示されることです。他の人から他の人に送信された電子メールを読みたいと思っている邪悪な個人を想像してみてください。その邪悪な個人が<ここにお気に入りのスパイ機関を挿入>である場合、SMTPサーバーをホストしている場所の1つでインターンを買収する必要があります。しかし、悪者がフリーランサーであるとしましょう。彼は、SMTPサーバーG（ "Gahoo"として）からSMTPサーバーY（ "Ymail"として）（もちろん架空の名前）に転送されている間に、電子メールを傍受したいでしょう。そのため、彼は DNS poisoning として知られる貧乏人のMitMを採用しています。SMTPサーバーGの目にはSMTPサーバーYを装います。
Gが接続すると、攻撃者はTLSをサポートしない（または、不正な証明書を使用したTLSをサポートするなど）と主張します。その後、Gは非TLSに正常に低下し、「現状のまま」メールを送信します。次に、悪者はnot電子メールの受信を確認し、代わりに突然接続を切断します。 SMTPサーバーGは、その発生をランダムなネットワークエラーと見なし、再試行します。今回は実際のYサーバーに接続し（攻撃者によってリレーされた可能性があります。問題ではありません）、TLSを実行し、電子メールを送信します。受信側では、攻撃者のマシンで終了した中止された非TLS転送の痕跡はありません。メールにはReceived:ヘッダーが多数含まれていますが、これらはすべてTLSが使用されたと主張しています-successfulメール接続についてのみ話しているためです。
電子メールが十分に保護されていることを保証することはできませんが、十分に保護されている技術者以外の顧客を説得することに成功する可能性があります。たとえばnotによって上記のいずれかを彼に伝える...
つまり、メールは安全ではなく、決して安全ではありません。電子メールのセキュリティを確保するには、真のエンドツーエンドのソリューション、つまりPGPまたはS/MIMEが必要です（これらは適切に採用されているものの、規定されていません）。
上記の特定のケースでは、既知のTLS対応プロバイダーから既知のTLS対応レシーバーに送信します（不便なサードパーティのバックアップMXはありません）。パスは信頼できますが、受信者には方法がありません。途中でTLSが使用されている場合は、Receivedヘッダー（または各ホップのSMTPログ）を分割する以外の方法で確認します。
SMTPの保存と転送の性質を考えると、一般的なケースでは、特定のメッセージが送信されることを事前に知ることができません（送信者）すべてのホップでTLS接続のみを使用して到着します。
私の知る限り、相互運用可能な方法はありません1 メッセージごとにSMTPサーバーにTLSのみを使用するように指示する。一部の電子メールクライアントのDKIM視覚インジケーターのように、MUAがそれを示す一般的な方法はありません。 Receivedヘッダー形式がMTAごとに異なることを考えると、それは、より難しい問題と思われるかもしれません。
非技術的なユーザーベースでは、1つの代替案は暗号化されたPDFである可能性があります。これには共有秘密の要件が伴いますが、これも必須のコンテンツ検査ポリシーに違反する可能性があります。
一般的に使用されるもう1つの代替手段（これも共有シークレットまたは認証の要件があります）は、コンテンツへのHTTPSリンクを電子メールで送信することです。
mxtoolbox であってもTLSの詳細の解析から遠ざかっていますが、理論的には可能ですが、ヘッダーをカットアンドペーストする方法をユーザーに示すこともうまくいっていると思います。
TLSソリューションはあまり適していません。それはレイヤー5（セッション）であり、レイヤー7（アプリケーション）レイヤーのセキュリティを提供しようとしています（そして、3つすべての を飲み込まないでください）。機密性、完全性、認証 苦い錠剤...）
1SalesForceX-SFDC-TLS-NoRelayヘッダーは独自の方法であるようですが、ドキュメント化された意図が見つからないため、ここでは推測しています。
解決策は、PIIを電子メールで送信しないことです。 TLS暗号化されていること、また消費者や保険代理店が簡単にアクセスできることを確認できるWebサイトを介してその情報を送信します。
同じ質問があり、mxtoolbox.com（現在）がSMTPサーバーをクエリしてTLSをサポートしているかどうかを報告するインターフェイスを提供していることを発見しました。これが、TLSが導入されていることを示すことができると思われる唯一の証拠です。
PIIをクリアテキストの電子メールで送信してはなりません。ネットワークホップがTLSで保護されている場合でも、データが保存時に暗号化されているかどうかはわかりません。多くの場合、データはサードパーティまたはフォースパーティで利用できます。特にGoogleはユーザーのメールをふるいにかけて、どの広告を表示するか、スパムのパターンを検出するかを調べます。関連するさまざまなシステムすべてが適切に安全または準拠していることを確認することはできません。そして、たとえそうであったとしても、たとえば、顧客の1人に勃起不全について「プライベート」にメールを送信すると、評判が著しく損なわれる可能性があります。 。
2つの選択肢が思い浮かびます：
PGPのような暗号化スキームでメールのcontentを保護します。
内容をメールに記載しないでください。代わりに、ユーザーがサインインしてコンテンツを表示できるサイトへのリンクを提供します。これは、たとえばCitrixセキュアエンベロープサービスが機能する方法です。
安全な電子メールの問題へようこそ。あなたのオプションを見てみましょう：
SMTP
プロトコルレベルでは、SMTPにセキュリティの概念はありません。ほとんどの初期のインターネットプロトコル（私はDNSを調べています）と同様に、悪意のあるサーバーが周りにないことを前提に設計されています。ここの他の回答に記載されている理由により、SMTP経由で送信されたものについては何も想定していない
PGPまたはS/MIME
どちらもアプリケーションレイヤーオーバーレイであり、基本的に安全でない下位レイヤーを保護します。これはすばらしいことですが、どちらも機能するためには（ユーザーの）ネットワーク効果が必要であり、問題はどちらも非対称暗号化の避けられない使用法から継承されます（PKI問題）。 （アプリケーションとしての）電子メールが地球上で最も多くのインターネットユーザーを持っていることを考えると、すぐに変わるとは思いません。 B2C（多くのB2Cでも）の状況では、運が悪いです。
間接層（別名「セキュリティの錯覚」）
これはまったくセキュリティを提供しませんが、PIIを送信しないことに関するMAの法律に準拠しようとしている場合は、GUIDベースのリンクを電子メールで送信できます。クリックすると実際のリンクが表示されます。ブラウザでの情報OR PIIテキストが実際に電子メールクライアント内のSSL経由でロードされた画像であるHTML電子メールを使用します。技術的には、安全でないトランスポートを介して実際のPIIを送信していません。あなたに言う必要はありませんが、これがあなたのビジネスリスクをカバーするなら弁護士に相談する必要があります。
ビジネス要件を変更します（<==推奨）
個人的に、これは私が選ぶものです。まず、PIIをメールで送信することは避けます。これが新規顧客（B2C）へのメールマーケティングである場合、PIIをコールドメールに入れることで、実際にそれらを忍び込ませることができます。これらの顧客（B2C）を既にお持ちの場合は、ログイン画面の背後にWebベースのメッセージングセンターを設定することをお勧めします（ビジネスに他のサービス用のログインポータルがあると想定しています）。正直なところ、これは、経験している正確な理由のためにほとんどの銀行や病院で採用されているアプローチです（まだ他の人が好きではありませんメッセージングポータルですが、強制されます）。こうすることで、PIIのない通常のメールを大量のメールに使用できます。PIIが必要な場合は、Webポータルにエスカレートしてください。安全なメッセージングポータルの組み込みを（SSO統合と共に）予算に入れ、「電子メールでPIIを送信する必要がある」というビジネスニーズを作成する意思決定者に提示し、価格に見合う価値があるかどうかを彼らに決定させます。