chuway wrote:
1.樓主要寄往Gmail，Gmail會檢查
2.Anti-SPAM有很多機制，你不知道對方會怎麼用。SPAM要使用SSL/TLS發送，會麻煩很多，一般市售的發送工具通常不會支援(CA要$$$)
1:到目前為止,Gmail並不會拒收沒走SSL/TLS的信件(只是有標示出來)....
2:到目前為止絕大部分的mail server在走TLS時並不會檢查對方有沒有放正式憑證(會接受自簽憑證),原因是SMTP不像HTTPS,TLS negotiation fail時user沒有介入的機會,通常只會斷線後retry,然後繼續fail直到queue expired為止,此時寄件人才會收到NDN發現寄送失敗,而對SMTP而言,Email能否寄達的重要性是遠高於啥TLS不TLS的(RFC3207上用的字眼是MUST NOT require use of the STARTTLS extension)....
3:到目前為止還沒有其他RFC或是業界標準宣告RFC3207已經失效,正常的MX應該都還是會接受cleartext或是走TLS,但沒提供正式憑證的SMTP連線....
),畢竟寄件端有寄信的自由,收件端也有不收的自由(雖然RFC3207上用的是MUST NOT require use of the STARTTLS extension,但管理者要怎麼config還是可以依其自由意志config
),不過SMTP設計時的初衷是確保訊息能成功送達,任何一方要在標準之外加上任何限制(i.e. RFC3207/RFC5321沒要求的部份
),就有義務自己承擔後果,而不是把責任推給對方,像鵝之前被某官衙門complain無法寄到另一個官衙門,會在8小時後收到退信,仔細看後才發現是收件端的MX不知為何EHLO沒回STARTTLS,那寄件端自然會走cleartext,而GSN又很雞婆的把cleartext擋掉了(鵝會說是GSN擋的是因為同時間其他官衙門的客戶都有同樣的狀況....BTW,GSN要擋cleartext不是不行,但好歹回個denied by GSN due to local policy之類,而不是由ISP莫名其妙的把connection drop掉,讓SMTP的雙方都搞不清楚狀況
),那您說這個鍋該由寄件端揹,還是收件端揹,或是GSN揹,亦或是廠商要揹啊
