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中查看是否有郵件複製信件記錄產生
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中查看是否有郵件複製信件記錄產生
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,即較新之版本) |
|
例如要新增一測試帳號信箱,在該帳號HOME目錄下新增一檔案.forward以下為檔案內容mrt@mfs.softnext.com.tw
- 在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系統管理中心後,依照附圖進行啟用即可。 (請管理者先進行卸載後再調整,調整後再重新掛載)