reject=403 4.7.0 TLS handshake failed (2)

 reject=403 4.7.0 TLS handshake failed

這個訊息總是會出現在我們sendmail的log檔, 之前找到msn.com網域的信, 其實是寄到outlook.com網域去的。這次是另一個類似的案例:

# mailq
Warning: Option: AuthMechanisms requires SASL support (-DSASL)
                /var/spool/mqueue (1 request)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
3781ZYIW045303   164044 Tue Aug  8 09:35 <>
                 (Deferred: 403 4.7.0 TLS handshake failed.)
                                         <bounce-833_HTML-127233725-9424761-700
                Total requests: 1

在mailq裡面看到一封寄不出去的信, 之前查過, 知道這應該是寄到我們合法使用者的廣告信, 收到使用者信箱後, 自動彈回的收到回條! (bounce-xxx...) 我們要求sendmail自動重送queue裡的信, 來看看問題何在?

# sendmail -v -q
Warning: Option: AuthMechanisms requires SASL support (-DSASL)

Running /var/spool/mqueue/3781ZYIW045303 (sequence 1 of 1)
<bounce-833_HTML-127233725-9424761-7002400-1004@bounce.email.savills-asia.com>... Connecting to inbound.s6.exacttarget.com. via esmtp...
220 orionsmtp-172.s6.exacttarget.com ESMTP Postfix
>>> EHLO mail1.princo.com.tw
250-orionsmtp-172.s6.exacttarget.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
>>> STARTTLS
220 2.0.0 Ready to start TLS
<bounce-833_HTML-127233725-9424761-7002400-1004@bounce.email.savills-asia.com>... Deferred: Name server: inbound.s6.exacttarget.com.: host name lookup failure
Closing connection to inbound.s6.exacttarget.com.

可以看到這封要寄到xx@bounce.email.savills-asia.com的信, 居然是傳到xx.exacttarget.com的郵件主機去! 那因為這台郵件主機回應了250-STARTTLS, 所以我們sendmail就下了STARTTLS命令, 要求進入加密通道, 但接著就出現了錯誤訊息: Name server: inbound.s6.exacttarget.com.: host name lookup failure。那是誰的主機名稱沒有設好呢? 我試著用nslookup找了一下:

# nslookup
> bounce.email.savills-asia.com
Server:         10.1.10.8
Address:        10.1.10.8#53

Non-authoritative answer:
*** Can´t find bounce.email.savills-asia.com: No answer
> savills-asia.com
;; Got recursion not available from 10.1.10.8, trying next server
;; Got recursion not available from 10.1.10.101, trying next server
Server:         168.95.1.1
Address:        168.95.1.1#53

Non-authoritative answer:
Name:   savills-asia.com
Address: 217.19.248.132
> inbound.s6.exacttarget.com.
Server:         10.1.10.8
Address:        10.1.10.8#53

Non-authoritative answer:
Name:   inbound.s6.exacttarget.com
Address: 68.232.203.116
> exit

確實bounce.email.savills-asia.com是查不到對應ip的, 看起來不像是我們的設定或軟體版本有問題! 所以, 我就將exacttarget.com在/etc/mail/access檔案裡, 設為不使用TLS. (Try_TLS:exacttarget.com NO 以及 tls_srv:exacttarget.com NO) 然後再來試試重送一次郵件:

# mailq
Warning: Option: AuthMechanisms requires SASL support (-DSASL)
                /var/spool/mqueue (1 request)
-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient-----------
3781ZYIW045303   164044 Tue Aug  8 09:35 <>
                 (Deferred: 403 4.7.0 TLS handshake failed.)
                                         <bounce-833_HTML-127233725-9424761-700
                Total requests: 1
mail1# sendmail -v -q
Warning: Option: AuthMechanisms requires SASL support (-DSASL)

Running /var/spool/mqueue/3781ZYIW045303 (sequence 1 of 1)
<bounce-833_HTML-127233725-9424761-7002400-1004@bounce.email.savills-asia.com>... Connecting to inbound.s6.exacttarget.com. via esmtp...
220 orionsmtp-55.s6.exacttarget.com ESMTP Postfix
>>> EHLO mail1.princo.com.tw
250-orionsmtp-55.s6.exacttarget.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
>>> MAIL From:<> SIZE=165559
250 2.1.0 Ok
>>> RCPT To:<bounce-833_HTML-127233725-9424761-7002400-1004@bounce.email.savills-asia.com>
>>> DATA
250 2.1.5 Ok
354 End data with <CR><LF>.<CR><LF>
>>> .
250 2.0.0 Ok: queued as 27DE514004F
<bounce-833_HTML-127233725-9424761-7002400-1004@bounce.email.savills-asia.com>... Sent (Ok: queued as 27DE514004F)
Closing connection to inbound.s6.exacttarget.com.
>>> QUIT
221 2.0.0 Bye
mail1# mailq
Warning: Option: AuthMechanisms requires SASL support (-DSASL)
/var/spool/mqueue is empty
                Total requests: 0

可以看到, 這樣就把信寄過去了, 所以到底是什麼問題? 用TLS加密通道, 對方就會回主機名稱找不到, (但我看不出來到底是那個主機名稱找不到!)不用TLS, 那就正常. 總之, 由mailq來看問題, 再由sendmail -v -q重現狀況, 提供了一個不錯的除錯方式。