「スマートホストフィンガープリント」などはありません。これらはTLS証明書のフィンガープリントであり、このコンテキストではたまたまSMTPリレーサーバー（スマートホスト）に属しますが、ここでのすべてはIMAPS、HTTPS、FTPS ... TLSを使用するものすべてに等しく適用されます。
TLS証明書のフィンガープリントは通常、クライアントにまったく依存していません。これらはサーバーの証明書のSHA1（またはSHA256）ハッシュであり、通常、サーバーは全員に同じ証明書を使用します。
ただし、1つの例外はロードバランサーの背後にあるサーバーです。大規模なサイトでは、単一の名前の背後に複数のサーバーがあり、1つの証明書を共有する場合もありますが、保証はほとんどありません。一度に20または50の証明書も簡単に使用できます。
また、同じサーバーであっても、フィンガープリントが変更される可能性が実際にあります。証明書は、有効期限が変更されるため更新されるか、他の理由（新しい秘密鍵、または新しい発行者、または新しいドメイン名...）
証明書は過去3〜5年間発行されていました（および手動でインストールされていました）が、新しいプラクティスではプロセスを自動化し、短期間（通常90または45 日）の証明書を使用します。Googleは約以来、これを行ってきました。2014年、それがLet's Encryptの初日からの動作です。（CA / Bフォーラムの規則により、「標準」の長寿命TLS証明書でさえ2年に制限されています。）
そのため、このtls_fingerprintオプションが役立つのは、証明書がいつ変更されるのかを正確に知っているときだけです（たとえば、あなたがそれを変更するのであれば）。それ以外の場合は、構成が1〜2か月ごとに中断されます。
実際には、少なくともLinuxディストリビューションはCA証明書パッケージの更新がかなり高速です。（つまり、そうでない場合は、コンピューターでそのOSを実行したいということですか？）
ですから、この記事は読者を間違った問題で怖がらせようとしていると思います。はるかに大きな懸念は、CA証明書パッケージには多くの場合、さまざまな国の政府が管理する日陰のCAがいくつか含まれていることです。
選択肢1：必要に応じて、プロバイダーが使用する単一のCAのみを含むカスタム tls_trust_fileを作成できます。たとえば、msmtpにDigiCertのみを信頼するように指示します。これは、「CA pinning」と呼ばれる一般的な方法です。しかし、サーバー管理者はビジネスを行うCAを自由に選択できるため、まだ破損する可能性があります。
代替案2：一部のプログラムは、異なる指紋タイプ– SPKI指紋（subjectPublicKeyInfoのハッシュ）をサポートしています。これらは生のキーペアのみを表し、追加の証明書メタデータは含まれません。サーバーは、同じキーペア、したがって同じSPKIフィンガープリントを保持しながら、定期的に証明書を更新できます。
（ただし、クライアントがSPKIフィンガープリントをサポートしていても（msmtpはサポートしていません）、サーバー管理者がこの方法で証明書を更新することを知っている場合にのみ利点があります。ほとんどの場合、そうではありません。）