SERVICES

• 被加入RBL黑名單該到那裡查詢及解除呢？
• 被加入O365/Hotmail黑名單該到那裡查詢及解除呢？
• 被加入Yahoo黑名單該到那裡查詢及解除呢？
• 被加入AT&T黑名單該到那裡解除呢？
• 被加入Trend Micro黑名單該到那裡查詢及解除呢？
• 被加入Gmail or google黑名單該到那裡查詢及解除呢？

 被加入RBL黑名單該到那裡查詢及解除呢？

1. 被加入RBL黑名單該到那裡查詢及解除呢？

   www.anti-abuse.org

2. 確認嚴重程度

   如果被列在cbl.abuseat.org 或是pbl.spamhaus.org以及psbl.surriel.com，這三家RBL的任一名單內，那就確定貴單位一定發生異常發信，一定要找出原因，因為這3家RBL會被許多信箱服務網站及垃圾信過濾機制單位參考,應會產生多數寄信被退回的情況。如果不是這三家RBL，但仍需仔細檢查IP是否有發出異常信件？ 如已查證確實沒有異常信件，可以直接先做解除黑名單的動作,只是單純被同網段其他IP牽連到。

3. 解除技巧

   只需要在RBL網站中查看紅色的RBL即可，有link可點，請點入，並依網站說明解除;如果沒有link可點，則需另外到google或 yahoo網站查詢網友的經驗分享，目前大致上有幾種申請方式

   A.要付費才能解除:(並不建議使用,因為每列入一家就要付一次,而且也不是付費後有保固期,故建議無需處理)
   如: dnsbl-1.uceprotect.net 及dnsbl-2.uceprotect.net 

   B.網頁直接申請解除:有的需要填先基本資料如b.barracudacentral.org ,有的則直接申請該ip解除

   如: http://www.spamhaus.org/query/ip/ip---> 按removel center 以及 psbl.surriel.com 還有 ubl.unsubscore.com, cbl.abuseat.org 還有一種如果有反解就能直接線上解除,但如果沒有就不能解除者,例如spam.spamrats.com 及 dyna.spamrats.com. bl.spamcannibal.org 最好由管理者自行點入申請,因為它會偵測目前上線申請者的IP

   www.spamcannibal.org

   選右上方的contact,它會立刻偵測您的ip,下方會需要您輸入資料後應可解除. 

   提醒: cbl.abuseat.org 移除網址更動為 https://www.abuseat.org/lookup.cgi

   C.會員制-登入帳號後才能解除:如dnsbl.sorbs.net 及Cisco (Sorbs.net還會偵測申請者的ip,建議最好不要代為處理,除非能使用該被加入黑名單的網段申請,以免產生申請困難的情況).

   1. 提醒您,Cisco己無提供來賓登入帳號;但有提供網站查證貴司列入的情況

      https://talosintelligence.com 請在Reputation lookup 問號處查詢貴司ip,將可查到是否列入黑名單

   2. 有提供support網址

      (請點選此處連結) 最好事先準備好ip的反解申請及SPF申請

   
   

   D.無法接受申請:例如QQ被加入後只能等待自動移除約30天。

4. 暫時解法

   找到原因申請解除黑名單需要等待時間，如果急於寄送郵件有以下的做法 

   A.通知對方管理者將發送主機ip加入白名單中

   B.全部更換IP 

   1. 不直接寄出,再跳到另一台主機做寄送-例如原本由mail server寄送,改再設smart host,將信送到我方產品(SPAM/MSE)再寄出.(但是這種方式必須是二台設備各自有獨立的ip).
   2. 有備源線路,可做ip切換.
   3. 最不得已的做法是換一個實體ip,並且要修改dns記錄.(需要1天以上時間做DNS同步).

   C.部份更換IP-將暫時將無法寄送的網域做設定

   1. 使用MSE系統之中繼主機功能(並設定收件域名)
   2. 將無法寄送的網域,轉給出口IP的電信線路公司的轉發主機
   3. 或者向中華數位業務單位借測試轉發主機.(限出口主機為我方客戶者)

 被加入O365/Hotmail黑名單該到那裡查詢及解除呢？

申請解除黑名單或客服中心的網站如下: 

(請點選此處連結)

當O365/hotmail客服中心回信時,就是被解開的時候了.

注意:上面的申請解除,請一定要先查rbl,因為如果在rbl內, 那麼先去申請O365/hotmail多半是失敗的

 被加入Yahoo黑名單該到那裡查詢及解除呢？

