[送信(SMTP)サーバ の設定] にある セキュリティと認証で "ユーザ名とパスワードを使用する" をチェックすると送信が遅くなります。
　　　ポート番号 : 587
　　〆ユーザ名とパスワードを使用する
　　　保護された接続を使用する: TLS (利用可能な場合)

チェックが無いときは瞬時に送信し終わるメッセージがチェックを付けると送信に5秒ほどかかります。

[サーバ設定]の "保護された認証を使う" は、チェックしていませんが、サーバ管理者に問い合わせたところ次の様な回答がありました。

>smtp 認証の設定において、CRAM-MD5 にもチェックが入っていると、いったんpassword fail となり、 5秒後にPLAIN でリトライするようになっているようです。

"ユーザ名とパスワードを使用する" をチェックしても送信が遅くならない様にするにはどうしたらよいでしょうか。

利用環境
　　Thunderbird: バージョン 2.0.0.12 (20080213) Windows 版
　　OS : Windows 2000 SP4

たしか、サーバから「CRAM-MD5 使えるよ」とレスポンスがない限りは CRAM-MD5 でトライすることはないはずですが。
サーバが CRAM-MD5 を受け付けないにもかかわらず

250-AUTH CRAM-MD5 PLAIN

とか返してきていませんか？
サーバ管理者に確認してみてください。

参考：SMTP認証で送信エラー - もじら組フォーラム
http://forum.mozilla.gr.jp/?mode=al2&na ... &&KLOG=173

_________________
[Desktop] Windows 10 Pro 22H2 (64bit) / Intel Core i7-2600 / Nvidia GeForce GTX 1650 GDDR6 / 32 GB Memory
[Laptop] Windows 10 Pro 22H2 (64bit) / Intel Core i5-520M vPro / Intel HD Graphics / 8 GB Memory
[Android] Android 13.0 (arm64) / Xperia 5 III (XQ-BQ42)
常用環境: Firefox ベータ版、リリース版 (Win64 x86-64, Android), Thunderbird ベータ版、リリース版 (Win64 x86-64)
テスト環境: Firefox (ESR, Nightly, Win64 x86-64, Android)
Cai/1.0 (Homo sapiens; N; Homo sapiens chemist; male; rv:0.0.4.2+)
-- いつまでたっても nightly

ユーザ名とパスワードを使用しなくても送信できるのですよね？
だとすると、"使用する" をチェックするのはなぜでしょうか。

何らかの理由でチェックする必要があると仮定して、その管理者の回答は、5 秒間時間をかけているのはメールクライアント側だというような言い方になっていますが、本当にそうでしょうか。
http://forum.mozilla.gr.jp/?mode=al2&na ... 0&KLOG=185
等を参考に、タイムスタンプつきでプロトコルログを取ると、時間をかけているのがサーバ側のなのか Thunderbird 側なのかがわかると思います。
もし Thunderbird 側だとしたら、そのプロトコルログから Thunderbird のどこで時間がかかっているのか見当がつくでしょうから、それを回避するような設定等を探す手がかりになると思います。
もしサーバ側だとしたら、本来はサーバ側でなんとかすべき問題ですが、それが無理なら、Thunderbird 側の設定をあれこれ試してみるしかないかもしれません。

回答ありがとうございます。


"あ"さんに教えて頂いた方法で ログを確認したところ、次の様な行が見つかりました。
　0[284458]: SMTP Response: 250-AUTH LOGIN CRAM-MD5 PLAIN

"SMTP認証で送信エラー" を見ると サーバ側で対応できない様にも見れますが対処法はないのでしょうか。


社内から送信する場合は どちらでも送れますが、外から送る場合は認証が必須になります。


"password fail" に対応する 応答を受け取った後、約5秒間何もしていない様(待機)に見えます。

250-AUTH LOGIN CRAM-MD5 PLAIN より、サーバ側から「CRAM-MD5 使えるよ」と返してきています。
「"password fail" に対応する 応答」が何を指すのかわかりませんが、CRAM-MD5 でも PLAIN でも使うパスワードは同じですから、CRAM-MD5 で通らないのに PLAIN なら通るのいうのが...
やはり「サーバは CRAM-MD5 を返してきているけど本当は対応していない」が原因のような感じがします。

