Lotus Domino 8.5設定SmartHost & Journal如下步驟：
SmartHost (outbound信件設定)
-
開啟Domino Admin，並選擇Configuration如下
-
選取Router/SMTP → Basics，更改SmartHost設定如下，在Relay host for messages leaving the local internet domain: 輸入relay的ip特別注意,需有中括弧例如範例圖,在Relay host for messages leaving the local internet domain:為 [192.168.11.25]
-
啟動Lotus Domino Console並輸入tell router q，重啟load router
- 完成後，確認是否有outbound信件傳送到relayhost
啟動Domino Journal郵件封存功能
-
開啟Lotus Domino Admin建立郵件journal帳號，帳號名可任意取
-
選擇Router/SMTP->Advanced->Journaling，依照下圖設定
Select “Enable”
Select “send to mail-in database"
Select user mailbox for journaling
-
選擇Router/SMTP->Restrictions and Controls->Rules，New Rule依照下圖設定
-
選擇”all Documents”及”journal this Message”
- 完成後，請到journal mailbox中查看是否有郵件複製信件記錄產生
- 被加入RBL黑名單該到那裡查詢及解除呢？
- 被加入O365/Hotmail黑名單該到那裡查詢及解除呢？
- 被加入Yahoo黑名單該到那裡查詢及解除呢？
- 被加入AT&T黑名單該到那裡解除呢？
- 被加入Trend Micro黑名單該到那裡查詢及解除呢？
- 被加入Gmail or google黑名單該到那裡查詢及解除呢？
-
被加入RBL黑名單該到那裡查詢及解除呢？
-
確認嚴重程度
如果被列在cbl.abuseat.org 或是pbl.spamhaus.org以及psbl.surriel.com，這三家RBL的任一名單內，那就確定貴單位一定發生異常發信，一定要找出原因，因為這3家RBL會被許多信箱服務網站及垃圾信過濾機制單位參考,應會產生多數寄信被退回的情況。如果不是這三家RBL，但仍需仔細檢查IP是否有發出異常信件？ 如已查證確實沒有異常信件，可以直接先做解除黑名單的動作,只是單純被同網段其他IP牽連到。
-
解除技巧
只需要在RBL網站中查看紅色的RBL即可，有link可點，請點入，並依網站說明解除;如果沒有link可點，則需另外到google或 yahoo網站查詢網友的經驗分享，目前大致上有幾種申請方式
A.要付費才能解除:(並不建議使用,因為每列入一家就要付一次,而且也不是付費後有保固期,故建議無需處理)
如: dnsbl-1.uceprotect.net 及dnsbl-2.uceprotect.netB.網頁直接申請解除:有的需要填先基本資料如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
選右上方的contact,它會立刻偵測您的ip,下方會需要您輸入資料後應可解除.
提醒: cbl.abuseat.org 移除網址更動為 https://www.abuseat.org/lookup.cgi
C.會員制-登入帳號後才能解除:如dnsbl.sorbs.net 及Cisco (Sorbs.net還會偵測申請者的ip,建議最好不要代為處理,除非能使用該被加入黑名單的網段申請,以免產生申請困難的情況).
提醒您,Cisco己無提供來賓登入帳號;但有提供網站查證貴司列入的情況
https://talosintelligence.com 請在Reputation lookup 問號處查詢貴司ip,將可查到是否列入黑名單
有提供support網址
(請點選此處連結) 最好事先準備好ip的反解申請及SPF申請
D.無法接受申請:例如QQ被加入後只能等待自動移除約30天。
-
暫時解法
找到原因申請解除黑名單需要等待時間，如果急於寄送郵件有以下的做法
A.通知對方管理者將發送主機ip加入白名單中
B.全部更換IP
- 不直接寄出,再跳到另一台主機做寄送-例如原本由mail server寄送,改再設smart host,將信送到我方產品(SPAM/MSE)再寄出.(但是這種方式必須是二台設備各自有獨立的ip).
- 有備源線路,可做ip切換.
- 最不得已的做法是換一個實體ip,並且要修改dns記錄.(需要1天以上時間做DNS同步).
C.部份更換IP-將暫時將無法寄送的網域做設定
- 使用MSE系統之中繼主機功能(並設定收件域名)
- 將無法寄送的網域,轉給出口IP的電信線路公司的轉發主機
- 或者向中華數位業務單位借測試轉發主機.(限出口主機為我方客戶者)
申請解除黑名單或客服中心的網站如下:
當O365/hotmail客服中心回信時,就是被解開的時候了.
注意:上面的申請解除,請一定要先查rbl,因為如果在rbl內, 那麼先去申請O365/hotmail多半是失敗的
- 先在此網頁任意按一個常見問題
- 按右上角-與我們聯繫
- 填表格 (帳號指的是email @yahoo.com的前面為帳號)
- 選擇服務方式
- A.聯絡客服人員 (請選此項)
- 查看產品服務說明(跳回第1步的常見問題區)
- 選擇主題-郵件管理員基本知識
- 選擇副題-SMTP錯誤-信件受阻或延遲
- 選擇服務方式 -與信件客服人員聯絡
- 填入表格,說明問題細節後送出
網站反應
操作流程
請使用申訴網頁處理 (請點選此處連結)
-
請寄信到此信箱 abuse_rbl@abuse-att.net
被加入Gmail or google黑名單該到那裡查詢及解除呢？
-
請使用申訴網頁處理 (請點選此處連結)
Exchange 2007 或 Exchange 2010 裝好後， AUTH 是 NTLM
預設如下：
但若使用者是透過 Internet對Exchange 做 SMTP 認證，就無法認證成功。 此時要取消 Offer Basic authentication only after starting TLS (只有在啟動 TLS 後才提供基本驗證) 設定
而 Exchange 上 AUTH 就多了個 LOGIN，再對 Exchange做寄信測試
|
GSSAPI: 一種代表一般安全性服務應用軟體程式設計介面，並且可讓使用者透過 Kerberos 進行驗證的方法。 NTLM: 一種代表 Windows NT 與 LAN Manager，並且可讓使用者透過 Windows NT 挑戰/回應通訊協定進行驗證的方法。 LOGIN: 一種代表 AUTH LOGIN 的方法，此為使用 Base-64 編碼之使用者名稱與密碼的純文字驗證方法。 |
發生原因： 因為寄件人使用了outlook TFG/TNEF格式 解決方式：唯有寄件人才能真正解決
請寄件人把收件人的通訊錄砍掉，重新開一張新文件寄信，並仔細檢查，用的是純文字或HTML寄信，才不會因為outlook的自動記錄功能，一直保留要用RTF格式寄給對方，對方就會收到.dat的檔案。
|
深入研究 |
如果不了解 TNEF 的電子郵件用戶端，收到一則含有TNEF資訊的訊息時，通常會出現下列三種結果：
|
參考資料 |
RTF 格式是 Microsoft 使用的格式 只有以下電子郵件應用程式支援 RTF 格式：
Mac OS X Mail：winmail.dat 附件是什麼？ |
-
產生原因：中國官方管制
出現這種錯誤是由中國的GFW(簡寫)造成的，(英文全名為The Great Fire Wall of China)，意指”中國網路防火牆”，這是中國國家網路的監控系統，俗稱”防火長城”，GFW是”金盾計劃”的一個子功能，”會對境外涉及敏感的網站，IP地址，關鍵字或關鍵詞，網址做過濾，而且會導致暫時或永久性無法連線。
-
被管制後的退信訊息。
551 User not local; please try <forward-path>
-
被管制後收到被改變的信件內容
如aaaazzzzzz
-
如何解決？
如果是中國與台灣之間的連線，建議走VPN，或使用加密傳輸
| outlook收信軟體的調整方式 |
|
| outlook express收信軟體的調整方式 |
|
本系統的計算方式是以整封信的大小來看，而非單指附件檔的大小 。
-
詳細原因說明
當一封郵件經由SMTP伺服器處理，準備寄發出去的時候，因為不管Client發出的信件為TXT純文字格式或是HTML格式，以及是否有夾帶任何附件檔案的時候，通通需要經過SMTP伺服器轉換為MIME編碼，方能讓其他所有支援RFC協定的標準SMTP伺服器接收此封郵件。至於增長的大小則是取決於本文、附加檔案、換行符號、MIME表頭、其他非數據元的資訊等而不確定編碼之後的檔案大小，一般常見的數據顯示約為增加30%~40%不等。因此在經過任何一個SMTP伺服器發送出去之後，檔案一定會比原來的大(MIME不能壓縮)，在SPAM或是其他郵件伺服器接收郵件的時候，一定是以整個MIME編碼的郵件大小來計算，而不是接收完成之後Decode回原本檔案的大小來計算。
-
設定前的考量
在設定條件時，應該預留信件膨脹比例，也就是說，如果條件設10MB，其實7-8mb的原信就無法寄出，或寄到系統上，據了解有些設備的膨脹比例高達50%。
-
測試檔案大小工具連結
以下有一個Third Party的工具程式，可以協助你換算，當一個檔案經過MIME編碼之後，會是多大的檔案大小？
UUDEVIEW http://www.miken.com/uud/
分成二種不同的版本 Exchange 2007前之版本.(不含2007，即較舊之版本) |
|
Exchange 2007之後版本.(含2007，即較新之版本) |
|
- 在notes上新增一測試帳號信箱，開啟該帳號信箱
- 在Forwarding addres的欄位中輸入mrt@mfs.softnext.com.tw
-
儲存後重跑notes service
這個問題大多發生在客戶有 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.
這個問題大多發生在客戶有 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.
如果無法寄到PCHOME且有看到以下錯誤訊息時：
Deferred： 450 4.7.1 Client host rejected： cannot find your hostname, [123.123.123.123] 則是outbound 出去IP的反解跟正解不相同，PCHOME就會不收。
舉例來說，如果帶出去的IP為123.123.123.123以及123.123.123.123的反解為mail.test.com的話，則mail.test.com的正解也要是123.123.123.123才行，如果反解或正解有一對多的情況時，PCHOME也會判斷錯誤而拒收，最好正反解是一對一的設定。
在我方系統內的郵件檢索或是郵件記錄，點開信件可以看到顯示詳細資料內即有郵件標題，範例如下：
由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主機的時間
問題情境：
看見 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系統管理中心後，依照附圖進行啟用即可。 (請管理者先進行卸載後再調整，調整後再重新掛載)
