目前郵件收發正常，只有該客戶有此情形，如下是客戶收到的退信內容，防火牆和mailserver並沒有將該客戶列為黑名單，我司寄去給對方的信可以正常接收，請問該情況如何處理?
目前有將對方的MX主機IP設為白名單也是不行
This is a return mail sent by system automatically, please do not reply this mail.
Your mail can not be delivered successfully due to the reason below:
Response Message :
To: ABC@test.com.tw
Subject: TEST
Remote host: XXX.XX.XX.XXX
Remote server replied: 220 2.0.0 Ready to start TLS
6/12
客戶說在寄信時會產生"Socket Error # 10054 Connection reset by peer"的錯誤訊息
6/13[解決]
後來想了一下有在5月初將原本使用Let's Encrypt憑證因過期而改回SERVER預設的SSL憑證，嘗試在改回去後MAILSERVER現在有正常收到該客戶的MAIL了，雖然還不知道為何只有該客戶受影響就是了。
已邀請的邦友 {{ invite_list.length }}/5
TLS握手失敗？
220 2.0.0 Ready to start TLS
所以在加密層就被收件方的伺服器拒絕，自然不會被應用層的Mail Server記錄
TLS失敗
若上面是客戶端收到的錯誤訊息，
那有可能就是客戶的Server不支援TLS
也就是你們的SERVER打開了TLS，並只接受TLS連線，已經不接受未加密的連線
可是實際上3.4月時客戶還有成功寄信給我們過耶?不過我先請他們先測試看看
可能是你們的SERVER最近有自動更新或是重開機過之類，就強制使用TLS了(default值被更改)
這情況，要不就是你們把TLS限制取消，客戶才能寄進來。
要不就是客戶的SERVER要更新為TLS傳輸，才有辦法跟你們的server連線，
首先傳輸協定要一致，都用相同的例如TLS，兩台主機才能翻譯溝通並建立連線，不然主機會搞不懂對方到底再說啥......
建立連線之後才有接下來的寄送流程，也才會有mailserver的log。
4/26前還收的到對方的信
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 220 ESMTP MAIL Server
14:52:43 < mx.oooooo.com.tw[oo.oo.ooo.oo]: EHLO mx.oooooo.com.tw
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-mail.xxxx.com.tw
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-PIPELINING
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-SIZE 25600000
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-VRFY
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-ETRN
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-STARTTLS
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-AUTH PLAIN LOGIN
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-ENHANCEDSTATUSCODES
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-8BITMIME
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-DSN
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-SMTPUTF8
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250 CHUNKING
14:52:43 < mx.oooooo.com.tw[oo.oo.ooo.oo]: STARTTLS
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 220 2.0.0 Ready to start TLS
14:52:43 < mx.oooooo.com.tw[oo.oo.ooo.oo]: EHLO mx.oooooo.com.tw
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-mail.xxxx.com.tw
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-PIPELINING
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-SIZE 25600000
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-VRFY
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-ETRN
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-AUTH PLAIN LOGIN
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-ENHANCEDSTATUSCODES
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-8BITMIME
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-DSN
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250-SMTPUTF8
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250 CHUNKING
14:52:43 < mx.oooooo.com.tw[oo.oo.ooo.oo]: MAIL FROM:<ooo@oooooo.com.tw> SIZE=305315
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250 2.1.0 Ok
14:52:43 < mx.oooooo.com.tw[oo.oo.ooo.oo]: RCPT TO:<xxx@xxxx.com.tw>
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250 2.1.5 Ok
14:52:43 < mx.oooooo.com.tw[oo.oo.ooo.oo]: DATA
14:52:43 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 354 End data with <CR><LF>.<CR><LF>
14:52:47 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 250 2.0.0 Ok: queued as E574D208006D
14:52:47 < mx.oooooo.com.tw[oo.oo.ooo.oo]: QUIT
14:52:47 > mx.oooooo.com.tw[oo.oo.ooo.oo]: 221 2.0.0 Bye
韌體更新是在3/12,後來出現寄送問題後在6/9在韌體到最新還是不行
客戶那邊是說他們也沒使用TLS加密寄信
你貼的TLS加密設定的說明說內送是預設開啟TLS，且無法關閉!?
會不會跟這個有關係
看log....客戶那邊應該是有啟動TLS ?
對方是說沒有啟動TLS,有請對方去查log,看到"Socket Error # 10054 Connection reset by peer"的錯誤訊息
現在頗多public mail server只接受TLS1.2或以上TLS版本,若對方只支援TLS1.0/1.1時會造成TLS negotiation failed後斷線,retry時還是會因為同樣的原因繼續fail,因為此時根本還沒進入SMTP session,所以查SMTP的log是查不到的,解決的方法就是把這類server的TLS徹底關掉----因為還沒人敢把cleartext關掉,所以至少可以確定信可以寄到,那鵝可以說cleartext比TLS1.0/1.1安全嗎
....
我們的mail server寫說支援TLS1.0~1.3
內送預設是開啟無法關閉端看對方是否啟用加密
mail server如果是postfix的話試試"grep -iE '(tls library problem|lost connection after starttls)' maillog",看會顯示啥....
感謝回覆，後來解決的方法放在上方了
有些mail server會要求正式憑證,用前面的grep就會看到unknown certificate之類的log....
老實說我覺得您的回答最詳細，但我似乎是最先猜中的
後來仔細看了一下，無法接收到的ssl憑證的主體名好像有問題，可能對方在判斷域名是否與憑證相符比較嚴格，應該是這個原因導致該客戶的信接收不到，雖然不曉得為何其他客戶沒受到影響就是了...
HTTPS因為瀏覽器可以問使用者要不要接受某些憑證,所以接不接受非正式憑證問題還算小,而mail server間的TLS/SSL因為沒有user介入的機制,為了確保Email能成功傳遞,一般是不會設定成只接受正式憑證的,因為絕大部分mail server根本沒放正式憑證上去,設定成只接受正式憑證的話老實說只是在找彼此的麻煩而已....
PS:依據RFC3207,對公眾提供服務的SMTP server(就是指各domain的MX)是不可以強制對方一定要加密的,因為這樣會損害Internet上各server間的互聯性,這應該可以延伸解釋為不可以強制對方要走特定TLS版本/Ciphersuite或有沒有正式憑證才對....
照您的說法是mailserver的系統一般並不會主動去判別對方的憑證的正確與否?這樣的說法對其他客戶的狀況可以說得通，確實也只有該客戶有這個問題...
鵝常常被user拿著一堆他自己看不懂的弱掃報告來要求這個關掉,那個關掉的,鵝之前還會回他說你確定要關嗎,可能會造成無法預期的狀況喔,大部分user都嘛回沒問題,有問題他負責,可是出問題時還是來亂盧一通,所以現在只要有user再來扯這些假議題,鵝就直接按最嚴格的標準幫他config,然後把RFC3207截給他標示說"You have been warned.",等他受不了時要他付service fee才幫他調回來....
iThome鐵人賽
看影片追技術