_________________
[Desktop] Windows 10 Pro 22H2 (64bit) / Intel Core i7-2600 / Nvidia GeForce GTX 1650 GDDR6 / 32 GB Memory
[Laptop] Windows 10 Pro 22H2 (64bit) / Intel Core i5-520M vPro / Intel HD Graphics / 8 GB Memory
[Android] Android 13.0 (arm64) / Xperia 5 III (XQ-BQ42)
常用環境: Firefox ベータ版、リリース版 (Win64 x86-64, Android), Thunderbird ベータ版、リリース版 (Win64 x86-64)
テスト環境: Firefox (ESR, Nightly, Win64 x86-64, Android)
Cai/1.0 (Homo sapiens; N; Homo sapiens chemist; male; rv:0.0.4.2+)
-- いつまでたっても nightly

Dbgview.exe がうまく動かないので wireshark を使って整理してみました。

結果、
["password fail" に対応する 応答を受け取った後、約5秒間何もしていない様(待機)に見えます。]
は 私の勘違いでした。

535 authorization failed (#5.7.0) をサーバが返すまで 5 秒間があることがわかりました。

Frame 18 (170 bytes on wire, 170 bytes captured)
SRV -> Client
Arrival Time: Aug 21, 2008 09:38:57.054173000
250-xxxxxxxxxxxx.co.jp
250-AUTH LOGIN CRAM-MD5 PLAIN
250-AUTH=LOGIN CRAM-MD5 PLAIN
250-PIPELINING
250 8BITMIME

Frame 19 (69 bytes on wire, 69 bytes captured)
SRV <- Client
Arrival Time: Aug 21, 2008 09:38:57.069233000
[This is an ACK to the segment in frame: 18]

Frame 20 (100 bytes on wire, 100 bytes captured)
SRV -> Client
Arrival Time: Aug 21, 2008 09:38:57.089460000
[This is an ACK to the segment in frame: 19]
334 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=

Frame 21 (140 bytes on wire, 140 bytes captured)
SRV <- Client
Arrival Time: Aug 21, 2008 09:38:57.092480000
[This is an ACK to the segment in frame: 20]
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==

Frame 22 (60 bytes on wire, 60 bytes captured)
SRV -> Client
Arrival Time: Aug 21, 2008 09:38:57.163846000
[This is an ACK to the segment in frame: 21]

Frame 27 (90 bytes on wire, 90 bytes captured)
SRV -> Client
Arrival Time: Aug 21, 2008 09:39:02.123414000
535 authorization failed (#5.7.0)

Frame 28 (115 bytes on wire, 115 bytes captured)
SRV <- Client
Arrival Time: Aug 21, 2008 09:39:02.150045000
[This is an ACK to the segment in frame: 27]
AUTH PLAIN xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Frame 29 (60 bytes on wire, 60 bytes captured)
SRV -> Client
Arrival Time: Aug 21, 2008 09:39:02.171419000
[This is an ACK to the segment in frame: 28]

Frame 30 (82 bytes on wire, 82 bytes captured)
SRV -> Client
Arrival Time: Aug 21, 2008 09:39:02.171958000
235 ok, go ahead(#2.0.0)

メールサーバの管理者が対応できるといいのですが。

メールサーバの方を修正してもらい、通常の速度で送信できるようになりました。
ありがとうございました。

ああやっぱりそうでしたか。

• CRAM-MD5 が使えるよ、と言っておきながら、実際には使うと失敗するというサーバが間違い
• かつ、サーバが失敗の応答を返すのに 5 秒間かかっているから遅い

という状況ですね。
すでに解決されたようにサーバ側を直すのが正しいのですが、同じ状況の人が後からここを見て、かつサーバ側を直してもらえなかった場合を想定して書いておくと、
設定エディタで mail.smtpserver.default.trySecAuth を false にすれば、CRAM-MD5 は使わずに、PLAIN は使う状態になると思います。

# 隠し設定全般について言えることですが、デフォルトではない設定で使うことになるので、デフォルトでは遭遇しないバグに遭遇する可能性が、ないとは言い切れません。自己責任でお使いください。(っていうか、隠し設定に限らず自己責任ですが)