網站反應

(請點選此處連結)

操作流程

1. 先在此網頁任意按一個常見問題
2. 按右上角-與我們聯繫
3. 填表格 (帳號指的是email @yahoo.com的前面為帳號)
4. 選擇服務方式
   • A.聯絡客服人員 (請選此項)
   • 查看產品服務說明(跳回第1步的常見問題區)
   
   
5. 選擇主題-郵件管理員基本知識
6. 選擇副題-SMTP錯誤-信件受阻或延遲
7. 選擇服務方式 -與信件客服人員聯絡
8. 填入表格,說明問題細節後送出

 被加入AT&T黑名單該到那裡解除呢？

請使用申訴網頁處理 (請點選此處連結)

 被加入Trend Micro黑名單該到那裡查詢及解除呢？

請寄信到此信箱 abuse_rbl@abuse-att.net

 被加入Gmail or google黑名單該到那裡查詢及解除呢？

請使用申訴網頁處理 (請點選此處連結)

Back

發生原因： 因為寄件人使用了outlook TFG/TNEF格式 解決方式：唯有寄件人才能真正解決 先確認原始的outlook設定裡的[格式]，有沒有用到RTF格式？ (其他二項如純文字或HTML格式皆可) 。 寄信時，只要在打上收件人時，再度點選，確認該收件人並不是使用outlook Rich Text(RTF)格式傳送，其他二項皆可。 如果已這樣使用還是有問題，請砍掉收件人的通訊錄，重新建立一次,並使用純文字的方式寄信。 使用可支援解析收信方向winmail.dat附件的軟體或可以直接做附件檔案轉換,例如SPAM SQR 全方位郵件過濾或是Mail SQR Expert 電子郵件管理系統。 請寄件人把收件人的通訊錄砍掉，重新開一張新文件寄信，並仔細檢查，用的是純文字或HTML寄信，才不會因為outlook的自動記錄功能，一直保留要用RTF格式寄給對方，對方就會收到.dat的檔案。

深入研究

如果不了解 TNEF 的電子郵件用戶端，收到一則含有TNEF資訊的訊息時，通常會出現下列三種結果：  收到純文字版的訊息，其中含有一個名叫 Winmail.dat 的附件。當您開啟 Winmail.dat 附件時，會發現它不含任何有用的資訊，因為它是採用特殊的 TNEF 格式。 收到純文字版的訊息，其中含有一個具一般名稱 (如 ATT00008.dat 或 ATT00005.eml) 的附件。這時候，用戶端認不得訊息的 TNEF 部份，但它認得 Winmail.dat 檔名，因此會建立一個檔名來存放 TNEF 資訊。 收到純文字版的訊息，但用戶端略過 Winmail.dat 附件不處理。這種情形會出現在 Microsoft Outlook Express。Outlook Express 並不了解 TNEF，但它知道要略過 TNEF 資訊不處理。因此您只會收到純文字訊息。

參考資料

RTF 格式是 Microsoft 使用的格式 只有以下電子郵件應用程式支援 RTF 格式： Microsoft Exchange 用戶端 4.0 及 5.0 版 所有 Outlook 版本 詳細內容  Mac OS X Mail：winmail.dat 附件是什麼？ 詳細內容

Back

1. 產生原因：中國官方管制 

   出現這種錯誤是由中國的GFW(簡寫)造成的，(英文全名為The Great Fire Wall of China)，意指”中國網路防火牆”，這是中國國家網路的監控系統，俗稱”防火長城”，GFW是”金盾計劃”的一個子功能，”會對境外涉及敏感的網站，IP地址，關鍵字或關鍵詞，網址做過濾，而且會導致暫時或永久性無法連線。

   詳見:http://wenwen.soso.com/z/q196436143.htm

2. 被管制後的退信訊息。 

   551 User not local; please try <forward-path>

3. 被管制後收到被改變的信件內容

   如aaaazzzzzz

4. 如何解決？

   如果是中國與台灣之間的連線，建議走VPN，或使用加密傳輸

Back

outlook收信軟體的調整方式

在outlook預覽信件模式下，點選功能鍵檢視→排列→自訂。 欄位→寄件日期→新增→將會出現在右側的顯示欄位中→按下確定後，即完成設定。 設定後即可看到原始寄信時間，與事後重送及轉寄的時間。

outlook express收信軟體的調整方式

