web-dev-qa-db-ja.com

メール送信時のmutt SMTP TLSエラー

メールを送信しようとすると、次のエラーが発生します。

gnutls_handshake:予期しないTLSパケットを受信しました。

これは私の.muttrcです(myname、myaddress、mymailはプレースホルダーです):

# Automatically log in to this mailbox at startup
set imap_user="myname"
set imap_pass=""
set spoolfile="imaps://imap.myaddress/Inbox"
set folder="imaps://imap.myaddress/Inbox"
set record="=Sent"
set postponed="=Drafts"

# define how to send mails
set smtp_url="smtps://$imap_user:[email protected]:587"

# activate TLS if available on the server
set ssl_starttls=yes

# always use SSL when connecting to a server
set ssl_force_tls=yes

# wait to enter mailbox manually
set imap_passive

# Automatically poll subscribed mailboxes for new mail (new in 1.5.11)
set imap_check_subscribed

# Reduce polling frequency to a sane level
set mail_check=60

# And poll the current mailbox more often (not needed with IDLE in post 1.5.11)
#set timeout=10

# keep a cache of headers for faster loading (1.5.9+?)
#set header_cache=~/.hcache

# Display download progress every 5K
set net_inc=5

# Cancel a message when subject is blank
set abort_nosubject=yes

# Set default editor
set editor="gvim -v"

# Asks to include message when replying
set include=ask-yes

# Asks to postpone a message when not sent
set postpone=ask-yes

# Ask before printing
set print=ask-yes

# set from to ensure mutt doesn't put [email protected] 
set from="myemail"
set use_from=yes
set envelope_from="yes"
17
bug

smtp送信をポート587で使用する場合、smtp_urlの値は"smtp://"で始まる必要があります。つまり、"smtps://"ではありません。上記の構成で正しく行われるように、ssl_starttls"yes"に設定されていることを確認することも重要です。

自分のサーバーをセットアップしているときに、まったく同じ問題が発生しました。クライアント側とサーバー側の両方のログにアクセスできるため、クライアント側の問題であることは明らかです。

smtpsで始まる構成オプションは、サーバーへのssl暗号化接続を開くようにmuttに指示します。ただし、サーバーは、クライアントとサーバーがネゴシエーションを行うとすぐに暗号化されるように転送されるクリアテキストのsmtpセッションを期待しています。

26
sampi

2019年6月の時点で、MuttはTLS1.3では機能せず、TLS1.2のみで機能します。

TLS 1.0、1.1、1.2と互換性のあるgnutls-binパッケージバージョン3.5.8-5 + deb9u4と、TLS 1.0、1.1、1.2、1.3を実装するgnutls-bin 3.6.7-4でテストしている間に、この肯定を得ました!

それは特にGmailでそのように動作するようです。使用可能な最も高いバージョンを使用すると、Hostgatorサーバーでは1.3ではなくTLS 1.2を使用したため、クライアントマシンでは責任がありました。

ある種のSASL-XOAUTH2エラーのように見えます:

TLS1.3を使用したSSL/TLS接続(ECDHE-RSA/AES-256-GCM/AEAD)[SASL-XOAUTH2]-リクエストauthID![SASL-XOAUTH2]-リクエストトークン

0
Vasconcelos1914