sendmail
を使用してEC2インスタンスでAmazon Linuxを実行します。 Network Solutionsのメールアカウントを持っています。そのアカウントをsendmail
構成でSMART_Host
リレーとして使用しています。細かい点を除けばうまく機能します。
私のmaillog
ファイルには、次のようなエントリがあります。
sendmail[28450]: STARTTLS=client, relay=mail.example.com.netsolmail.net., version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256
少し調べた結果、verify=FAIL
は基本的に無害であるという結論に達しました。接続は実際には暗号化されていますが、ホストの証明書を検証できなかっただけです。
私以外は誰もログファイルを読み取らないので、気にしません。しかし、メッセージが到着すると、Received
ヘッダーは
Received: from unknown (HELO example.com) ([email protected]@12.34.56.78)
by 0 with ESMTPA; 15 Aug 2016 07:10:15 -0000
with ESMPTSA
を見たいと思っていましたが、証明書の検証に失敗したため、「S」が抑制されたと思います。
証明書のどこに問題があるのか、また検証の失敗をどのように回避できるのか。私の推測では、mail.example.com.netsolmail.net
の複数のサブドメインは証明書の名前と十分に一致していません。しかし、どのようにしてそれを確認し、どのようにして苦情を回避できますか?より正確には、Received
ヘッダーを取得してESMTPSA
との安全な接続を確認する方法を教えてください。
編集:私はsendmail.mc
を編集して追加しました
define(`confLOG_LEVEL', `15')dnl
メールログに詳細が表示されるようになりました。 verify=FAIL
行の直後に次のように表示されます。
sendmail[30706]: STARTTLS=client, cert-subject=/OU=GT39680792/OU=See+20www.rapidssl.com/resources/cps+20+28c+2915/OU=Domain+20Control+20Validated+20-+20RapidSSL+28R+29/CN=*.hostingplatform.com, cert-issuer=/C=US/O=GeoTrust+20Inc./CN=RapidSSL+20SHA256+20CA+20-+20G3, verifymsg=unable to get local issuer certificate
これは、検証エラーの少なくとも1つの原因は、sendmailが実行されているローカルマシンの証明書を見つけられないことであると考えていますか?私は送信メールをnetsolサーバーに中継するだけで、インターネットからの受信メールは決して受け入れないため、このサーバーの証明書が必要だとは思いませんでした。必要な場合は、どこにどのようにインストールしますか?そして、それは私のウェブサーバーに使用するのと同じ証明書にすることができますか、それとも別のものが必要ですか?自己署名証明書の使用は、Received
ヘッダーにwith ESMTPSA
を示すのに十分でしょうか、それともCAからの商用証明書である必要がありますか?
編集#2:
@MadHatterによる回答を受け入れます。キーはconfCACERT
を定義していました。私は恥ずかしいですが、私の唯一の言い訳は、古い老年期の脳がm4ソースをグロッキー化しないことです。 Amazon Linuxのデフォルトのsendmail.mcファイルにはすでに
define(`confCACERT_PATH', `/etc/pki/tls/certs')dnl
define(`confCACERT', `/etc/pki/tls/certs/ca-bundle.crt')dnl
その中に、ファイルが存在することを確認しました。 しかし実際にはこれらの行の先頭にある卑劣な小さなdnl
に気付かなかった!私はそれが何を意味するかを知っていますが、m4ソースをめったに見ないので、dnl
- ed行が#
でコメントとしてマークされた直後だったので、私の脳はそれらを-として登録しましたnotコメントアウトされています!
私は実際に、Firefoxから証明書をダウンロードし、ウェブサイトで使用するDigicert証明書をsendmailに向ける一連の旋回を行いましたが、このホストは、送信、受信、電子メール送信のみを行うため、他に必要なものはありません。私はdnl
をconfSERVER_CERT
とconfSERVER_KEY
の定義に戻しましたが、すべて順調で、maillog
はverify=OK
とverifymsg=ok
を示しています適切なSTARTTLS=client
行。
ただし、TLSに関する診断がなかったとしても、netsolへの接続のReceived
ヘッダーにはwith ESMTPA
が表示され、with ESMTPSA
は表示されません。まあ、@ MadHatterもその上にドープを持っていました。申し訳ありませんが、これはとても長く、野生のガチョウの追跡でした。しかし、私は多くのことを学びました、そして私は私の構成を改善しました(重要でない方法で)。これを乗り切るのに十分な必死の誰かが何かを学ぶかもしれないと思います。
これは非常に多くの点で問題であり、私はそのように受け止めます。私は数十年にわたってsendmail
を私の優先MTAとして使用してきましたが、その専門家であるとは言えません(つまり、私はEric Allmanではありません)。
verifymsg=unable to get local issuer certificate
これは、検証エラーの少なくとも1つの原因は、sendmailが実行されているローカルマシンの証明書を見つけられないことであると考えていますか?
これは MTAのメッセージではなく、OpenSSLメッセージ のようであり、私が理解しているように、確認アプリが発行者の証明書のローカルコピーを取得できないことを意味します。つまり、sendmailは、リモートサーバーの証明書を発行した人のルート証明書を含む証明書バンドルにアクセスできません。 Linuxは一元化された証明書管理サービスを提供していないため、各アプリは独自のバンドルをロールバックする必要があることに注意してください。私の場合、sendmailに次のm4コードを含む証明書バンドルへのアクセスを許可しました。
define(`confCACERT', `/etc/pki/tls/certs/ca-bundle.with.intermediate.crt')dnl
ESMPTSAで確認することを望んでいましたが、証明書の検証の失敗により「S」が抑制されたと思います。
推測は間違っていると思います。 RFC2821と2822は、Received:ヘッダーの形式についてかなり柔軟であり、ESMTPA
とESMPTSA
(sic)を区別するものは何も見つかりません。私のヘッダーはすべて次のような行を示しています:
Received: from example.com (example.com [80.70.90.61])
by lory.teaparty.net (8.14.4/8.14.4) with ESMTP id u6G25OXi006577
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
for <[email protected]>; Sat, 16 Jul 2016 03:05:24 +0100
レシーバーのMTAがESMTPA
で何を意味するかを理解するには、そのMTAが何であるかを調べ、ドキュメントを読む必要があります。あなたがそれをするまで、私はあなたがその手紙の集まりに多くを読むことができるとは思いません。
Starttlsを回避できますか
verify=fail
サーバーのホスト名が証明書と一致しない場合
できないと思います。 SSLの背後にある根本的な考えは、(a)接続するホスト名(b)信頼できるサードパーティ(c)が署名した証明書を、CNまたはSANフィールドこれらのプロパティのいずれかが満たされない場合、SSLはピアのIDを検証できないことを通知するのは当然です。
読みすぎないようにしてください。自己署名証明書は、依然として電子メール処理で非常に一般的です。私が最後に送受信した1919のTLSで保護された電子メールのうち、1764には、なんらかの理由でIDを検証できなかったピアが含まれていました。あなた自身が自己署名証明書で実行しています。したがって、ほとんどの人がSMTP TLSピアの信頼チェーンを気にしないことを嬉しく思うはずです。