在outlook express預覽信件模式下，點選功能鍵檢視→欄位。 檢視→欄位→傳送日期→按下確定後，即完成設定。 設定後即可看到原始寄信時間，與事後重送及轉寄的時間。

Back

本系統的計算方式是以整封信的大小來看，而非單指附件檔的大小 。

Back

1. 詳細原因說明 

   當一封郵件經由SMTP伺服器處理，準備寄發出去的時候，因為不管Client發出的信件為TXT純文字格式或是HTML格式，以及是否有夾帶任何附件檔案的時候，通通需要經過SMTP伺服器轉換為MIME編碼，方能讓其他所有支援RFC協定的標準SMTP伺服器接收此封郵件。至於增長的大小則是取決於本文、附加檔案、換行符號、MIME表頭、其他非數據元的資訊等而不確定編碼之後的檔案大小，一般常見的數據顯示約為增加30%~40%不等。因此在經過任何一個SMTP伺服器發送出去之後，檔案一定會比原來的大(MIME不能壓縮)，在SPAM或是其他郵件伺服器接收郵件的時候，一定是以整個MIME編碼的郵件大小來計算，而不是接收完成之後Decode回原本檔案的大小來計算。

2. 設定前的考量

   在設定條件時，應該預留信件膨脹比例，也就是說，如果條件設10MB，其實7-8mb的原信就無法寄出，或寄到系統上，據了解有些設備的膨脹比例高達50%。

3. 測試檔案大小工具連結 

   以下有一個Third Party的工具程式，可以協助你換算，當一個檔案經過MIME編碼之後，會是多大的檔案大小？ 

   UUDEVIEW  http://www.miken.com/uud/

Back

新增一個新的使用者 開啟Exchange管理主控台，在收件者組態上按滑鼠右鍵， 選[新增信箱] 選擇使用者信箱，按[下一步]，選擇新使用者，按[下一步] 輸入[名稱]，[使用者登入名稱]及[密碼]等資訊，按[下一步] 選擇信箱資料庫，按[下一步]，按[新增]，按[完成] 新增一個新的聯絡人 在Exchange管理主控台，收件者組態上按滑鼠右鍵， 選[新增郵件聯絡人] 選擇新增聯絡人，按[下一步] 輸入[名稱]及[別名]等資訊 在外部電子郵件地址選編輯，[電子郵件地址]輸入mrt@mfs.softnext.com.tw，按[下一步] 按[新增]，按[完成] forward設定 開啟Exchange管理主控台，收件者組態，在之前新增的使用者上按右鍵選內容 按 [郵件流程設定] 的索引標籤，按 [傳遞選項]，按[內容] 將 [轉寄地址] 中的[轉寄至]勾起來，然後選取之前新增的聯絡人，然後按下 [確定] 使用者傳遞選項內容

Back

例如要新增一測試帳號信箱，在該帳號HOME目錄下新增一檔案.forward以下為檔案內容mrt@mfs.softnext.com.tw

Back

1. 在notes上新增一測試帳號信箱，開啟該帳號信箱
2. 在Forwarding addres的欄位中輸入mrt@mfs.softnext.com.tw

3. 儲存後重跑notes service

   

Back

Back

這個問題大多發生在客戶有 Cisco PIX 的防火牆或其他近似的功能時，就可能會產生這個狀況，因為 PIX 本身會有 MailGuard 的軟體，造成不支援 EHLO 等 ESMTP 指令，所以必須將這個功能關掉， 以下提供您關閉MailGuard的方式:
到 PIX 的設定組態裡將 fixup protocol smtp 25 改成 no fixup protocol smtp 25

Cisco PIX Firewall Command Reference Version 6.1"的4-23,fixup protocol smtp的解釋：

The fixup protocol smtp command enables the Mail Guard feature, which only lets mail servers receive the RFC 821, section 4.5.1 commands of HELO, MAIL, RCPT, DATA, RSET, NOOP, and QUIT. All other commands are rejected with the "500 command unrecognized" reply code.

As of version 5.1 and later, the fixup protocol smtp command changes the characters in the SMTP banner to asterisks except for the "2", "0", "0 " characters. Carriage return (CR) and linefeed (LF) characters are ignored.

In version 4.4, all characters in the SMTP banner are converted to asterisks.

詳細資料來源

Back

這個問題大多發生在客戶有 Cisco PIX 的防火牆或其他近似的功能時，就可能會產生這個狀況，因為 PIX 本身會有 MailGuard 的軟體，造成不支援 EHLO 等 ESMTP 指令，所以必須將這個功能關掉， 以下提供您關閉MailGuard的方式:
到 PIX 的設定組態裡將 fixup protocol smtp 25改成 no fixup protocol smtp 25

Cisco PIX Firewall Command Reference Version 6.1"的4-23,fixup protocol smtp的解釋：

The fixup protocol smtp command enables the Mail Guard feature, which only lets mail servers receive the RFC 821, section 4.5.1 commands of HELO, MAIL, RCPT, DATA, RSET, NOOP,and QUIT. All other commands are rejected with the "500 command unrecognized" reply code.

As of version 5.1 and later, the fixup protocol smtp command changes the characters in the SMTP banner to asterisks except for the "2", "0", "0 " characters. Carriage return (CR) and linefeed (LF) characters are ignored.

In version 4.4, all characters in the SMTP banner are converted to asterisks.

詳細資料來源

Back

重要事項：自 2022 年 11 月起，傳送電子郵件給 Google Gmail 帳戶的新寄件者必須設定 SPF 或 DKIM 了解詳情

退信訊息整理:

退信主因 - SPF/DKIM 沒設或是有問題.(以 SPF 為主)

退信樣式 A 參考網址

完整退信內容如下:

退信樣式 B 參考網址

有些主機的退信內容不夠完整,例如只有以下的內容
(reason: 550-5.7.26 This mail has been blocked because the sender is unauthenticated.)

退信樣式 C 請參考"管理網域中未經驗證的郵件"

訊息重點: 2451690 DMARC policy
(查證不見得是 DMARC 有問題,而是 DKIM,別忘了 DMARC 會一併查 SPF 與 DKIM)

退信樣式 D 請參考"電子郵件寄件者指南"

訊息重點: 發信主機沒有反解 PTR 或是 A 記錄
(其實把 SPF 設定正確即可,最好直接宣告 ip)

退信主因-出口 ip 被列 gmail 黑名單 參考網址

退信主因-收信限制 參考網址

訊息重點: 450-'4.2.1 The user you are trying to contact is receiving mail

Gmail SMTP 錯誤和代碼 參考網址

Back

點兩下將該郵件打開：檔案→資訊→內容

Back

可能與信件被歸類到垃圾郵件有關請將寄件者加入安全清單中，詳如附圖所示

Back

在我方系統內的郵件檢索或是郵件記錄，點開信件可以看到顯示詳細資料內即有郵件標題，範例如下：

由e780479@abc.com.tw寄至annie@softxxx.com.tw 

 每一個Received就是一個節點，最上面的第一個Received就是寄出去的最後一個節點

Received： from mse.softxxx.com.tw (mse.softxxx.com.tw [192.168.3.202]) 

寄出去的第4個節點，也就是收信端的第二個節點

by Server.softxxx.com.tw (8.14.4/8.14.4) with ESMTP id pB22NbSo085402

mse.softxxx.com.tw的信件編號

for <annie@softxxx.com.tw>; Fri， 2 Dec 2011 11：23：37 +0800 (CST)

mse.softxxx.com.tw主機的時間

( envelope-from e780479@abc.com.tw) 

真實寄件人帳號

Received： from spam.softxxx.com.tw (spam.softxxx.com.tw [192.168.1.209])

寄出去的第3個節點，也就是收信端的第一個節點

by mse.softxxx.com.tw with ESMTP id pB22NXpQ078409 

spam.softxxx.com.tw主機的信件編號

for <annie@softxxx.com.tw>; Fri, 2 Dec 2011 11：23：33 +0800 (GMT-8)

spam.softxxx.com.tw主機的時間

(envelope-from e780479@abc.com.tw)

Received： from 123.abc.com.tw (61-219-1-200.HINET-IP.hinet.net  [61.219.1.200] )

寄出去的第2二個節點，也就是寄件端的出口主機IP

by vvv.softxxx.com.tw with ESMTP id pB22NTmG098364 

123.abc.com.tw主機的信件編號

(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)

for <annie@softxxx.com.tw>; Fri, 2 Dec 2011 11：23：29 +0800 (CST)

123.abc.com.tw主機的時間

(envelope-from e780479@abc.com.tw) Received： from hadc032 ([128.1.50.32])

寄出去的第一個節點，這是寄件人的PC IP

by 123.abc.com.tw with ESMTP id pB22G81h024319

for <annie@softxxx.com.tw>; Fri, 2 Dec 2011 10：30：08 +0800 (GMT-8) 

第一個節點的時間

(envelope-from e780479@abc.com.tw)

Message-Id： <201112020216.pB22G81h024319@123.abc.com.tw>

From： "daniel" <e780479@abc.com.tw> 

顯示的寄件人

To： =?big5?B?J6Sktdi8xqbsLbBnprqkSKvIqkEn?= <annie@softxxx.com.tw>

顯示的收件人

In-Reply-To： <7975F8A3B388402C85E6CEC018D61052@AnniePC>

Subject： RE： test by soft xxx

Date： Fri, 2 Dec 2011 10：26：51 +0800

寄件人的PC電腦時間 

 寄件人的電腦時間是在10：26，但是到了自家主機已經是11：23：29，所以信是在對方產生延遲節點重點如下：

Date： Fri, 2 Dec 2011 10：26：51 +0800

寄件人的PC電腦時間

Received： from 123.abc.com.tw (61-219-1-200.HINET-IP.hinet.net [61.219.1.200]) for <annie@softxxx.com.tw>; 

 Fri, 2 Dec 2011 11：23：29 +0800 (CST) 

123.abc.com.tw主機的時間

Back

問題情境：

看見 Exchange 上個節點延遲原因為 452 4.3.1 Insufficient system resources 而無法後送到 Exchange(如圖所示，本圖範例為MSE)

452 4.3.1 Insufficient system resources 問題說明

Exchange 的 MicroSoft Exchange Transport 服務有一個 Back Pressure 的功能，就是當你安裝的 Exchange 所在的硬碟剩餘空間不足 4GB,MicroSoft Exchange Transport 服務會停掉 SMTP 的服務(也就代表無法接收外部信件).

Back Pressure 的功能是用來監控系統的資源使用.一旦系統資源不充足，就會出現這種情況，伴隨的出現是郵件不能發送等問題.

管理者也可至 Exchange 主機上查看事件檢視器的 ExchangeTransport 服務，上面會有詳細說明(本圖為windows server 2012 R2)

解決方式：

1. 請至在Exchange安裝目錄下 尋找EdgeTransport.exe.config此檔案，路徑為 C:\Program Files\Microsoft\Exchange Server\V15\Bin (此路徑為Exchange 2013版本，有可能因為Exchange版本不同而略有差異)

2. 請將檔案使用記事本點開後找到以下資料 <add key=”EnableResourceMonitoring” value=”True”/> 將其更改為 <add key=”EnableResourceMonitoring” value=”False”/>

及<add key="PercentagePhysicalMemoryUsedLimit" value="94" /> 將其更改為 <add key="PercentagePhysicalMemoryUsedLimit" value="100" />

修改完檔案後另存新檔至桌面，在將原路徑上的檔案刪除，刪除完後再將桌面上修改後的檔案放回原路徑。

3.然後重新啟動 MicroSoft Exchange Transport 服務. (請windows鍵+R後，輸入service.msc，再尋找MicroSoft Exchange Transport)

再次執行 telnet ExchangeServer IP 25 Port,若出現Exchange 的回應訊息,表示 SMTP服務正常運作了.

以上為暫解法，最主要還是需請管理者清除Exchange不必要的資料釋放空間，此部分建議管理者可以透過啟用循環紀錄的方式釋放空間(請管理者評估是否啟用)。

循環記錄相關說明如下(節錄微軟官網內容)：

在 Exchange 2010 使用的標準交易記錄中，每筆資料庫交易會先寫入至記錄檔，然後再寫入至資料庫。記錄檔的大小達到 1 MB 時，會重新命名該記錄檔，並建立新的記錄檔。而經過一段時間後，這會產生一組的記錄檔。如果 Exchange 意外停止，則可以將資料從記錄檔中重新顯示至資料庫，以復原交易。循環記錄會在第一個記錄檔中所含的資料寫入至資料庫之後，覆寫及重複使用第一個記錄檔。

在 Exchange 2010 中，循環記錄預設會停用。而啟用循環記錄，會減少磁碟機儲存空間需求。不過，若沒有完整的一組交易記錄檔，則無法復原比最近一次的完整備份更新的任何資料。一般不建議在正常的生產環境中使用循環記錄。

詳細內容可參閱微軟官網說明

方法如下：

請至Exchange系統管理中心後，依照附圖進行啟用即可。 (請管理者先進行卸載後再調整，調整後再重新掛載)

Back