專利名稱：消息系統(tǒng)的制作方法
消息系統(tǒng)
相關(guān)申請的交叉參考
這個(gè)申請要求2003年7月7日提交的美國臨時(shí)專利申請?zhí)?60/485,167的權(quán)益，其內(nèi)容通過引用結(jié)合于此。
背景技術(shù)：
本發(fā)明總體上涉及一種電子消息系統(tǒng)，并且更具體地涉及一種用于 處理通過互聯(lián)網(wǎng)從發(fā)送者到接收者的電子消息的電子消息傳送系統(tǒng)。更 狹義地，這個(gè)書面內(nèi)容公開了作為一個(gè)實(shí)施例的高性能電子消息傳送引
電子消息傳送問題
電子消息已經(jīng)快速地成為現(xiàn)代社會中日常生活的一個(gè)構(gòu)成整體所需 的部分。今天，電子郵件(e-mail)是互聯(lián)網(wǎng)最廣泛使用的應(yīng)用以及最快速 成長的通信媒介。除了一對一用戶通信的巨大擴(kuò)展以外，許多公司己經(jīng) 開始意識到常規(guī)出站電子消息通信，以及經(jīng)由e-mail的自動化的客戶照 管服務(wù)可以增強(qiáng)公司與客戶的關(guān)系。然而，發(fā)送和接收大量e-mail提出 了眾多技術(shù)挑戰(zhàn)，如例如1):管理和支持用于大量發(fā)送的增長的基礎(chǔ)設(shè) 施；2)維護(hù)對互聯(lián)網(wǎng)開放的應(yīng)用的安全；3)當(dāng)e-mail進(jìn)入或離開網(wǎng)絡(luò)時(shí)， 需要對其施加病毒、內(nèi)容和其它過濾；4)管理和優(yōu)先化消息隊(duì)列；5)使用 本地客戶數(shù)據(jù)來到客戶的消息進(jìn)行觸發(fā)、確立目標(biāo)和定義；6)管理入站的 "彈回的"e-mail; 7)—致且自動地支持客戶偏愛的能力；8)執(zhí)行快速和 高效的發(fā)送。
通過使用可獲得的技術(shù)，即使不是不可能，然而滿足可縮放的電子 消息程序的這些挑戰(zhàn)已經(jīng)是困難的，并且已經(jīng)在硬件和人力資本上要求 大量投資。目前，所有類型的公司、組織，包括e-mail專家和服務(wù)提供
商，繼續(xù)采用數(shù)十年舊的技術(shù)，用于經(jīng)由郵件傳遞代理(MTA)對e-mail 進(jìn)行發(fā)送和路由，所述代理并未預(yù)期業(yè)務(wù)量的膨脹以及今日網(wǎng)絡(luò)的系統(tǒng) 復(fù)雜性。
現(xiàn)有技術(shù)MTA以及開放源郵件路由服務(wù)商
E-mail被開發(fā)用來在計(jì)算機(jī)網(wǎng)絡(luò)上從一個(gè)用戶到另一用戶傳送電子 通信，其中用戶是e-mail消息系統(tǒng)的成員并且可是人、機(jī)器或是在e-mail 消息系統(tǒng)的域內(nèi)具有e-mail地址的應(yīng)用。E-mail的首要技術(shù)是被眾所周 知為簡單郵件傳輸協(xié)議(SMTP)的TCP/TP通信協(xié)議，其被發(fā)明于1981年 且被設(shè)計(jì)成支持電子消息通過互聯(lián)網(wǎng)、經(jīng)由可兼容的路由傳送服務(wù)器 從一個(gè)計(jì)算機(jī)的用戶到接收計(jì)算機(jī)的用戶的路由和傳送。通過將消息格 式標(biāo)準(zhǔn)化成帶有公用頭部和路由信息，并且建立用于e-mail處置應(yīng)用之 間通信事務(wù)處理的命令句法和步驟，SMTP方便了 e-mail的傳送。
總體上，e-mail應(yīng)用屬于在移動和管理e-mail消息過程中起到特定 作用的至少三個(gè)分類之一。第一應(yīng)用分類是郵件傳遞代理(MTA),其通過 互聯(lián)網(wǎng)利用SMTP在主機(jī)和網(wǎng)絡(luò)之間傳遞e-mail消息。消息沿途可通過 幾個(gè)MTA行進(jìn)到其預(yù)期的目的地。第二應(yīng)用分類是郵件傳送代理 (MDA)，其向MTA傳輸出站消息，用于從當(dāng)?shù)刂鳈C(jī)或網(wǎng)絡(luò)的傳送，并且 被MTA調(diào)用，以將進(jìn)入的e-mail歸檔在預(yù)期的接收者的郵箱中。實(shí)際上， 許多MTA具有內(nèi)置的MDA，并且一些MDA包括某些MTA組件。第三 應(yīng)用分類是郵件用戶代理(MUA)，其基本上是e-mail客戶應(yīng)用，所述 客戶應(yīng)用最少允許用戶從MDA讀取且創(chuàng)作e-mail消息。1
在目前的現(xiàn)有技術(shù)中，MTA通過到互聯(lián)網(wǎng)的網(wǎng)關(guān)，在到達(dá)接收者的 途中將e-mail從當(dāng)?shù)刂鳈C(jī)發(fā)送到其它的MTA郵件服務(wù)器。MTA技術(shù)在 二十世紀(jì)八十年代中期由UC Berkeley的Eric Allman開發(fā)，并且原始MTA 技術(shù)的基本架構(gòu)和組件今日仍然被使用。2
MTA的目前技術(shù)
在目前的現(xiàn)有技術(shù)中，MTA e-mail發(fā)送的標(biāo)準(zhǔn)過程如下 1 .在MTA處，接收來自MDA或其它e-mail產(chǎn)生應(yīng)用的進(jìn)入的SMTP 格式化的消息；
2. 將進(jìn)入的消息寫給硬驅(qū)動器上的文件，用于暫時(shí)存儲；
3. 讀取消息的SMTP頭部以得到目的地信息；
4. 通過域名服務(wù)(DNS)查詢表，發(fā)現(xiàn)目的地的郵件交換(MX)記錄；
5. 在目的地網(wǎng)絡(luò)處打開與MTA的連接(即插槽)；
6. 通過這個(gè)插槽，進(jìn)行SMTP通信，包括來自發(fā)送MTA的一系列 信息傳輸以及來自接收MTA的回答，驗(yàn)證身份并且證實(shí)可傳送性或傳 達(dá)臨時(shí)的或永久的可傳送性的失??；
7. 傳輸消息；以及
8. 等待任何來自接收者M(jìn)TA的短期回答消息，包含傳送失敗錯(cuò)誤 ("彈回")。在傳送失敗錯(cuò)誤的情況下，重新發(fā)送消息。否則，從硬驅(qū)動
器中刪除消息并且結(jié)束過程。
在目前的現(xiàn)有技術(shù)中，從連接到傳輸?shù)男蛄谢旧鲜且恢碌暮蜆?biāo)準(zhǔn) 的。消息的傳輸是完整傳送過程的第一部分，其中，在消息被傳遞后， MTA繼續(xù)存儲消息的拷貝一段時(shí)間，其中任何短期失敗消息(即，彈回)、 傳達(dá)傳送失敗的從接收MTA發(fā)送到發(fā)送MTA的SMTP email可被接收。 如果這種彈回被接收，則發(fā)送MTA使用所存儲的消息拷貝，來重復(fù)整 個(gè)過程并且再次發(fā)送消息(即重試)。典型地，在終止傳送過程且向發(fā)送 者遞交傳送失敗消息之前，MTA將連續(xù)地幾次重試被彈回的消息。當(dāng) e-mail在從其起點(diǎn)到其最終目的地的途中在MTA之間被傳遞時(shí)，這個(gè)過 程可重復(fù)。
現(xiàn)在轉(zhuǎn)到附圖，其中相似的項(xiàng)目利用相似的參考號來表示，首先注 意圖1A和1B，其分別示例用于引導(dǎo)e-mail消息從發(fā)送者到接收者的現(xiàn) 有技術(shù)配置以及SMTP過程。圖1A示例現(xiàn)有技術(shù)，即總體上由參考號
10表示、用于通過MTA發(fā)送和接收的SMTP email的多用戶e-mail消息 系統(tǒng)。系統(tǒng)10包括與發(fā)送MDA 14相連接的多個(gè)發(fā)送者(由框12A-12F 表示)。發(fā)送者12A-12F產(chǎn)生多個(gè)e-mail消息16并且將e-mail消息導(dǎo)引 到發(fā)送者M(jìn)AD14。多個(gè)e-mail消息16中的每個(gè)總體上包括頭部，其 包含有關(guān)始發(fā)發(fā)送者(如發(fā)送者用戶名稱及發(fā)送者服務(wù)器域名)以及預(yù)期 的接收者(如接收者用戶姓名及接收者服務(wù)器域名)的信息；以及消息體， 其包含例如消息文本。發(fā)送者M(jìn)DA 14將e-mail消息16傳輸?shù)桨l(fā)送者 MTA20。注意到為了簡明，發(fā)送者M(jìn)DA14和發(fā)送者M(jìn)DA20的特定組 件，如處理器和硬驅(qū)動器未被示于圖1A中。發(fā)送者M(jìn)TA20啟動通過互 聯(lián)網(wǎng)(由參考項(xiàng)目30表示)與接收者M(jìn)TA 40的通信，以便于將e-mail消 息16中繼到接收者M(jìn)TA40。接收者M(jìn)TA40將e-mail消息16前轉(zhuǎn)到接 收者M(jìn)DA44，然后其將消息導(dǎo)引到從多個(gè)接收者(由框46A-46F所表示) 之一中選擇出的相應(yīng)預(yù)期接收者。如圖1A中所示的過程可被顛倒，以便 于接收者46A-46F可產(chǎn)生通過MDA和MTA發(fā)送到發(fā)送者12A-12F的多 個(gè)e-mail消息。
現(xiàn)在結(jié)合圖1A來參考圖1B，在發(fā)送者M(jìn)TA 20處用于發(fā)送e-mail 消息的SMTP過程被示例。在圖IB中所示的過程60中，在步驟62發(fā)送 者M(jìn)TA 20首先從發(fā)送者M(jìn)DA 14接收電子消息(多個(gè)e-mail消息16之 一)。然后，在步驟64， MTA20將電子消息寫入到硬驅(qū)動器中。然后， 在步驟66， MTA 20査詢接收者服務(wù)器的域名并且在步驟68連接到接收 者M(jìn)TA 40。判斷70確定是否已經(jīng)進(jìn)行發(fā)送者M(jìn)TA 20與接收者M(jìn)TA 40 的連接，并且如果判斷70的結(jié)果是YES，那么己經(jīng)進(jìn)行了連接，則在步 驟72發(fā)送者M(jìn)TA20將在其硬驅(qū)動器上的SMTP消息拷貝傳遞到接收者 MTA40。如果判斷70的結(jié)果是NO，那么還沒有進(jìn)行連接，則在步驟74 發(fā)送者M(jìn)TA可排定在以后的時(shí)間重試傳送(即循環(huán)回到步驟66)。在步 驟72之后，判斷76確定SMTP消息到接收者M(jìn)TA 40的傳送是否已經(jīng) 成功。如果判斷76的結(jié)果是YES，那么傳送己經(jīng)成功，則在步驟78，被傳送的SMTP消息被從MTA20的硬驅(qū)動器中刪除。如果判斷76的結(jié) 果是NO，則傳送尚未成功，于是發(fā)送者M(jìn)TA通過循環(huán)回到步驟74可再 次排定在以后的時(shí)間重新發(fā)送消息。
繼續(xù)參考圖1A和1B，注意到在電子消息傳送系統(tǒng)的這個(gè)現(xiàn)有技術(shù) 配置中，發(fā)送者M(jìn)TA 20和接收者M(jìn)TA 40兩者基本上充當(dāng)盲中繼器(blind relayer)。即，發(fā)送者M(jìn)TA20獲取預(yù)先形成的e-mail消息16且將其通過 互聯(lián)網(wǎng)導(dǎo)引，而不管例如接收者用戶名稱和接收者服務(wù)器域名的準(zhǔn)確性 以及接受進(jìn)入的e-mail消息的接收者M(jìn)TA 40的可用性。結(jié)果是，系統(tǒng) IO不可避免地產(chǎn)生多個(gè)彈回，其通過發(fā)送者M(jìn)TA20、發(fā)送者M(jìn)DA14將 重新發(fā)送導(dǎo)引回且到發(fā)送者12A-12F。彈回和重新發(fā)送的過程消耗了發(fā)送 者M(jìn)TA和MDA可獲得的處理能力并且在過程期間在傳輸和接收多個(gè) e-mail的同時(shí)，占用附加的通信帶寬。申請人提出在現(xiàn)有技術(shù)的e-mail 傳送系統(tǒng)中，上述彈回和重新發(fā)送過程使用所不希望數(shù)量的處理時(shí)間和 帶寬。
現(xiàn)在結(jié)合圖1A，參考圖2，電子消息(如被示于圖1A中的多個(gè)e-mail 消息16之一)的標(biāo)準(zhǔn)消息格式被示例。如圖2中所示，多個(gè)e-mail消息 16中的每一個(gè)包括消息頭部90和消息體92。在圖2所示的實(shí)例中，消 息90包括這樣的信息，如消息產(chǎn)生日期、消息ID、始發(fā)發(fā)送者(g卩，"來 自")、預(yù)期的接收者(即"到")等。消息體92包括例如消息文本和相聯(lián) 系的HTML碼以規(guī)定消息的外觀?？傮w上，由于多個(gè)e-mail消息16的 每一個(gè)作為包括消息頭部和消息體的單個(gè)文件被導(dǎo)引到發(fā)送者M(jìn)TA20， 所以并不可能執(zhí)行附加的過程，如例如在MTA20處添加客戶內(nèi)容、安全 鑰匙或附件。
概括地，在目前現(xiàn)有技術(shù)的e-mail MTA中的關(guān)鍵過程如下
1. SMTP饋送對預(yù)先形成的SMTP消息排它的接收及處理；
2. 存儲及前轉(zhuǎn)將每個(gè)消息寫入到硬驅(qū)動器上的文件中用于暫時(shí)存 儲、將文件前轉(zhuǎn)到接收MTA用于傳送及隨后完成傳送過程之后將它刪
除的機(jī)構(gòu)，以在傳送過程己經(jīng)完成之前系統(tǒng)失敗之時(shí)確?；謴?fù)和重新傳
送；
3. 組合的驗(yàn)證和傳輸終結(jié)于消息傳輸?shù)呐c接收者M(jìn)TA的SMTP 通信內(nèi)的通信事務(wù)處理的固定序列；
4. 中繼將其接收的每個(gè)消息發(fā)送并且繼續(xù)重新發(fā)送未能發(fā)送的那 些消息的傳送過程；以及
5. 閉合的架構(gòu)將不可中斷過程序列中的上述元素組合的架構(gòu)。
MTA技術(shù)的最新進(jìn)步
自從第一代MTA應(yīng)用，g卩sendmail于1981年發(fā)布以來，上述所說 明的MTA過程和特征基本上還未改變。迄今為止，在MTA email傳送技 術(shù)上的進(jìn)步還沒有改變上述所說明的任何基礎(chǔ)過程和特征，但是卻在其 約束內(nèi)一直努力工作，以通過改善執(zhí)行這些過程的速度和效率來優(yōu)化傳 送性能。
為此，結(jié)合在支持MTA e-mail傳送的某些現(xiàn)存關(guān)鍵過程的硬件操作 系統(tǒng)上的進(jìn)步，已經(jīng)發(fā)展了在此技術(shù)中的最新進(jìn)步，即到接收者M(jìn)TA的 插槽連接的產(chǎn)生以及來自硬驅(qū)動器或到其的消息文件的存儲和檢索，或 文件輸入/輸出(即文件1/0)。
插槽連接的產(chǎn)生是SMTP郵件傳送的基礎(chǔ)。在此技術(shù)的最早的實(shí)施 例中，建立到接收者M(jìn)TA的插槽連接的方法基于每個(gè)新插槽有新應(yīng)用實(shí) 例的產(chǎn)生(即基于過程的插槽連接)。這個(gè)方案固有地是處理器密集型且將 傳送速度限制到此速率，即應(yīng)用可以在硬件上例化(instantiate)本身的 速率。
基于線程的SMTP連接
當(dāng)e-mail量已經(jīng)增加時(shí)，并且發(fā)送消息到大量接收者，用于公布、 營銷及其它目的的實(shí)踐涌出時(shí)，改善e-mail MTA的速度和處理性能的興
趣得到增強(qiáng)。與此同時(shí)，操作系統(tǒng)的進(jìn)步提供了支持在程序內(nèi)多個(gè)同時(shí) 發(fā)生的命令鏈(即線程)的能力，從而與例化所要求相比，在支持具有基本 上較低處理開銷的多個(gè)同時(shí)的數(shù)據(jù)事務(wù)處理時(shí)，使能同時(shí)發(fā)生的過程。
因此，e-mail MTA可同時(shí)產(chǎn)生多個(gè)插槽連接，從而使能對SMPT連接的 并行處理，用于在低得多的處理開銷下的快得多的傳送(即基于線程的插 槽連接)。
開放源MTA應(yīng)用qmail是這個(gè)方法的最早且最廣泛使用的實(shí)例。在 用于各種操作系統(tǒng)的線程化模型中的隨后改善提供了用于線程化的更高 效的存儲器分配，其使能有效地用于插槽連接中的線程數(shù)目得到巨大的 增加。線程數(shù)目的這一增加導(dǎo)致qmail類型MTA應(yīng)用的出現(xiàn)，其被優(yōu)化 來更高效地運(yùn)行在用于電子消息的大量多線程發(fā)送所配置的操作系統(tǒng) 上。這個(gè)進(jìn)步最成功的實(shí)例是于1999年發(fā)布的商業(yè)產(chǎn)品PowerMTATM、 以及于2001年發(fā)布的Lyris Ma服ngine。
非同步文件I/0
由多線程SMTP通信引發(fā)的速度和性能的改善強(qiáng)調(diào)了在MTA e-mail 傳送中新的速率限制過程，即寫入到硬驅(qū)動器和從硬驅(qū)動器檢索，文件 1/0的過程。文件I/0過程公用于計(jì)算機(jī)應(yīng)用，并且在將文件順序地讀取 和寫入到盤之后，應(yīng)用，或過程系列的速度減緩或出現(xiàn)瓶頸的傾向被廣 泛知曉。在這個(gè)過程中的第一重大進(jìn)步引入跨并行的多驅(qū)動盤(RAID)的 數(shù)據(jù)存儲的管理，從而極大地增加了速度。在這個(gè)過程中的第二更近期 的進(jìn)步發(fā)布了開放源操作系統(tǒng)OpenBSD和Linux RedHat，從而使能操作 系統(tǒng)同時(shí)地遞增地或非同步地(S卩，非同步1/0)將多個(gè)文件寫入到驅(qū)動器 且從中讀取。這個(gè)進(jìn)步使能相當(dāng)更快速的讀取及寫入文件到盤，產(chǎn)生MTA
應(yīng)用中的文件i/o過程的效率的明顯改善，因此改善了處理速度和效率。
因此，在支持大量多線程化和非同步文件I/O的操作系統(tǒng)上，有可 能優(yōu)化基于qmail的MTA應(yīng)用，以從e-mail MTA的應(yīng)用中取得迄今為止
最佳的性能。事實(shí)上，為確保操作系統(tǒng)的最佳配置以及MTA應(yīng)用的調(diào)諧，
這種應(yīng)用的優(yōu)選實(shí)施例是預(yù)先配置的帶有RAID的硬件裝置。兩個(gè)這樣 的裝置IronPORT A60 及Mirapoint Message Server于2001至2002被投
放市場。根據(jù)已發(fā)表的技術(shù)規(guī)范，上面所說明的現(xiàn)有技術(shù)MTA應(yīng)用的持 續(xù)性能的比較被概括于表l。
持續(xù)性能
(標(biāo)準(zhǔn)雙處理器PIII或等Sendmail qmail 優(yōu)化的基于IronPort 效物) Q-mail的MTA
E-mail( 10,000字節(jié))/服10,000 務(wù)器/小時(shí)
在8小時(shí)時(shí)段中發(fā)送50 4,000,000個(gè)e-mail所需
要的服務(wù)器
30,000 200,000 300,000 17 3 2
表1. E-Mail MTA性能
MTA最常用的性能尺度是持續(xù)速率，在此速率上它們從標(biāo)準(zhǔn)雙 Pentium 3或Pentium 4處理器服務(wù)器或其等效物傳輸標(biāo)準(zhǔn)的文本消息(從 5000到10000字節(jié)范圍)。Sendmail MTA執(zhí)行得最差，因?yàn)樗乃俣缺?插槽連接和標(biāo)準(zhǔn)文件1/0的例化所損害。通過使用基于線程的插槽連接， Qmail的標(biāo)準(zhǔn)實(shí)施執(zhí)行得好大約三倍?；赒mail的多線程化MTA比 qmail標(biāo)準(zhǔn)實(shí)施從性能上提供了極大的十倍的改善，同時(shí)還使用非同步I/O 的基于qmail的多線程MTA比沒有它的大量多線程化的基于qmail的 MTA從性能上提供附加的50%或更多的增加。
MTA的應(yīng)用程序接口
雖然sendmail和其它MTA被演變成使用用于內(nèi)容分析的特征和規(guī)則
集，但是用戶在執(zhí)行對SMTP消息和其它復(fù)雜處理(如，例如垃圾郵件及
附件過濾、定制記錄、放棄者添加(disclaimer addition)及病毒掃描)的 修改時(shí)可用的選項(xiàng)已經(jīng)被限制成l)對外部程序的調(diào)用，其通常僅對于當(dāng)
地傳送或到當(dāng)?shù)氐刂返南⒂杏茫?)對于在定期的基礎(chǔ)上被觸發(fā)的程序， 在排隊(duì)模式中使用MTA; 3)使用前轉(zhuǎn)方案(g卩，具有幾個(gè)MTA實(shí)例的串 行架構(gòu))；或4)改變sendmail的源碼以添加一些擴(kuò)展，由此需要sendmail 的重新編譯3。這四個(gè)選項(xiàng)當(dāng)中沒有一個(gè)使用簡便或操作高效。缺少到其 它應(yīng)用的公用接口，使得這個(gè)架構(gòu)還被稱為"閉合的架構(gòu)"。
為了便利于e-mail的處理過濾器的寫入和集成，sendmail組開發(fā)了 一些應(yīng)用程序接口(API)，用于在MTA的SMTP過程的各個(gè)步驟中使能 引入外部e-mail處理序列4。這些API共同稱為MIL TER(Mail Filtering API)。 MIL TER首先被實(shí)施在sendmail的8.10.x版本中，且自從8.12.x 版本己經(jīng)被正式地在sendmail中被加以支持。
MIL TER API被限制在后處理的范圍，其中API事件僅在協(xié)議期間 每個(gè)SMTP事件(例如，連接，HELO， MAIL FROM, FROM, RCPT TO, DATA及QUIT)發(fā)生之后才被觸發(fā)。g卩，當(dāng)接收服務(wù)器正在響應(yīng)于發(fā)送服 務(wù)器的動作時(shí)，消息可在INBOUND傳播進(jìn)服務(wù)器的同時(shí)被加以動作。 然而，在事件發(fā)生前用于對信息做出動作的規(guī)定尚不存在，并且因此不 存在當(dāng)發(fā)送服務(wù)器正在啟動動作時(shí)用于對從服務(wù)器OUTBOUND傳播的 消息加以動作的工具。
正如此后將看到的，借助于其提供增加的性能的能力而同時(shí)解決存 在于電子消息傳送系統(tǒng)目前現(xiàn)有技術(shù)中的上述問題，本發(fā)明提供了一種 如上所討論對現(xiàn)有技術(shù)的顯著改善。
參考
1. Bill Ball, Hoyt Duff, Red Ha敏Linux 9， S咖May 8,2003, Chapter 11.
2. JDavid Pitts and Bill Ball, fed Hat Linux 6 (Unleashed), S咖July 30, 1999, Chapter 7 SMTP and Protocols.
3. Stdphane Lentz "Matw," http:〃miltef,free.fr/intro/. slides 1 and 2, France, April 14,2004.
4. Sendmail Inc.. "Milter API." hto:〃www.milter.oiymfltef api/ani.html. 2003.

發(fā)明內(nèi)容
正如此后將更詳細(xì)所說明，在此公開了一種用在通過互聯(lián)網(wǎng)對接的 消息系統(tǒng)的方法。用于處理來自發(fā)送者且想要傳送到至少一個(gè)接收者的 消息的這個(gè)方法包括在依賴于接收者信息來發(fā)送消息之前，借助于建 立通過互聯(lián)網(wǎng)從發(fā)送者服務(wù)器到接收者服務(wù)器的臨時(shí)測試連接，測試接 收者信息，以便于提供消息到接收者的可傳送性指示，而無需使用SMTP 驗(yàn)證(VRFY)命令，其中所述發(fā)送者通過能夠與接收者服務(wù)器通信的發(fā)送 者服務(wù)器對接到互聯(lián)網(wǎng)上，其中所述消息包括至少接收者信息及消息體。
在本發(fā)明的另一方面中，公開了一種用在通過互聯(lián)網(wǎng)接口的消息系 統(tǒng)的方法。用于處理來自發(fā)送者且想要傳送到至少一個(gè)接收者的消息的
這個(gè)方法包括根據(jù)接收者信息確認(rèn)消息到接收者的可傳送性，其中所
述發(fā)送者通過能夠與接收者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng) 上，其中所述消息包括至少接收者信息及消息體。所述確認(rèn)包括通過互 聯(lián)網(wǎng)建立發(fā)送者服務(wù)器與接收者服務(wù)器之間的連接，以及從發(fā)送者服務(wù) 器，通過使用所述連接利用接收者服務(wù)器來驗(yàn)證接收者信息，以便于不
使用SMTP VRFY命令而提供接收者是否通過接收者服務(wù)器對接到互聯(lián) 網(wǎng)上的指示。所述指示是接收者的確通過接收者服務(wù)器對接到互聯(lián)網(wǎng)的 肯定確認(rèn)以及示出接收者并未通過接收者服務(wù)器對接到互聯(lián)網(wǎng)的否定中
的一個(gè)。
在本發(fā)明另外一個(gè)方面中，公開了一種用在通過互聯(lián)網(wǎng)對接的消息 系統(tǒng)中的方法。用于處理來自發(fā)送者且想要傳送到至少一個(gè)接收者的消 息的這個(gè)方法包括在發(fā)送者服務(wù)器處從發(fā)送者接收用于定義消息的多個(gè)
離散數(shù)據(jù)包，其中所述發(fā)送者通過能夠與接收者服務(wù)器通信的發(fā)送者服 務(wù)器對接到互聯(lián)網(wǎng)上。多個(gè)離散數(shù)據(jù)包中的至少一個(gè)包括接收者信息且 多個(gè)離散數(shù)據(jù)包的至少另外一個(gè)包括消息體。所述方法進(jìn)一步包括在 依賴于接收者信息來發(fā)送消息之前，借助于通過互聯(lián)網(wǎng)建立從發(fā)送者服 務(wù)器到接收者服務(wù)器的臨時(shí)測試連接，測試接收者信息，以便于提供消 息到接收者的可傳送性指示，而無需使用SMTP VRFY命令。所述方法 還包括，基于所述指示，執(zhí)行下述之一(i)通過組合至少接收者信息和消 息體產(chǎn)生消息，然后通過互聯(lián)網(wǎng)建立從發(fā)送者服務(wù)器到接收者服務(wù)器的 傳送連接，隨后通過傳送連接將消息導(dǎo)引到接收者服務(wù)器，以便于傳送 到接收者，以及(ii)放棄消息的傳送。
在本發(fā)明的另一方面中，公開了在通過互聯(lián)網(wǎng)對接的消息系統(tǒng)中， 一種用于處理來自發(fā)送者且想要傳送到至少一個(gè)接收者的消息的方法。 所述發(fā)送者通過能夠與接收者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng) 上。所述方法包括在發(fā)送者服務(wù)器處從發(fā)送者接收用于定義消息的多個(gè) 離散數(shù)據(jù)包。多個(gè)離散數(shù)據(jù)包中的至少一個(gè)包括接收者信息且多個(gè)離散 數(shù)據(jù)包的至少另外一個(gè)包括消息體。所述方法還包括根據(jù)接收者信息確 認(rèn)消息到接收者的可傳送性，這是借助于通過互聯(lián)網(wǎng)建立發(fā)送者服務(wù) 器與接收者服務(wù)器之間的連接，以及從發(fā)送者服務(wù)器，通過所述連接利
用接收者服務(wù)器來驗(yàn)證接收者信息，以便于不使用SMTP VRFY命令而 提供接收者是否通過接收者服務(wù)器對接到互聯(lián)網(wǎng)上的指示。所述指示是 接收者的確通過接收者服務(wù)器對接到互聯(lián)網(wǎng)的肯定確認(rèn)以及示出接收者 并未通過接收者服務(wù)器對接到互聯(lián)網(wǎng)的否定中的一個(gè)。所述方法進(jìn)一步
包括基于所述指示，執(zhí)行下述之一(i)響應(yīng)于肯定確認(rèn)，通過組合至少
接收者信息和消息體產(chǎn)生消息，然后將所產(chǎn)生的消息通過連接導(dǎo)引到接 收者服務(wù)器，以便于傳送到接收者，以及(ii)響應(yīng)于否認(rèn)，放棄消息的傳 送。
在本發(fā)明的另一方面中，公開了一種經(jīng)修改的消息服務(wù)器，其被配置用來代替對接到互聯(lián)網(wǎng)用于處理來自發(fā)送者且想要傳送到至少一個(gè)接 收者的未修改的消息服務(wù)器。所述發(fā)送者通過能夠與接收者服務(wù)器通信 的未修改消息服務(wù)器對接到互聯(lián)網(wǎng)上。所述未修改的消息服務(wù)器包括硬 驅(qū)動器，其被配置用于將消息作為消息文件保存到其上，以及所述未修 改的消息服務(wù)器被配置成將消息文件前轉(zhuǎn)到接收者服務(wù)器。經(jīng)修改的消 息服務(wù)器包括用于從發(fā)送者接收用來定義消息的多個(gè)離散數(shù)據(jù)包的裝 置。多個(gè)離散數(shù)據(jù)包中的至少一個(gè)包括接收者信息且多個(gè)離散數(shù)據(jù)包的 至少另外一個(gè)包括消息體。經(jīng)修改的接收裝置包括電子存儲器，用于將 多個(gè)離散數(shù)據(jù)包保存其中。經(jīng)修改的消息服務(wù)器進(jìn)一步包括如此裝置， 其用于處理多個(gè)離散數(shù)據(jù)包并且通過組合至少接收者信息和消息體來產(chǎn) 生消息。
在本發(fā)明的另外一個(gè)方面中，公開了一種在通過互聯(lián)網(wǎng)對接的消息 系統(tǒng)中用于處理來自發(fā)送者的消息組的方法。所述發(fā)送者通過能夠與多 個(gè)接收者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，其中每一組消息 想要傳送到接收者。所述方法包括在發(fā)送者服務(wù)器處從發(fā)送者接收用于 定義消息組的多個(gè)離散數(shù)據(jù)包，對于所述消息組中對應(yīng)的一個(gè)消息，多 個(gè)離散數(shù)據(jù)包中的至少一個(gè)包括接收者信息且多個(gè)離散數(shù)據(jù)包的至少另 外一個(gè)包括消息體。所述方法進(jìn)一步包括對于所述消息組中的每一個(gè) 消息，通過組合至少接收者信息和消息體來產(chǎn)生消息。所述方法還包括 對于所述消息組中的每一個(gè)消息，基于至少接收者信息和消息體之一以 根據(jù)預(yù)定規(guī)則集的次序來設(shè)置消息組。
在本發(fā)明的另一方面中，公開了一種在通過互聯(lián)網(wǎng)對接的消息系統(tǒng) 中用于處理來自發(fā)送者且想要傳送到至少一個(gè)接收者的消息的方法。所 述發(fā)送者通過能夠與接收者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng) 上。所述方法包括在發(fā)送者服務(wù)器處從發(fā)送者接收用于定義消息的多個(gè) 離散數(shù)據(jù)包。多個(gè)離散數(shù)據(jù)包中的至少一個(gè)包括接收者信息且多個(gè)離散 數(shù)據(jù)包的至少另外一個(gè)包括消息體。所述方法還包括將多個(gè)離散數(shù)據(jù)包
通過應(yīng)用程序接口導(dǎo)引到多個(gè)外部應(yīng)用之一，用于執(zhí)行至少下述之一(i) 根據(jù)第一預(yù)定規(guī)則集，修改多個(gè)離散數(shù)據(jù)包，(ii)根據(jù)第二預(yù)定規(guī)則集，
向多個(gè)離散數(shù)據(jù)包添加附加的數(shù)據(jù)包，以及(iii)根據(jù)第三預(yù)定規(guī)則集，對 多個(gè)離散數(shù)據(jù)包排序，并且因此，用于提供多個(gè)所得到的數(shù)據(jù)包。所述 方法進(jìn)一步包括通過應(yīng)用程序接口從多個(gè)外部應(yīng)用之一接收多個(gè)所得到 的數(shù)據(jù)包，并且通過組合多個(gè)所得到的數(shù)據(jù)包的至少一部分來產(chǎn)生消息。 所述方法附加地包括通過互聯(lián)網(wǎng)建立從發(fā)送者服務(wù)器到接收者服務(wù)器的 連接，并且將消息通過所述連接導(dǎo)引到接收者服務(wù)器，以便于傳送到接 收者。
在本發(fā)明的另一方面中，公開了一種通過互聯(lián)網(wǎng)對接、用于處理來 自發(fā)送者且想要傳送到至少一個(gè)接收者的消息的消息系統(tǒng)。發(fā)送者通過 能夠與接收者通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)，并且消息包括至少接 收者信息和消息體。消息系統(tǒng)包括測試裝置，其用于在依賴于接收者信 息來發(fā)送消息之前，借助于通過互聯(lián)網(wǎng)建立從發(fā)送者服務(wù)器到接收者服 務(wù)器的臨時(shí)測試連接，測試接收者信息，以便于提供消息到接收者的可 傳送性的指示，而無需使用SMTPVRFY命令。
在本發(fā)明的另外一個(gè)方面中，公開了一種通過互聯(lián)網(wǎng)對接、用于處 理來自發(fā)送者且想要傳送到至少一個(gè)接收者的消息的消息系統(tǒng)。發(fā)送者 通過能夠與接收者通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)，并且消息包括至 少接收者信息和消息體。消息系統(tǒng)包括測試裝置，其用于在依賴于接收 者信息來發(fā)送消息之前，借助于通過互聯(lián)網(wǎng)建立從發(fā)送者服務(wù)器到接收 者服務(wù)器的連接，測試接收者信息，以便于提供消息到接收者的可傳送 性的指示而無需使用SMTP VRFY命令。消息系統(tǒng)還包括選擇性傳送裝 置，用于基于所述指示，執(zhí)行下述之一(i)將消息通過所述連接導(dǎo)引到接 收者服務(wù)器以便于傳送到接收者(ii)放棄消息的傳送。
在本發(fā)明的另一方面中，公開了一種在通過互聯(lián)網(wǎng)對接的消息系統(tǒng) 中用于處理來自發(fā)送者且想要傳送到至少一個(gè)接收者的消息的方法。所
述發(fā)送者通過能夠與接收者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng) 上。所述方法包括將消息作為數(shù)據(jù)在電子存儲器中處置。作為附加的方 面，消息系統(tǒng)進(jìn)一步包括用于存儲文件的硬驅(qū)動器，并且消息在消息系 統(tǒng)中被處置而無需將消息作為所述文件之一存儲在硬驅(qū)動器中。
在本發(fā)明的另一方面中，公開了一種在通過互聯(lián)網(wǎng)對接的消息系統(tǒng) 中用于處理來自發(fā)送者的消息的方法。所述發(fā)送者通過能夠與多個(gè)接收 者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上。所述消息想要傳送到接 收者。所述方法包括在發(fā)送者服務(wù)器，將消息分開成多個(gè)離散的數(shù)據(jù)包， 其中多個(gè)離散數(shù)據(jù)包中的至少一個(gè)包括接收者信息且多個(gè)離散數(shù)據(jù)包的 至少另外一個(gè)包括消息體。所述方法還包括在依賴于接收者信息來發(fā) 送消息之前，借助于通過互聯(lián)網(wǎng)建立從發(fā)送者服務(wù)器到接收者服務(wù)器的 連接，來測試接收者信息，從便于提供到接收者的可傳送性的指示而無
需使用SMTP VRFY命令。所述方法進(jìn)一步包括基于所述指示，執(zhí)行
下述之一(i)通過所述連接導(dǎo)引所述消息，以便于通過接收者服務(wù)器傳送
到接收者(ii)放棄消息的傳送。作為選擇地，測試通過臨時(shí)測試連接被執(zhí)
行，而消息通過傳送連接導(dǎo)引。
在本發(fā)明的另外方面中，公開了一種用于在通過互聯(lián)網(wǎng)對接的消息 系統(tǒng)中處理消息組的方法。所述發(fā)送者通過能夠與多個(gè)接收者服務(wù)器通 信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上。消息組中的每個(gè)消息想要傳送到接
收者。所述方法包括在發(fā)送者服務(wù)器處，將消息組中的每個(gè)消息分開
成多個(gè)離散數(shù)據(jù)包，其中對于消息組當(dāng)中對應(yīng)的消息，多個(gè)離散數(shù)據(jù)包 中至少一個(gè)包括接收者信息且多個(gè)離散數(shù)據(jù)包中至少另一個(gè)包括消息
體。所述方法還包括對于消息組當(dāng)中的每個(gè)消息基于接收者信息和消 息體中至少之一以根據(jù)預(yù)定規(guī)則集的次序設(shè)置消息組。
在本發(fā)明的另一方面中，公開了一種在通過互聯(lián)網(wǎng)對接的消息系統(tǒng) 中用于處理來自發(fā)送者且想要傳送到至少一個(gè)接收者的消息的方法。所 述發(fā)送者通過能夠與接收者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)
上。消息系統(tǒng)包括用于處理數(shù)據(jù)的電子存儲器以及用于存儲文件的硬驅(qū) 動器。所述方法包括選擇至少以下之一(i)將消息作為數(shù)據(jù)在電子存儲器 中處置，無需將消息作為文件之一而存儲在硬驅(qū)動器中，以及(ii)將消息 作為文件之一而存儲在硬驅(qū)動器中。


通過參考結(jié)合下面簡要說明的附圖給出的下述詳細(xì)說明，本發(fā)明可 得到理解。注意出于示例清楚的目的，附圖中的某些元件可能未被按 照比例繪畫。
圖1A是示出根據(jù)目前可獲得的現(xiàn)有技術(shù)用于通過互聯(lián)網(wǎng)發(fā)送電子
消息的e-mail消息系統(tǒng)的主要組件的示意性示例。
圖IB是示例通過使用圖1A中所示系統(tǒng)通過互聯(lián)網(wǎng)發(fā)送電子消息的 過程的流程圖。
圖2是e-mail消息的示意性示例，在此被示出示例e-mail消息的主 要組件。
圖3是在現(xiàn)有技術(shù)中所實(shí)踐的VRFY過程的示意性示例。
圖4A是根據(jù)本發(fā)明的SMTP通信過程的示意性示例。
圖4B和4C是示出根據(jù)本發(fā)明分別具有肯定和否定結(jié)果的基于
SMTP的接收者信息確認(rèn)過程的更多細(xì)節(jié)的示意性示例。
圖5A是根據(jù)本發(fā)明用于接收多個(gè)數(shù)據(jù)包及隨后發(fā)送包含多個(gè)數(shù)據(jù)
包中至少一部分的電子信息的郵件服務(wù)器系統(tǒng)的示意性示例。
圖5B和5C是示例帶有與不帶有本發(fā)明的基于域的流程控制的接收
者域的理論分布的示范圖。
圖5D是適合于用在本發(fā)明郵件服務(wù)器系統(tǒng)中的動態(tài)IP選擇過程的
示意性示例。
圖6A和6B是示例根據(jù)本發(fā)明的接收者服務(wù)器信息驗(yàn)證過程的可能 實(shí)施例的流程圖。
圖7A和7B是示例根據(jù)本發(fā)明的接收者服務(wù)器信息和接收者信息驗(yàn)
證過程的可能實(shí)施例的流程圖。
圖8A和8B是示例根據(jù)本發(fā)明接收者服務(wù)器信息和包括遲消息產(chǎn)生 的接收者信息驗(yàn)證過程的可能實(shí)施例的流程圖。
圖9A和9B是將通過互聯(lián)網(wǎng)發(fā)送電子消息的現(xiàn)有技術(shù)"存儲和前轉(zhuǎn)" 過程與本發(fā)明的"構(gòu)建和前轉(zhuǎn)"相比較的流程圖。
圖IOA和10B是將在處置電子消息時(shí)用于添加補(bǔ)充過程的現(xiàn)有技術(shù) 方法與本發(fā)明方法相比較的流程圖。
圖11A是示例現(xiàn)有技術(shù)的MILTER API事件管理和分布的流程圖。
圖IIB和IIC分別是本發(fā)明的事件后及事件前API過程的示意性示
圖11D是根據(jù)本發(fā)明在郵件服務(wù)器處API事件登記的示意性示例。 圖11E是示例根據(jù)本發(fā)明的API事件管理和分布過程的流程圖。 圖12A和12B是示例根據(jù)本發(fā)明的可配置RAM/HDD消息過程的可 能實(shí)施例的流程圖。
圖13A是現(xiàn)有技術(shù)插槽通信的單線程模型的示意性示例。
圖13B是示例圖13A中現(xiàn)有技術(shù)的單線程模型插槽通信過程的流程圖。
圖13C是用于現(xiàn)有技術(shù)服務(wù)器之間的數(shù)據(jù)傳輸?shù)亩嗑€程模型、插槽 通道及選擇器實(shí)施例的示意性示例。
圖13D是示例對應(yīng)于圖13B使用TCP的現(xiàn)有技術(shù)選擇器過程的流程
圖13E是根據(jù)本發(fā)明的多線程模型、插槽通道及選擇器通信模型。 圖13F是示例根據(jù)本發(fā)明使用TCP的插槽通道和選擇器過程的流程圖。
圖13G是示例使用UDP的本發(fā)明選擇器處理的流程圖。
具體實(shí)施例方式
下述說明被呈現(xiàn)以使能現(xiàn)有技術(shù)中的普通技術(shù)人員之一能夠制作且 使用本發(fā)明，并且其在專利申請和其要求中的相關(guān)內(nèi)容中被提供。對所 說明實(shí)施例的各種修改，對本領(lǐng)域中的那些普通人員將容易地是顯而易 見，并且在此通用原理可被應(yīng)用于其它實(shí)施例。因此，本發(fā)明并不想要 限制于所示的實(shí)施例，而是要符合與在此所說明的原理和特征一致的最 寬范圍。
在目前現(xiàn)有技術(shù)中的問題
與操作系統(tǒng)中的進(jìn)步相結(jié)合，本領(lǐng)域的進(jìn)步已經(jīng)產(chǎn)生傳送速度和硬
件效率的改善。然而，在e-mail MTA的眾多關(guān)鍵特征中存在問題，其限 制了性能、靈活性、柔軟性、安全性及特征增強(qiáng)方面的進(jìn)步。
SMTP饋送的問題
E-mail最初被建立用來將電子消息從計(jì)算機(jī)網(wǎng)絡(luò)上的一個(gè)發(fā)送者 (通常是人)傳輸?shù)搅硪话l(fā)送者。E-mail MTA被建立用來接收和傳送來 往于當(dāng)?shù)剜]件傳送代理的e -mail消息，所述當(dāng)?shù)剜]件傳送代理掌控到主 機(jī)或網(wǎng)絡(luò)之外的其它MTA的發(fā)送者帳戶。隨著使用e-mail和互聯(lián)網(wǎng)的增 長，用戶和組織開始鑒別人類-發(fā)送者所產(chǎn)生的通信以外的e-mail應(yīng)用， 開始是使用e-mail用于大眾公告及發(fā)展成直接營銷、自動化事務(wù)處理、 支持和客戶照管等應(yīng)用。這些新的應(yīng)用提供了巨大的潛力，用于急劇地 降低成本且改善大眾通信活動的效率，且因此加速了對對應(yīng)技術(shù)方案的 興趣。
E-mail最有前途的應(yīng)用圍繞在使用有關(guān)客戶、成員或訂戶的信息數(shù) 據(jù)庫以識別接收者、填充消息內(nèi)容及觸發(fā)e-mail傳送的能力上。更基本 地，在網(wǎng)頁上交互和事務(wù)處理盛行的增加驅(qū)動對e-mail接收和其它在線 交互的確認(rèn)的需要。
因此，使數(shù)據(jù)庫和當(dāng)?shù)鼐W(wǎng)絡(luò)應(yīng)用能發(fā)送e-mail變得重要，但是，由 于在這種情況下消息將由系統(tǒng)命令來建立且并不由單個(gè)用戶來創(chuàng)作，所 以標(biāo)準(zhǔn)的MDA將不支持所要求的過程，并且e-mail將不得不被直接地 從這些系統(tǒng)發(fā)送到MTA。然而，MTA僅接受預(yù)先形成的SMTP消息， 而網(wǎng)及數(shù)據(jù)庫應(yīng)用產(chǎn)生數(shù)據(jù)輸出。因而，系統(tǒng)開發(fā)商為當(dāng)?shù)叵到y(tǒng)和按目 的建立的e-mail營銷和公布系統(tǒng)建立SMTP"饋送裝置"(例如Javamail)， 其將數(shù)據(jù)包轉(zhuǎn)化成電子消息，以便于傳輸?shù)疆?dāng)?shù)豈TA。然而SMTP饋送 裝置固有地將任何MTA的傳送速度限制到它可以由饋送裝置來饋送的 速率(在目前技術(shù)中，在持續(xù)的基礎(chǔ)上每小時(shí)約200,000個(gè)e-mail)。
此外，隨著e-mail的使用變得更加復(fù)雜，日益希望使用來自兩個(gè)或 更多源系統(tǒng)的信息來產(chǎn)生消息。例如，電子商務(wù)應(yīng)用可產(chǎn)生用于文本消 息的數(shù)據(jù)，其包含在最近所完成的事務(wù)處理中的特定的信息?？上Ｍ?是基于被包含在消息中的信息，從單獨(dú)的系統(tǒng)中抽出作為目標(biāo)的廣告 或服務(wù)內(nèi)容。在目前的現(xiàn)有技術(shù)中，這種來自多個(gè)源系統(tǒng)的信息組合將 要求在向SMTP饋送裝置呈遞全部內(nèi)容數(shù)據(jù)集之前，處理第一系統(tǒng)和 第二系統(tǒng)之間的事務(wù)處理，用于產(chǎn)生SMTP e-mail消息。第一和第二系統(tǒng) 之間的這個(gè)處理暗示著這些系統(tǒng)之間重大的集成，正如就申請人所知道 的最大程度，僅由一個(gè)公司，Amazon.com，針對大規(guī)模e-mail操作已經(jīng) 執(zhí)行的那樣。
另外，可希望的是e-mail MTA支持其它的電子消息協(xié)議格式，以 便于基于每個(gè)消息內(nèi)的技術(shù)規(guī)范，集中的業(yè)務(wù)邏輯或其它機(jī)制，接受其 它協(xié)議中的消息以便于轉(zhuǎn)換成SMTP e-mail或接受SMTP email消息以便 于轉(zhuǎn)換成其它協(xié)議。
存儲和前轉(zhuǎn)處理中的問題
與SMTP饋送的實(shí)踐有關(guān)的是存儲和前轉(zhuǎn)處理的目前實(shí)踐，其中 MTA將SMTP e-mail消息接受到應(yīng)用中、將每一個(gè)寫入到硬驅(qū)動器上的
文件上、通過傳送過程將其發(fā)送并且隨后從硬驅(qū)動器中刪除所存儲的消
息。這個(gè)實(shí)踐產(chǎn)生了 e-mail傳送的眾多問題。
如先前所討論，向硬驅(qū)動器寫入文件，文件I/0是長期存在的MTA 性能中的問題。雖然在非同步文件I/0上的最新革新已經(jīng)改善了性能，但 是機(jī)械地從硬驅(qū)動器讀取和向其寫入文件的活動固有地是處理密集型的 且趨向于瓶頸。
存儲和前轉(zhuǎn)處理的附加問題是在系統(tǒng)中消息處理的順序的、先進(jìn)先 出(FIFO)性質(zhì)，其由如此事實(shí)引起，即每個(gè)e-mail隔離于與正在被處理 的相結(jié)合或相鄰而發(fā)送的任何其它e-mail被處理。這導(dǎo)致在大量MTA e-mail傳送性能中的最顯著問題之一。E-mail被順序地排隊(duì)， 一個(gè)接在另 一個(gè)后面，以便于通過工作連接傳輸。在大量應(yīng)用中，消息按照域進(jìn)一 步分組。這呈現(xiàn)了不利的情況，其中SMTP通信在相同域被同時(shí)地導(dǎo)引， 從而增加了在接收者域MTA的減緩或連接失敗的可能性。當(dāng)這種連接被 嘗試且減緩或失敗時(shí)，它們變成不工作的。在到同一域的各個(gè)消息依次 通過應(yīng)用時(shí)建立的多個(gè)被嘗試的連接使附加的連接不工作，并且減緩或 停止了該應(yīng)用上的傳送，而不管極大數(shù)量線程的初始的可用性。
與存儲和前轉(zhuǎn)處理相聯(lián)系的FIFO處理產(chǎn)生對E-mail發(fā)送的附加限 制。與連接變得不工作時(shí)系統(tǒng)不能夠回顧多個(gè)接收者地址來管理傳送嘗 試相同，也不能回顧信息和消息組，以對隊(duì)列或隊(duì)列集上的業(yè)務(wù)量確定 優(yōu)先權(quán)，其中可能希望的是通過MTA給e-mail業(yè)務(wù)量賦予優(yōu)先權(quán)。
存儲和前轉(zhuǎn)處理的最終問題是缺少用于引入向消息作任何添加或 對消息加以修改的任何機(jī)制。與SMTP饋送問題緊密相聯(lián)，固定消息被 輸入進(jìn)MTA并且經(jīng)歷嚴(yán)格定義的用于傳送到最終接收者的過程集這一 事實(shí)，將MTA的功能性嚴(yán)格限制于中繼消息。隨著e-mail過程如安全證 書，用戶化的內(nèi)容等的進(jìn)步，現(xiàn)在存在許多應(yīng)用，所述應(yīng)用使得在從發(fā) 送者應(yīng)用(MDA或其它系統(tǒng)中)到互聯(lián)網(wǎng)的過渡中修改信息是高度理想 的。參考SMTP饋送，類似于使用兩個(gè)或更多個(gè)系統(tǒng)來產(chǎn)生消息的問題，
無能力修改傳播通過MTA的消息內(nèi)容導(dǎo)致目前技術(shù)，其中產(chǎn)生e-mail 內(nèi)容修改的應(yīng)用必須在發(fā)送之前被結(jié)合進(jìn)入發(fā)送應(yīng)用中用于處理。
組合的驗(yàn)證及傳輸以及中繼的問題
共同地所知，在當(dāng)前現(xiàn)有的MTA e-mail發(fā)送技術(shù)中， 一旦MTA識 別出接收者服務(wù)器并且打開連接時(shí)， 一系列信息事務(wù)處理發(fā)生，其中發(fā) 送MTA驗(yàn)證接收者服務(wù)器的可用性并且接收者服務(wù)器驗(yàn)證消息的可傳 送性。在現(xiàn)有技術(shù)中，不管驗(yàn)證結(jié)果如何，MTA均將消息發(fā)送到接收者 MTA。如果消息最終被證明為不可傳送，則接收者服務(wù)器將SMTP錯(cuò)誤 消息發(fā)送回到發(fā)送MTA，其將隨后重新發(fā)送消息。這個(gè)過程通常繼續(xù)通 過幾個(gè)嘗試，此時(shí)對于原始不可傳送的e-mail以及對于依照它們彈回和 隨后的重新發(fā)送，通過利用顯著的處理開銷、以及帶寬，發(fā)送MTA將失 敗報(bào)告回到始發(fā)發(fā)送者或系統(tǒng)。
在e-mail傳送中長期的問題是改善這個(gè)過程，這是通過在發(fā)送消息 之前驗(yàn)證接收者e-mail地址的可傳送性，并且在它并不可傳送的情況下 不發(fā)送它。為了驗(yàn)證在大清單中e-mail地址的可傳送性，以將永久地不 可傳送的那些e-mail地址去除以不進(jìn)行未來嘗試的目的，也一直在努力 解決這個(gè)問題。迄今為止，嘗試已經(jīng)被集中在使用出于此目的被內(nèi)置于 sendmail的驗(yàn)證過程及VRFY命令，其被設(shè)計(jì)成獨(dú)立于標(biāo)準(zhǔn)的用于發(fā)送 e-mail的SMTP通信過程。然而，這個(gè)單獨(dú)的驗(yàn)證過程還可能被網(wǎng)絡(luò)以 外的操作者使用，用來經(jīng)由自動的反復(fù)試驗(yàn)來識別網(wǎng)絡(luò)內(nèi)有效的e-mail 地址，從而引起顯著的安全危害。
現(xiàn)在結(jié)合圖1A參考圖3，在圖1A的現(xiàn)有技術(shù)消息系統(tǒng)中成功使用 VRFY命令的過程被說明。在步驟102通過連接到接收者M(jìn)TA 40， VRFY 過程100由發(fā)送者M(jìn)TA20啟動。在步驟104接收者M(jìn)TA40關(guān)注連接。 然后在步驟106發(fā)送者M(jìn)TA20向接收者M(jìn)TA40發(fā)送"HELO"。在步驟 108，通過在步驟108以"歡迎"作出響應(yīng)，接收者M(jìn)TA40告知問候。
發(fā)送者M(jìn)TA 20以VRFY命令隨其后，以驗(yàn)證預(yù)期接收者的e-mail地址 的有效性。如果在VRFY命令中被發(fā)送的預(yù)期接收者的e-mail地址在接 收者M(jìn)TA40中是正確的，則在步驟112中接收者M(jìn)TA以"Okay"作出 響應(yīng)。否貝ij，接收者M(jìn)TA40通知發(fā)送者M(jìn)TA40:在VRFY命令中所發(fā) 送的e-mail地址的用戶并未通過發(fā)送者M(jìn)TA40與互聯(lián)網(wǎng)對接。
VRFY命令是方便的，因?yàn)檫@個(gè)特征被內(nèi)置于被公共地使用的應(yīng)用 sendmail中。然而，由于對VRFY過程的支持是在接收者sendmail MTA 上的任選設(shè)置，并且對于標(biāo)準(zhǔn)的e-mail傳送操作并不是關(guān)鍵性的，所以 為安全防范，這個(gè)特征被廣泛地禁止。即，接收者M(jìn)TA 40不是在步驟 112中以"Okay"或以否定結(jié)果作出響應(yīng)，而是以VRFY特征已經(jīng)被禁止-由此未能確認(rèn)或否認(rèn)預(yù)期接收者的e-mail地址的準(zhǔn)確性-的通知對來自發(fā) 送者M(jìn)TA的VRFY命令作出響應(yīng)。因此，申請人提出VRFY命令本身 并不是對e-mail驗(yàn)證問題的解決方案。
MTA應(yīng)用程序接口的問題
如前所提到，在使用和應(yīng)用e-mail上的增長已經(jīng)導(dǎo)致對下述過程的 需要和要求，即對e-mail消息的作用、修改、檢査和否則與其交互的過 程。今天，如此過程包括病毒保護(hù)應(yīng)用、SPAM過濾、內(nèi)容過濾、加密、 網(wǎng)絡(luò)簽名、策略過濾、HTML模板應(yīng)用等。此外，雖然如前所述通過與 啟動發(fā)送者系統(tǒng)(雖然有困難)結(jié)合，內(nèi)容修改應(yīng)用可以被應(yīng)用，但是當(dāng)掃 描過程行進(jìn)或通過網(wǎng)絡(luò)時(shí)其通過限定應(yīng)用到電子消息?，F(xiàn)有技術(shù)電子消 息傳送過程中現(xiàn)存的問題是MTA架構(gòu)的盛行，所述MTA架構(gòu)將目前的 MTA過程與至多單個(gè)外部過程組合在一個(gè)序列中。此外，在多個(gè)外部過 程必須在系統(tǒng)或網(wǎng)絡(luò)中的消息上進(jìn)行的情況下，這種外部過程必須通過 一序列單獨(dú)MTA被串行地應(yīng)用。
在目前現(xiàn)有技術(shù)中，這種過程被串行地應(yīng)用，這是通過將每個(gè)信 息通過由接收MTA所支持的單獨(dú)應(yīng)用來發(fā)送，以接受消息，并且單獨(dú)的 發(fā)送MTA將它們前轉(zhuǎn)到下一個(gè)處理應(yīng)用或主MTA以便于通過互聯(lián)網(wǎng)傳 送。結(jié)果是，整個(gè)系統(tǒng)的傳送效率受到通過多個(gè)MTA和處理應(yīng)用的串行 處理層的傳送效率的限制。所述架構(gòu)還在硬件和支持上是密集型的。
建議的方案
如上所說明，在當(dāng)前可用MTA的SMTP饋送中的固有局限抑制或限 制了現(xiàn)有技術(shù)MTA來提供下述特征的能力，如例如增加的傳送速度及來 自多個(gè)源系統(tǒng)數(shù)據(jù)庫數(shù)據(jù)信息的組合。作為對這些問題的解決方案，申 請人提出了這樣的MTA，其通過應(yīng)用程序接口(API)可以接受數(shù)據(jù)元素、 原始數(shù)據(jù)文件或其它電子消息格式，并且使用相關(guān)的數(shù)據(jù)項(xiàng)來在MTA應(yīng) 用內(nèi)建立SMTP e-mail。電子消息可例如是SMTP消息或e-mail,或想要 從發(fā)送者傳送到預(yù)期接收者的其它格式的電子數(shù)據(jù)包。
因使用通信的存儲和前轉(zhuǎn)模式而導(dǎo)致現(xiàn)有技術(shù)MTA中存在附加問 題。申請人提出，對這個(gè)問題的一個(gè)解決方案是在直接地由處理器芯 片可訪問的隨機(jī)存取存儲器(RAM-即電子存儲器)中存儲消息，因此消除 了與文件I/O相聯(lián)系的機(jī)械動作，以實(shí)現(xiàn)效率的巨大增加。在e-mail發(fā) 展過程的早期，文件I/O方法被設(shè)計(jì)成確保在系統(tǒng)失敗情況下在過程中被 存儲的消息的可恢復(fù)能力，以及被結(jié)合在現(xiàn)代MTA的基本架構(gòu)中。今天， 在過程中丟失消息的風(fēng)險(xiǎn)被極大地降低，這是通過已經(jīng)增加了傳送處 理速度，以便于存儲時(shí)間被降低到接近于零的這一進(jìn)步，以及通過可以 設(shè)計(jì)當(dāng)系統(tǒng)失敗時(shí)向硬驅(qū)動器寫入文件的機(jī)制的潛在便利性。
由現(xiàn)有技術(shù)MTA的存儲和前轉(zhuǎn)過程所引發(fā)的另一問題是消息處理 的順序的先進(jìn)先出(FIFO)性質(zhì)，其經(jīng)常導(dǎo)致處理瓶頸并且排除任何形式的 業(yè)務(wù)量優(yōu)先或排隊(duì)管理。作為對這一問題的解決方案，申請人提出使 MTA能回顧消息組或接收者清單上的域組成，并且對用于傳送的處理消 息排序，以將連接嘗試分布到清單上的各個(gè)域。通過此方法，接收者M(jìn)TA 減緩及失敗的可能性以及由于試圖傳送到相同的問題域而耗盡線程連接
所產(chǎn)生的潛在瓶頸被減到最小。此外，本發(fā)明提供一種靈活的可用戶化 的過程，以優(yōu)化和管理消息業(yè)務(wù)量。
本發(fā)明還為可傳送性驗(yàn)證問題提供一種解決方案，即通過重新設(shè)計(jì)
標(biāo)準(zhǔn)的SMTP通信過程來使能一種交替的消息過程，其在標(biāo)準(zhǔn)的SMTP
轉(zhuǎn)換期間接收可傳送性失敗響應(yīng)。在這個(gè)過程中，這些消息并不被發(fā)送
到接收者M(jìn)TA，而是相反經(jīng)由附加的SMTP傳送通信嘗試被重試，直至 它們被驗(yàn)證為可傳送的且然后被發(fā)送，或作為傳送失敗被報(bào)告到始發(fā)的 發(fā)送者或系統(tǒng)且被終止。
閉合的架構(gòu)問題也被本發(fā)明減輕。本發(fā)明提供了一種MTA應(yīng)用，所 述MTA應(yīng)用使能通過在標(biāo)準(zhǔn)SMTP過程的若干階段的任何階段，開式接 口對為此過程而設(shè)計(jì)的可兼容應(yīng)用的可用性將隨之而來的e-mail過程， 如掃描和修改與MTA應(yīng)用本身的緊密結(jié)合。這種MTA應(yīng)用可接受用于 傳送的e-mail、或e-mail等效的數(shù)據(jù)文件，并且通過直接的數(shù)據(jù)接口，通 過這些所添加的過程在將它們傳送到接收者M(jìn)TA之前將它們導(dǎo)引。本發(fā) 明的這些及其它的特征在此后將更詳細(xì)地被說明。
現(xiàn)在結(jié)合圖1A轉(zhuǎn)到圖4A-4C，圖1A的現(xiàn)有技術(shù)消息系統(tǒng)中的成功 SMTP發(fā)送過程200的進(jìn)一步詳情被示出。圖4A示例圖1A中發(fā)送者 MTA20與接收者M(jìn)TA40之間的通信過程。在步驟202中通過連接到接 收者M(jìn)TA 40，發(fā)送者M(jìn)TA 20啟動過程200。接收者M(jìn)TA 40在步驟204 中通過關(guān)注發(fā)送者M(jìn)TA作出響應(yīng)。發(fā)送者M(jìn)TA20然后在步驟206向接 收者M(jìn)TA 40發(fā)送"HELO"。在步驟208接收者M(jìn)TA 40通過向發(fā)送者 MTA20發(fā)送"歡迎"而作出響應(yīng)。在步驟210，發(fā)送者M(jìn)TA20通知接 收者M(jìn)TA40即將到來的e-mail消息。如果接收者M(jìn)TA40正在接受進(jìn)入 的消息，則接收者M(jìn)TA40在步驟212以"Okay"作出響應(yīng)，由此確認(rèn)接 收者M(jìn)TA的可用性。在步驟214發(fā)送者M(jìn)TA 20然后向接收者M(jìn)TA 40 指示預(yù)期接收者的e-mail地址。如果這樣指示的e-mail地址在接收者M(jìn)TA 處是有效的e-mail地址，則接收者M(jìn)TA 40然后在步驟216以"Okay"
作出響應(yīng)，因此確認(rèn)預(yù)期接收者e-mail地址的有效性。在步驟218，發(fā)送 者M(jìn)TA20然后向接收者M(jìn)TA40指示將要向此發(fā)送數(shù)據(jù)。在這個(gè)成功的 SMTP發(fā)送過程200中，接收者M(jìn)TA 40在歩驟220以"幵始"作出響應(yīng)， 此時(shí)在步驟222發(fā)送者M(jìn)TA 20開始發(fā)送e-mail消息。在接收到e-mail 消息時(shí)，接收者M(jìn)TA 40在步驟223以另一 "Okay"作出響應(yīng)。然后在 步驟226發(fā)送者M(jìn)TA 20以"退出"指示e-mail發(fā)送過程結(jié)束，在步驟 228接收者M(jìn)TA40以"Okay"對其作出響應(yīng)。最終地，在步驟230發(fā)送 者M(jìn)TA20從接收者M(jìn)TA40斷開連接，并且類似地，在步驟232接收者 MTA40從發(fā)送者M(jìn)TA20斷開連接，從而完成成功的SMTP發(fā)送過程。
繼續(xù)參考圖4A，強(qiáng)調(diào)地是在本發(fā)明過程中在正常SMTP通信過程中 e-mail消息傳送能力(g卩，接收者M(jìn)TA可傳送性及預(yù)期接收者信息的有 效性)的確認(rèn)被完成，而無需求助于例如在現(xiàn)有技術(shù)中的VRFY命令。 通過這種方法，本發(fā)明避開了現(xiàn)有技術(shù)中的問題，而同時(shí)與使用現(xiàn)有技 術(shù)MTA所可能的相比較，提供具有顯著較少彈回的高得多的性能。
圖4B和4C示例圖4A所示的確認(rèn)過程的兩個(gè)可能的結(jié)果。示出成 功的確認(rèn)過程250的圖4B基本上與圖4A中成功的SMTP發(fā)送過程200 的前幾步相同?；旧?，在發(fā)送者M(jìn)TA20與接收者M(jìn)TA40之間的正常 SMTP通信過程中，在步驟210和212中，用來接受進(jìn)入消息的接收者 MTA的可用性被確認(rèn)，并且在步驟213和216中預(yù)期接收者的e-mail地 址的有效性被確認(rèn)。相對照，圖4C示例未成功的確認(rèn)過程250'，其中 接收者M(jìn)TA 40響應(yīng)于在步驟214預(yù)期的接收者信息查詢，在步驟252 以"用戶未知"消息向發(fā)送者M(jìn)TA發(fā)送。g卩，預(yù)期接收者e-mail地址的 有效性己經(jīng)被否認(rèn)。響應(yīng)于所述否認(rèn)，發(fā)送者M(jìn)TA可例如放棄消息傳送 過程且開始繼續(xù)到處理在隊(duì)列中等待的下一個(gè)電子消息。
現(xiàn)在注意力轉(zhuǎn)到圖5A-5D，其示例本發(fā)明消息傳送系統(tǒng)的進(jìn)一步增 強(qiáng)。首先參考圖5A，電子消息傳送系統(tǒng)300包括發(fā)送者M(jìn)TA320。發(fā)送 者M(jìn)TA 320被配置成接受由多個(gè)發(fā)送者326始發(fā)的多個(gè)數(shù)據(jù)包320A(被
包圍在虛線框324A中)。多個(gè)數(shù)據(jù)包322A可包括，例如組成e-mail消息 的各種組件，如圖2中所示。發(fā)送者326可是例如通過發(fā)送者M(jìn)TA 320 對接到互聯(lián)網(wǎng)的人類用戶。正如現(xiàn)有技術(shù)中的MTA，發(fā)送者M(jìn)TA320可 附加地被配置成從發(fā)送者326接受多個(gè)完整的電子消息328。發(fā)送者M(jìn)TA 320也被配置成接受由與數(shù)據(jù)庫332接口的計(jì)算機(jī)系統(tǒng)330所產(chǎn)生的多個(gè) 數(shù)據(jù)包322B(包圍在虛線框324B中)。例如，計(jì)算機(jī)系統(tǒng)330可將包含在 數(shù)據(jù)庫332中的元素轉(zhuǎn)換成如圖2中所示的e-mail消息的各種組件。
繼續(xù)參考圖5A，發(fā)送者M(jìn)TA320包括隨機(jī)存取存儲器(RAM) 336， 以便于，當(dāng)發(fā)送者M(jìn)TA320接收多個(gè)數(shù)據(jù)包322A和322B時(shí)，那樣所接 收的數(shù)據(jù)包被保存在RAM中而不是作為硬驅(qū)動器上的單獨(dú)文件。結(jié)果 是，MTA320能夠執(zhí)行增強(qiáng)過程，如例如靜態(tài)內(nèi)容含括340、基于域的流 程控制342、動態(tài)IP分配344及甚至可傳送性確認(rèn)346，然后從多個(gè)數(shù) 據(jù)包322A和322B產(chǎn)生待通過互聯(lián)網(wǎng)30導(dǎo)引的多個(gè)最終電子消息350。
強(qiáng)調(diào)地是在發(fā)送者M(jìn)TA320中的增強(qiáng)過程通過下述事實(shí)而便利，即 發(fā)送者M(jìn)TA 320被配置成將數(shù)據(jù)包接受到RAM而不僅依賴于作為文件 被保存在硬驅(qū)動器上的完整電子消息。由于最終的電子消息從各種數(shù)據(jù) 包產(chǎn)生，所以電子消息傳送系統(tǒng)300被稱為"構(gòu)建和前轉(zhuǎn)"系統(tǒng)，而不 是先前所說明的現(xiàn)有技術(shù)的"存儲和前轉(zhuǎn)"系統(tǒng)。構(gòu)建和前轉(zhuǎn)系統(tǒng)比存 儲和前轉(zhuǎn)系統(tǒng)提供顯著的優(yōu)點(diǎn)，因?yàn)楸话ㄔ跇?gòu)建和前轉(zhuǎn)系統(tǒng)中的增加 過程可全部在RAM中被處置，而不是像在存儲和前轉(zhuǎn)系統(tǒng)中要求一系列 的文件讀取或重寫。而且，當(dāng)可傳送性確認(rèn)被包括在增強(qiáng)過程中時(shí)，發(fā) 送者M(jìn)TA 320可被如此配置，以便于如果那個(gè)最終的電子消息350的可 傳送性未被確認(rèn)，則它并不產(chǎn)生最終的電子消息350，從而導(dǎo)致處理時(shí)間 和通信帶寬的節(jié)省。
圖5B和5C是示出在不帶有域名分布的現(xiàn)有技術(shù)系統(tǒng)中以及在包括 域名分布的本發(fā)明電子消息傳送系統(tǒng)中，在傳送多個(gè)電子消息過程中典 型的域名分布圖。首先考慮圖5B，在電子消息的典型批處理中，例如在
大量e-mail發(fā)送環(huán)境中，趨向于e-mail消息被發(fā)送到少量大的互聯(lián)網(wǎng)服 務(wù)提供商域名。例如，大多數(shù)e-mail消息可想要針對通過主要提供商如 AOLTM、 MSN窗、HOTMailTM及Yahoo 對接的接收者。在圖5B中，其 中示出時(shí)間由x軸362所表示且消息計(jì)數(shù)由y軸364所表示的圖360，每 個(gè)垂直條366A、 366B等表示在給定時(shí)間被導(dǎo)引到特定域的e-mail消息 的數(shù)量。由于大多數(shù)接收者地址集中于少數(shù)域名，導(dǎo)致在傳送嘗試中的 域名分布趨向于隨著時(shí)間而相當(dāng)?shù)夭黄骄?。在圖5B中所示例的實(shí)例中， 圖360表示如此情況，其中發(fā)送者M(jìn)TA (或e-mail消息產(chǎn)生數(shù)據(jù)庫)趨 向于將被導(dǎo)引到特定域名的e-mail消息一起組成組。例如，發(fā)送者M(jìn)TA 可開始于將大量e-mail消息導(dǎo)引到AOl7M(如由垂直條366A所表示)，然 后到MAN ,由垂直條366B所表示)并且如此一直隨著時(shí)間到較小ISP 的域。結(jié)果是，發(fā)送者M(jìn)TA必須在初始的發(fā)送時(shí)間段內(nèi)發(fā)送出大量e-mail 消息，然后隨著時(shí)間進(jìn)展則為較小數(shù)量，使得發(fā)送者M(jìn)TA的處理能力隨 著時(shí)間被不均勻地利用，且傳送速度和性能受損害。此外，某些提供商 具有過濾能力，其禁止在短時(shí)間范圍內(nèi)對來自單個(gè)發(fā)送者M(jìn)TA的大量 e-mail的接收。
相對照，圖5C示出根據(jù)本發(fā)明具有基于域的流程控制的消息傳送的 圖370，時(shí)間再次由x軸372表示且消息計(jì)數(shù)由y軸374表示。在圖370 中，電子消息到每個(gè)域的傳送隨著時(shí)間被分布，使得每個(gè)水平條376A、 376B等表示在給定時(shí)間被導(dǎo)引到特定域的e-mail消息的數(shù)量。正如在圖 5C中可以看出，被導(dǎo)引到特定域的消息數(shù)量隨著時(shí)間被均勻地分布，使 得本發(fā)明發(fā)送者M(jìn)TA的傳送速度和性能較現(xiàn)有技術(shù)得到大大地改善。而 且，均勻的域分布減緩因大量消息傳送導(dǎo)致的消息傳送被阻塞在特定域 的問題。域名分布被圖5A中發(fā)送者M(jìn)TA 320的特征使能，以接受包含 e-mail消息的構(gòu)建塊的數(shù)據(jù)包。即，不像現(xiàn)有技術(shù)MTA，在最終的電子 消息被產(chǎn)生之前，發(fā)送者M(jìn)TA320能夠操縱e-mail消息的組件，以便于 執(zhí)行如此任務(wù)，如基于域的消息分布和流程控制。因本發(fā)明MTA處理數(shù)
據(jù)包而不是整個(gè)電子消息文件的能力，導(dǎo)致將這種的附加處理步驟結(jié)合 進(jìn)入消息傳送過程本身被極大地簡化。申請人提出這個(gè)特征在大量及/ 或大批消息環(huán)境中尤為有利。
圖5D示例圖5A的動態(tài)IP分配344的細(xì)節(jié)。如圖5A中所示，在步 驟380，動態(tài)IP分配344開始于IP地址的請求，隨后是步驟382的選擇 IP地址。在圖5A中所示例的實(shí)施例中，選擇IP地址步驟382包括旋轉(zhuǎn) 通過IP地址弁l-弁8(由圓圈384A-384H表示)，以便于相繼的外出消息并不 具有相同的始發(fā)IP地址。申請人提出這個(gè)特征在大量消息傳送中尤為 有利。
圖6A是示例根據(jù)本發(fā)明包括基于域的流程控制、接收者服務(wù)器可用 性確認(rèn)及數(shù)據(jù)庫反饋回路的電子消息傳送過程的步驟。特別地，如圖6A 中所示的過程400A包括通過單個(gè)SMTP通信發(fā)生的確認(rèn)和傳送步驟。過 程400A從數(shù)據(jù)庫402啟動，從此有關(guān)特定e-mail消息或多個(gè)e-mail消息 的信息(即數(shù)據(jù)包)被抽取。在過程400A中，數(shù)據(jù)包被從數(shù)據(jù)庫402導(dǎo)引 到基于域的流程控制步驟(被示為框404)，其提供如上面參考圖5A至5C 所說明的基于域的流程控制。跟著基于域的流程控制步驟，在步驟406 數(shù)據(jù)包的特定集合或記錄被選擇用于傳送嘗試。然后在步驟408 SMTP 連接被啟動。 一旦SMTP連接已經(jīng)被建立，則判斷410被執(zhí)行以確定接 收者服務(wù)器是否存在(即確認(rèn))。如果判斷410的結(jié)果是NO，則接收者服 務(wù)器不存在，則在步驟412，過程400A進(jìn)行到退出SMTP連接，然后在 步驟414向數(shù)據(jù)庫402記錄傳送失敗。如果判斷410的結(jié)果是YES，則 接收者服務(wù)器的確存在，則在步驟420，過程400A繼續(xù)進(jìn)行以將e-mail 消息傳送到接收者服務(wù)器，在步驟424退出SMTP連接，然后在步驟426 將成功的傳送記錄到數(shù)據(jù)庫402。以這種方式，基于域的流程控制、接收 者服務(wù)器可用性確認(rèn)以及數(shù)據(jù)庫反饋全部通過單個(gè)SMTP連接在單個(gè)過 程中被完成。
現(xiàn)在結(jié)合圖6A參考圖6B，圖6B是示例同樣根據(jù)本發(fā)明的包括基
于域的流程控制、接收者服務(wù)器可用性確認(rèn)及數(shù)據(jù)庫反饋回路的另一可
選電子消息傳送過程的流程圖。在圖6B中所示的過程400B包括通過確 認(rèn)SMTP握手的確認(rèn)步驟以及通過單獨(dú)的傳送SMTP通信發(fā)生的傳送步 驟。像圖6A中所示的過程400A，過程400B從數(shù)據(jù)庫402被啟動，并且 來自數(shù)據(jù)庫402的數(shù)據(jù)包通過基于域的流程控制404和傳送嘗試406的 選擇步驟被導(dǎo)引。然后，在步驟408'，出于可傳送性確認(rèn)目的的SMTP 連接被啟動。如在過程400A中，步驟408'之后為判斷410，以確認(rèn)接 收者服務(wù)器是否存在。如先前，如果判斷410的結(jié)果是NO，則接收者服 務(wù)器不存在，則在步驟412， SMTP連接被終止，并且在步驟414傳送失 敗被記錄到數(shù)據(jù)庫402。然而，不像在過程400A中，如果判斷410的結(jié) 果是YES，接收者服務(wù)器的確存在，則在新步驟430，過程400B進(jìn)行到 啟動第二傳送SMTP連接。消息傳送步驟420通過這個(gè)傳送SMTP連接 被執(zhí)行，而不是通過與在步驟408'中所建立的確認(rèn)SMTP相同的SMTP 連接。在啟動服務(wù)器連接之前需要確定可傳送性的實(shí)例中，為確認(rèn)和傳 送步驟建立單獨(dú)SMTP連接的這個(gè)過程是有利的。
現(xiàn)在結(jié)合圖6A參考圖7A，圖7A是示例根據(jù)本發(fā)明的包括基于域 的流程控制、可傳送性確認(rèn)(包括對接收者服務(wù)器可用性和接收者信息有 效性的確認(rèn))及數(shù)據(jù)庫反饋回路的電子消息傳送過程步驟的流程圖。如同 在圖6A中的過程400A，圖7A中所示的過程500A包括通過單個(gè)SMTP 通信發(fā)生的確認(rèn)和傳送步驟。除了被包括在過程400A中的全部步驟以 夕卜，過程500A還包括跟著判斷402的判斷502，以確定預(yù)期的接收者(即 用戶)是否存在于接收者服務(wù)器上。換句話說，判斷502確定由數(shù)據(jù)庫402 所提供的接收者信息是否有效。如果判斷502的結(jié)果是NO，則用戶并不 存在于接收者服務(wù)器上，則過程500A轉(zhuǎn)到終止SMTP通信且向數(shù)據(jù)庫 402寫入傳送失敗(如圖中所示的步驟412和414)的步驟。通過這種方法， 除了在圖6A的過程400A中所提供的接收者服務(wù)器確認(rèn)步驟以外，過程 500A還提供附加的接收者信息有效性的可傳送性確認(rèn)步驟。
類似地，圖7B示例如圖6B中所示的過程400B的變型。圖7B是示 例同樣根據(jù)本發(fā)明的包括基于域的流程控制、可傳送性確認(rèn)(包括對接收 者服務(wù)器可用性和接收者信息有效性的確認(rèn))及數(shù)據(jù)庫反饋回路的另一可 供選擇的電子消息傳送過程步驟的流程圖。在圖7B中所示的過程500B 包括通過確認(rèn)SMTP握手的確認(rèn)步驟以及通過單獨(dú)的傳送SMTP通信發(fā) 生的傳送步驟。與圖6B的過程400B相比較，過程500B提供了用于檢 查接收者信息的單獨(dú)步驟510。步驟510包括啟動確認(rèn)SMTP通信的步驟 408'、跟著的接收者服務(wù)器是否存在的判斷410及預(yù)期接收者是否存在 于接收者服務(wù)器上的判斷502。然后，如果判斷410和502的答案均是 YES，則在步驟430啟動傳送SMTP,以與確認(rèn)SMTP通信分開來執(zhí)行消 息的實(shí)際傳送。
圖8A是示例根據(jù)本發(fā)明的包括基于域的流程控制、可傳送性確認(rèn) (包括對接收者服務(wù)器可用性和接收者信息有效性的確認(rèn))、后期消息建立 及數(shù)據(jù)庫反饋回路的另一電子消息傳送過程步驟的流程圖。在圖8A中所 示的過程600A包括通過單個(gè)SMTP通信發(fā)生的確認(rèn)及傳送步驟。過程 600A實(shí)質(zhì)上是圖7A中的過程500A的變型，只是進(jìn)一步包括后期消息 建立步驟602。 g卩，可傳送性確認(rèn)步驟410和502僅基于從數(shù)據(jù)庫402所 提供的數(shù)據(jù)包而不是從預(yù)先建立的e-mail消息中所抽取的接收者信息而 被執(zhí)行。然后，僅對于在判斷410和502中那些可傳送性已經(jīng)得到確認(rèn) 的接收者，后期消息建立步驟602提供實(shí)際e-mail建立的消息，由此降 低了對存儲預(yù)先建立的e-mail消息的存儲器要求。
圖8B是是示例同樣根據(jù)本發(fā)明的包括基于域的流程控制、可傳送性 確認(rèn)(包括對接收者服務(wù)器可用性和接收者信息有效性的確認(rèn))、后期消息 建立及數(shù)據(jù)庫反饋回路的另一電子消息傳送過程步驟的流程圖。在圖8B 中所示的過程600B包括通過確認(rèn)SMTP握手的確認(rèn)步驟以及通過單獨(dú)的 傳送SMTP通信發(fā)生的傳送步驟。如同圖8A向圖7A的過程500A添加 了后期消息建立步驟，圖8B實(shí)質(zhì)上向圖7B的過程500B添加了后期消
息建立602。
圖9A和9B是比較電子消息傳送的現(xiàn)有技術(shù)存儲和前轉(zhuǎn)方法相對于 本發(fā)明的構(gòu)建和前轉(zhuǎn)模型的流程圖。圖9A示例如先前所說明的現(xiàn)有技術(shù) 的存儲和前轉(zhuǎn)模型，其中消息傳送引擎接受完整的電子消息、將消息寫 入盤、定位域名(如包括在電子消息中的頭部部分)、然后將消息通過互 聯(lián)網(wǎng)被導(dǎo)引向預(yù)期的接收者。具體而言，如圖9A中所示的過程700A示 例存儲和前轉(zhuǎn)模型，其開始于步驟702的接受輸入電子消息。在步驟704， 這樣被接受的電子消息作為文件被存儲在盤上。然后，在步驟706，如在 電子消息所規(guī)定的接收者服務(wù)器的域通過例如DNS查詢表被"查詢"， 然后在步驟708電子消息被傳輸向互聯(lián)網(wǎng)。如較早所討論，過程700A是 不利的，因?yàn)?.....[填空]。
相對照，圖9示例本發(fā)明的構(gòu)建和前轉(zhuǎn)模型，其中消息傳送引擎接 受電子消息(作為完整的信息或作為離散的數(shù)據(jù)包)、確認(rèn)消息的可傳送 性、然后取決于可傳送性確認(rèn)的結(jié)果，構(gòu)建用于通過互聯(lián)網(wǎng)傳送到預(yù)期 接收者的消息。如圖9B中所示的過程700B也以接受輸入的電子消息的 步驟702開始。然而，輸入的電子消息并不作為文件被存儲在盤中，而 是作為包含有關(guān)消息的信息位被存儲。過程700B進(jìn)一步如先前所說明， 包括基于這些數(shù)據(jù)包，用于確認(rèn)可傳送性的步驟720。此外，在過程700B 中，實(shí)際的e-mail消息并不被構(gòu)建，直到消息的可傳送性己經(jīng)被確認(rèn)之 后的步驟722。然后，過程700B繼續(xù)進(jìn)行以通過互聯(lián)網(wǎng)30傳送所得到 的消息。
圖IOA和IOB是將現(xiàn)有技術(shù)與本發(fā)明方法相比較的流程圖，其中附 加的過程，如消息過濾被添加到消息服務(wù)器功能性。如圖10A中所示， 現(xiàn)有技術(shù)傳送引擎在消息服務(wù)器802從用戶(未示出)接收完整的SMTP消 息，然后通過SMTP通信將消息導(dǎo)引到例如抗病毒應(yīng)用804，然后由另--SMTP通信導(dǎo)引到垃圾郵件過濾器806，然后由另外一個(gè)SMTP通信導(dǎo)引 到內(nèi)容過濾器808，然后通過再另一個(gè)SMTP通信導(dǎo)引到郵件服務(wù)器810
以便于發(fā)送，通過另一個(gè)SMTP通信導(dǎo)引向預(yù)期的接收者。多個(gè)SMTP 握手過程是麻煩的且耗費(fèi)時(shí)間和帶寬。相對照，圖10B的傳送引擎850 在消息服務(wù)器852處通過例如SMTP或通過應(yīng)用程序接口(API)從數(shù)據(jù)源 接受電子消息作為數(shù)據(jù)包，然后將所述電子消息借助API通過各種過程 導(dǎo)引，如抗病毒應(yīng)用854、垃圾郵件過濾器856、內(nèi)容過濾器858以及入 站路由器860，以便于在附加過程之間的SMTP通信是沒有必要的。然后 消息通過例如SMTP通信從發(fā)送者郵件服務(wù)器862導(dǎo)引向預(yù)期的接收者。 本發(fā)明在電子消息傳送中的途徑緊接著在以下被附加地加以討論。
通用途徑
使用SMTP消息傳送的這種重新代管的(refactored)架構(gòu)來發(fā)送消息 的通用途徑包括給服務(wù)器饋送用于傳送的消息、啟動SMTP與接收服 務(wù)器的通信、構(gòu)建用于傳送的消息、以及最終將消息內(nèi)容傳輸?shù)浇邮辗?務(wù)器。我們將緊接著在以下依次地對每個(gè)加以討論。
服務(wù)器首先被饋送發(fā)送者和接收者信息。這個(gè)過程可以包括對完整 的"被完好形成的"SMTP消息、或?qū)⒃谶^程中被組合以建立消息的數(shù)據(jù) 包集合的接受。在所優(yōu)選的實(shí)施中，輸入將是用于隨后的消息構(gòu)建的數(shù) 據(jù)包/點(diǎn)的集合。這個(gè)數(shù)據(jù)將包括消息頭部的信息，如接收者e-mail地址、 主題行、來自地址等。它還將包括用于消息體的信息。這可以包括來自 單獨(dú)數(shù)據(jù)源的被存儲的個(gè)人信息、文本、HTML碼、圖形、音頻或視頻 的、附件或許多其它類型電子數(shù)據(jù)中的任何數(shù)據(jù)。
一旦系統(tǒng)具有用于有效SMTP連接所要求的數(shù)據(jù)點(diǎn)，則它啟動與接 受服務(wù)器的連接。通過打開到接受服務(wù)器的通信插槽并且開始正常的 SMTP通信，系統(tǒng)可以確定消息的"可傳送性"。如果可傳送性被確認(rèn)為 肯定的，則系統(tǒng)基于所提供的數(shù)據(jù)點(diǎn)構(gòu)建針對相關(guān)協(xié)議(例如SMTP)被格 式化的完整消息用于傳送。如果傳送被拒絕，則系統(tǒng)將消息標(biāo)志為不可 傳送且關(guān)閉到接收服務(wù)器的連接。
消息傳送僅在成功的可傳送性測試以及消息構(gòu)建之后才發(fā)生。 一旦 這些事件已經(jīng)發(fā)生，則消息通過通信插槽傳遞到接收者服務(wù)器并且系統(tǒng) 關(guān)閉連接。
上述每個(gè)步驟的詳細(xì)說明
如果當(dāng)它應(yīng)用到電子消息時(shí)人們想詳細(xì)地跟隨這個(gè)過程，則它將隨 著緊接著在以下概述的過程而進(jìn)展。
a) 包含建立所需消息所必要的所有信息的數(shù)據(jù)包集合被系統(tǒng)接受。
b) 發(fā)送服務(wù)器檢查數(shù)據(jù)包以得到接收服務(wù)器的域名。
c) 利用互聯(lián)網(wǎng)域名服務(wù)(DNS)接口，發(fā)送服務(wù)器使用這個(gè)域名來査 詢郵件交換(MX)記錄。這個(gè)過程返回用于這個(gè)消息的接收服務(wù)器實(shí)際的 IP地址。
d) 發(fā)送服務(wù)器建立到接收服務(wù)器IP地址的TCP/IP插槽連接。
e) —旦連接時(shí)，接收服務(wù)器發(fā)送本身的通告。
f) 發(fā)送服務(wù)器發(fā)出其名稱作為自變量的"HELO"命令。
g) 然后接收服務(wù)器驗(yàn)證發(fā)送服務(wù)器是有效的且能夠發(fā)送e-mail進(jìn) 入其系統(tǒng)。如果被接受，則接收服務(wù)器將以"250歡迎"命令作出響應(yīng)。 如果連接被拒絕，則接收服務(wù)器將以"500連接拒絕"命令作出響應(yīng)。
h) 此時(shí)發(fā)送服務(wù)器將通告誰正在以"郵件來自 senderprefix@senderdomain.com"命令發(fā)送e-mail。
i) 再一次，接收服務(wù)器驗(yàn)證發(fā)送者的地址被允許將e-mail傳送進(jìn)接 收服務(wù)器。如果e-mail是可接受的，則接收服務(wù)器以"250 Okay"命令 作出響應(yīng)。如果消息是不可接受的，則接收服務(wù)器以"500未允許"命 令作出響應(yīng)。
j)此時(shí)發(fā)送服務(wù)器發(fā)出"接收到recipientprefix⑨recipientdomain"
命令，來告訴接收服務(wù)器誰要接收消息。
k)接收服務(wù)器驗(yàn)證接收者地址、檢査它是域內(nèi)的有效地址且可用于 接收消息。如果接收者地址是有效的且可用，則接收服務(wù)器將以"250
Okay"命令作出響應(yīng)。如果接收者地址是無效的，則接收服務(wù)器將以"500 用戶未知"或其它用戶可用性失敗命令作出響應(yīng)。
1)正是過程中的這點(diǎn)，本發(fā)明與現(xiàn)有技術(shù)不同。 一旦在SMTP對話 中的驗(yàn)證事務(wù)處理己經(jīng)發(fā)生，則在可傳送性的肯定驗(yàn)證情況下，發(fā)送服 務(wù)器將構(gòu)建消息并且繼續(xù)發(fā)送過程，或在可傳送性失敗錯(cuò)誤的情況下， 將失敗寫進(jìn)記錄日志、中止過程且關(guān)閉連接。
m)在這個(gè)新的過程中， 一旦消息被構(gòu)建，則發(fā)送服務(wù)器發(fā)送"數(shù) 據(jù)"命令。
n)如果接收服務(wù)器準(zhǔn)備好接受消息，則它將以格式"250 Okay"發(fā) 送命令。
o) —旦發(fā)送服務(wù)器具有上述提到的okay，則它將整個(gè)消息內(nèi)容發(fā) 送到接收服務(wù)器，以字符序列"〈cr〉 〈lf〉 〈cr〉 〈lf〉"而結(jié)束。這個(gè)串將 通知接收服務(wù)器消息是完整的。
P)如果接收服務(wù)器接受所述消息，它將發(fā)送另一 "250 Okay"命令。 q) —旦最終的okay被接收，則發(fā)送服務(wù)器發(fā)出"退出"命令，并 且在一收到時(shí)，接收服務(wù)器將斷開插槽連接并且兩側(cè)都將關(guān)閉通信。
任選的附加特征 構(gòu)建和前轉(zhuǎn)(基于數(shù)據(jù)包)
構(gòu)建和前轉(zhuǎn)消息由三個(gè)主要步驟組成。第一且最重要的是在SMTP 通信被建立以發(fā)送消息組的同時(shí)，接受包含接收者、傳送和消息內(nèi)容信 息的數(shù)據(jù)包，并且將它們存儲在隨機(jī)存取存儲器(RAM)，而不是將它們 寫入到硬驅(qū)動器的能力。第二關(guān)鍵特征是在處理大量包含傳送和其它 個(gè)性化信息的唯一接收者數(shù)據(jù)包的同時(shí)，保持主要e-mail內(nèi)容(體和某些 頭部)的單拷貝。在"構(gòu)建和前轉(zhuǎn)"過程中的第三步驟是在SMTP連接被 建立且可傳送性已經(jīng)被確定之后以及傳輸?shù)浇邮辗?wù)器之前(或期間)，將
e-mail內(nèi)容與每個(gè)接收者的唯一傳送和其它個(gè)性化信息合并。
在存儲器中被處置的消息(被寫入RAM，而不是盤)
這個(gè)系統(tǒng)的關(guān)鍵特征是在電子存儲器中處置消息。這是利用可尋址 的RAM源，而不是文件I/0實(shí)現(xiàn)。通過使用這個(gè)資源，而不是典型的系 統(tǒng)硬驅(qū)動器，與文件I/O相聯(lián)系的瓶頸以及現(xiàn)有技術(shù)所共有的單點(diǎn)失敗可 得到減少。
動態(tài)IP地址分配
動態(tài)IP地址分配用于在寬得多的地址空間上分散傳送負(fù)荷。這允許 較快速的傳送并且降低正在大量傳送的消息將被視為未被請求的商業(yè)郵 件的可能性。
串行途徑(為每個(gè)接收者握手/發(fā)送)與并行途徑(一個(gè)確認(rèn)連接， 一不同的 傳送連接)的對比
這個(gè)可傳送性確認(rèn)步驟可以采取串行形式，即在另一個(gè)利用同一插 槽連接之后的一個(gè)步驟，或與實(shí)際的傳送并行。兩個(gè)途徑均具有優(yōu)點(diǎn)， 并且導(dǎo)致相同的結(jié)論。
發(fā)送者可是人或應(yīng)用/機(jī)器
由于這個(gè)系統(tǒng)的首要接受方法是數(shù)據(jù)，而不是被完好形成的SMTP消息， 所以始發(fā)者可是人或計(jì)算機(jī)系統(tǒng)。這個(gè)數(shù)據(jù)驅(qū)動的實(shí)施的使用并不排除 SMTP消息的使用，而是擴(kuò)展了兼容性。
數(shù)據(jù)驅(qū)動的支持
通過將消息傳輸分解成不同的數(shù)據(jù)包，系統(tǒng)可以與現(xiàn)存的及未來的 應(yīng)用程序?qū)?，并且擴(kuò)展在消息傳送過程期間消息增強(qiáng)的可能性，與在
傳送之前相反。
a) 與各種軟件、特征的API連接通過建立API"鏈"，每個(gè)消息 可以被交到修改器(modifier)應(yīng)用。這種應(yīng)用可起到病毒防護(hù)、SPAM 過濾、內(nèi)容管理等功能。
b) 被觸發(fā)的e-mail:在所建議的系統(tǒng)中，當(dāng)消息由數(shù)據(jù)包組成時(shí)， 這個(gè)系統(tǒng)適合于修改并且傳送由數(shù)據(jù)庫觸發(fā)驅(qū)動的e-mail。當(dāng)規(guī)定的標(biāo) 準(zhǔn)在數(shù)據(jù)庫中被滿足時(shí)，發(fā)生數(shù)據(jù)庫觸發(fā)。數(shù)據(jù)庫可"觸發(fā)"事件，如 傳送e-mail。通過使數(shù)據(jù)包經(jīng)受消息過程是在傳送過程后期構(gòu)建消息， 被觸發(fā)的消息收發(fā)變成實(shí)用的。
c) 監(jiān)視出站消息及事件除了數(shù)據(jù)驅(qū)動的消息收發(fā)可以提供這一被 添加的功能性以外，這個(gè)數(shù)據(jù)途徑還允許系統(tǒng)的管理者監(jiān)視且控制系統(tǒng) 內(nèi)所有的消息收發(fā)活動。從對消息數(shù)目的簡單計(jì)數(shù)，到先進(jìn)的API鏈管 理。
基于域的流程控制
基于域的流程控制通過如下而實(shí)現(xiàn)察看被排定用于傳送的e-mail 域的整個(gè)組，以及對分布進(jìn)行"規(guī)格化"，以便于沒有單個(gè)域可以阻礙其 它域的傳送。正如在本領(lǐng)域中所眾所周知，任何e-mail地址清單由大多 數(shù)大的ISP的地址組成，然后由剩余的較小服務(wù)提供商而填充。在典型 的清單發(fā)送方案中，e-mail以基于域名的組被傳送。如果一個(gè)或更多個(gè)大 IPS難以接受郵件或減慢速度，則清單的剩余部分將等待先前的郵件被發(fā) 送。像典的FIFO行為)這種行為明顯地限制了系統(tǒng)快速傳送大量郵件的 能力。通過將每個(gè)域分割成相等大小的部分并且基于這些組而不是嚴(yán)格 的域排序來傳送，實(shí)現(xiàn)了基于域的流程控制。
入站消息接收
與系統(tǒng)的數(shù)據(jù)驅(qū)動的性質(zhì)一樣，還將允許利用標(biāo)準(zhǔn)SMTP協(xié)議使消息進(jìn)入系統(tǒng)。這允許如進(jìn)一步所說明的擴(kuò)展功能性。
根據(jù)握手/傳送結(jié)果，進(jìn)入數(shù)據(jù)庫的數(shù)據(jù)反饋
這個(gè)系統(tǒng)的強(qiáng)大特征是記錄郵件傳送中的彈回和失敗而無需實(shí)際上
發(fā)送e-mail的能力。這是通過在消息建立和傳送之前記錄來自接收服務(wù) 器的響應(yīng)而實(shí)現(xiàn)。
數(shù)據(jù)驅(qū)動的支持
系統(tǒng)的另一方面是將一個(gè)或多個(gè)數(shù)據(jù)源處置成每個(gè)消息的輸入的能 力。這個(gè)能力將標(biāo)準(zhǔn)郵件服務(wù)器從先前技術(shù)概念"郵件延遲"中解放出 來，而在郵件傳送系統(tǒng)中建立消息工廠。
宏替換字段、增強(qiáng)的e-mail、個(gè)性化、內(nèi)容的修改
上述提到的進(jìn)步使能每個(gè)消息包含經(jīng)由定制業(yè)務(wù)邏輯，或標(biāo)準(zhǔn)的宏 替換從根本不同的數(shù)據(jù)源中拉出且被構(gòu)建進(jìn)消息的個(gè)性化數(shù)據(jù)。這提供 了在消息建立過程中的無限靈活性并且與先前技術(shù)形成鮮明的對照。
架構(gòu)的靈活性
所建議的系統(tǒng)的關(guān)鍵特征是擴(kuò)展和擴(kuò)張郵件系統(tǒng)架構(gòu)的能力。通過 允許對在系統(tǒng)內(nèi)傳播的消息的"線上(in-line)" API,消息可以被增強(qiáng)、 修改或操縱而無需先前技術(shù)中常見的串行方案。這個(gè)過程作用如下
i. 消息被接受到系統(tǒng)內(nèi)
ii. 與初始消息相關(guān)的處理發(fā)生
iii. 系統(tǒng)被交到"隊(duì)列管理器"，其將允許API鏈有序的處理
iv. 然后消息被交到在系統(tǒng)內(nèi)登記的每個(gè)API過程
v. —旦消息已經(jīng)越過API鏈，則它繼續(xù)其傳送路徑
vi. 然后消息被傳送到最終的接收者。
其它的消息傳送協(xié)議
除了就此點(diǎn)所討論的e-mail消息協(xié)議以外，還應(yīng)該注意到這個(gè)系統(tǒng) 可以被用來使能其它目前的或未來的互聯(lián)網(wǎng)協(xié)議的所有提到的特征。這 包括SMS(簡單消息服務(wù))、以及目前可用的或可在未來開發(fā)的各種其它 協(xié)議。
適配于作為入站/出站MTA而使用
除了擴(kuò)展的協(xié)議以外，這個(gè)系統(tǒng)還可以被轉(zhuǎn)向面對網(wǎng)絡(luò)內(nèi)部，以允 許利用本領(lǐng)域中的同樣進(jìn)步對入站消息加以處置。作為入站處理或消息 中繼的特征，本系統(tǒng)可以被配置成在可傳送性可以被整個(gè)地確定或消息 被清晰地指示成在隨后時(shí)間重新發(fā)送使對消息嘗試重試。這個(gè)系統(tǒng)還可 以被擴(kuò)展成充當(dāng)真實(shí)的消息中繼，以增加先前技術(shù)的性能和能力。
附加的修改
API事件的管理和分布
現(xiàn)有技術(shù)API過程的一個(gè)實(shí)例是上述提到的MIL TER過程。參考圖 IIA，在現(xiàn)有技術(shù)郵件服務(wù)器內(nèi)的現(xiàn)有技術(shù)MIL TER API事件管理及分 布過程900被說明。在下面的說明中，應(yīng)用被定義為被寫入以與API對 接的任何計(jì)算機(jī)碼段，且收聽者被定義為嵌進(jìn)系統(tǒng)中的API接口。在步 驟906當(dāng)API事件在郵件服務(wù)器內(nèi)被執(zhí)行時(shí)，在郵件服務(wù)器902內(nèi)過程 900被觸發(fā)。跟著在步驟906中API事件的執(zhí)行，然后在步驟908郵件服 務(wù)器對收聽者掃描那個(gè)API事件。判斷910跟著步驟908，以確定是否己 經(jīng)發(fā)現(xiàn)API收聽者。如果判斷910的答案是YES，則那個(gè)事件的一個(gè)或 更多個(gè)API收聽者被發(fā)現(xiàn)，那么在步驟912消息被傳遞到第一隨機(jī)選擇 的收聽者。在步驟914，通過改變它、刪除它或讓它未經(jīng)修改便通過，第 一收聽者可作用于消息對象。在步驟916，這個(gè)第一收聽者向郵件服務(wù)器
發(fā)送響應(yīng)。這個(gè)響應(yīng)可包括例如回到始發(fā)發(fā)送者服務(wù)器的郵件服務(wù)器的 結(jié)果碼。如果附加的API收聽者己經(jīng)被發(fā)現(xiàn)，則在步驟918消息對象被
傳遞到第二收聽者，并且對于第二收聽者重復(fù)步驟912至916。過程被重 復(fù)直至所有的API收聽者已經(jīng)作用于消息。然后在步驟920，根據(jù)規(guī)定的 消息協(xié)議，郵件服務(wù)器向始發(fā)的發(fā)送者發(fā)送響應(yīng)，并且在步驟922過程 繼續(xù)進(jìn)行到下一個(gè)消息事件。
雖然上述說明的MIL TER架構(gòu)使能對接MTA與外部應(yīng)用程序，用 于各種類型的處理，但是MTA性能、架構(gòu)及特征的局限性已經(jīng)限制了 MIL TER架構(gòu)適用性的性質(zhì)。具體地，MIL TER接口被常用于將單個(gè) e-mail處理應(yīng)用(例如病毒過濾器)與MTA接口，這是出于平衡作為應(yīng)用 的郵件中繼機(jī)構(gòu)的MTA的目的。當(dāng)網(wǎng)絡(luò)或系統(tǒng)要求多個(gè)一個(gè)這樣的應(yīng)用 (例如病毒過濾器和垃圾郵件過濾器)時(shí)，多個(gè)MTA被順序地布置，從而 如圖10A中所示互相饋送消息。
這個(gè)存在問題的、順序的處理方案的盛行主要是由于現(xiàn)有技術(shù)中 MTA的局限性，這包括緩慢的處理速度、無效率的硬件資源的使用、無 效率的數(shù)據(jù)業(yè)務(wù)量管理、在多個(gè)可用過程情況下對于等待處理的消息， 缺乏高效的排隊(duì)方法、以及當(dāng)消息傳播通過多個(gè)過程時(shí)缺乏消息排序的 手段。當(dāng)多個(gè)API過程被實(shí)施在單個(gè)MTA情況下，這些局限性組合構(gòu)成 下述不可接受的風(fēng)險(xiǎn)，即過分使用可用的系統(tǒng)資源、業(yè)務(wù)量瓶頸及潛在 的系統(tǒng)失敗。因此，在目前現(xiàn)有技術(shù)中，這種過程幾乎總是通過如下串 行地應(yīng)用，即借助于通過由接收MTA所支持的單獨(dú)的應(yīng)用發(fā)送每個(gè)消 息，以接受消息，以及單獨(dú)的發(fā)送MTA，以將它們前轉(zhuǎn)到下一個(gè)處理應(yīng) 用，或主MTA，以便于通過互聯(lián)網(wǎng)傳送(如所舉例，例如通過圖10A中 的傳送引擎800)。因而，整個(gè)系統(tǒng)的傳送效率受到通過多個(gè)MTA和處理 應(yīng)用的串行處理層的傳送效率的限制。這個(gè)順序的架構(gòu)也是從硬件及支 持上是密集型的。
作為對結(jié)合圖IOB所說明的本發(fā)明API饋送過程的替換，其可被如
此修改，以便于多個(gè)應(yīng)用可為任何消息事件而登記，同時(shí)規(guī)定執(zhí)行次序。 與此同時(shí)，本發(fā)明的API過程可平衡性能改善方法，其包括但不局限于 用于數(shù)據(jù)傳輸?shù)牟宀弁ǖ篮瓦x擇器方法、用于優(yōu)化過程之間的消息流的 事件排隊(duì)機(jī)制、以及用于改善在大小上大的消息的處理效率的消息壓縮。 本發(fā)明的API過程的細(xì)節(jié)緊接著在以下被詳細(xì)說明。
眾所周知地是使用SMTP協(xié)議的電子消息的傳送過程包括多個(gè)消
息事件，如例如連接、HELO、 MAILFROM、 RCPTTO、 DATA及QUIT。 在本發(fā)明的API過程中，API應(yīng)用可在傳送過程的任何時(shí)間為這些消息 事件而登記。換句話說，在實(shí)例Post—Connect、 Post—HELO、 Post—MAIL、 Post—RCPT、 Post—DATA 、 Post—QUIT 、 Msg—Injector 、 Pre Connect 、 Pre—HELO、 Pre—MAIL、 Pre—RCPT、 Pre_DATA和Pre—QUIT可進(jìn)行登記。 事件后及事件前登記的實(shí)例被示例在圖IIB和11C中。首先參考圖 11B，示出包括根據(jù)本發(fā)明的post-HELO事件登記932的事件后API過 程930。事件后API過程930包括發(fā)送服務(wù)器934與接收服務(wù)器936之間 的通信。 一系列SMTP事件(由括號938所指示)發(fā)生在發(fā)送服務(wù)器934 與接收服務(wù)器936之間，包括從發(fā)送服務(wù)器到接收服務(wù)器的HELO請求。 Post—HELO事件登記932規(guī)定針對post—HELO事件所登記的API應(yīng)用， 服務(wù)器在接受來自發(fā)送服務(wù)器的HELO命令之后，將接收消息對象。相 對照，圖11C示例包括pre—HELO事件登記942的事件前API過程940 的實(shí)例。在事件前API過程940中，在發(fā)送服務(wù)器934向接收服務(wù)器936 發(fā)出HELO命令之前，針對pre—HELO所登記的API應(yīng)用將接收消息對 象。
在消息事件(例如，pre—HELO)之前可被觸發(fā)的事件的添加允許過濾 器應(yīng)用被施加到在從服務(wù)器出站的途中的消息上，這被視為優(yōu)于現(xiàn)有技 術(shù)MILTER過程的顯著進(jìn)步。在本發(fā)明的API過程中，通過當(dāng)?shù)鼗蜻h(yuǎn)程 的TCP插槽連接，應(yīng)用可向郵件服務(wù)器進(jìn)行登記。這個(gè)應(yīng)用登記規(guī)定發(fā) 送者想要捕捉的事件以及那個(gè)特定的發(fā)送者在收聽者隊(duì)列中應(yīng)該被放置的次序。本發(fā)明的這個(gè)API事件登記概念被示例于圖IID，其示出根據(jù) 本發(fā)明的API示意圖950的方框圖。API示意圖950包括中央的郵件服 務(wù)器952，其為上面所列的多個(gè)郵件事件中的至少一些處置多個(gè)登記(由 具有參考號954A-954G的框表示)?！熠?，郵件服務(wù)器952可處置來自多個(gè) API應(yīng)用的登記，并且多個(gè)應(yīng)用可為同一事件而登記。任選地，郵件服務(wù) 器952可包括API事件排序能力(由框956表示)，以便于郵件服務(wù)器952 可以處置來自多個(gè)應(yīng)用的登記，而同時(shí)允許每個(gè)應(yīng)用來規(guī)定在收聽者隊(duì) 列中特定API應(yīng)用應(yīng)該被放置的次序。收聽者和API應(yīng)用兩者可配備有 高性能的消息對象隊(duì)列以暫時(shí)地保持等待處理的消息。隊(duì)列機(jī)制將允許 API應(yīng)用和收聽者的較快速饋送，而無需阻礙服務(wù)器的主要活動。API 事件排序能力956的包括允許例如某些API應(yīng)用比其它API應(yīng)用具有優(yōu) 先權(quán)。
現(xiàn)在結(jié)合圖IIA和IID參考圖11E，郵件服務(wù)器952處置多個(gè)登記 所借助的過程被說明。本發(fā)明圖11E中的API事件管理和分布過程960 共享圖11A中所示的MIL TER API過程卯0的一些步驟，但是除了 MIL TER過程卯0以外還包括若干步驟。在步驟906，當(dāng)API事件在郵件服 務(wù)器內(nèi)被執(zhí)行時(shí)，過程960在郵件服務(wù)器952內(nèi)被觸發(fā)。跟著在步驟906 的API事件的執(zhí)行，然后在步驟962郵件服務(wù)器向API事件隊(duì)列中添加 消息。然后在步驟906郵件服務(wù)器針對那個(gè)API事件掃描事件收聽者。 判斷910跟著步驟908以確定API收聽者是否已經(jīng)被發(fā)現(xiàn)。如果判斷910 的答案是YES，則那個(gè)事件的一個(gè)或更多個(gè)收聽者已經(jīng)被發(fā)現(xiàn)，則在判 斷964消息的大小被確定。如果判斷964確定消息大于預(yù)定閾，則在前 進(jìn)到步驟912之前的步驟966，消息被壓縮。如果判斷964確定消息足夠 小，則消息立即被導(dǎo)引到步驟912以將消息傳遞到第一收聽者事件隊(duì)列。 例如通過使用插槽通道和選擇器方法，這個(gè)傳輸可被執(zhí)行。在步驟968 第一收聽者事件隊(duì)列接受消息，其后在步驟914通過改變它、刪除它或 讓它未經(jīng)修改便被傳遞，收聽者可作用于消息。在步驟916，收聽者將消
息返回到事件隊(duì)列并且向郵件服務(wù)器發(fā)送響應(yīng)。這個(gè)響應(yīng)可包括，例如
郵件服務(wù)器的結(jié)果碼，用以傳遞回到啟動發(fā)送者服務(wù)器。然后在步驟970, 將所述消息從事件隊(duì)列中去除。如果已經(jīng)發(fā)現(xiàn)附加的API收聽者，則在 步驟918消息被傳遞到第二收聽者，并且對于第二收聽者，步驟912、968、 916和970被重復(fù)。這些步驟被重復(fù)，直至所有的API收聽者已經(jīng)作用于 消息。然后在步驟972根據(jù)規(guī)定的消息協(xié)議(例如SMPT)，郵件服務(wù)器向 啟動的發(fā)送者服務(wù)器發(fā)送響應(yīng)。然后在步驟974消息從API事件隊(duì)列中 被去除并且在步驟922過程繼續(xù)進(jìn)行到下一個(gè)消息事件。作為變型，圖 11E中的過程960可與上面所說明的可傳送性確認(rèn)過程相結(jié)合被執(zhí)行。
可配置的RAM或硬驅(qū)動器消息處理
作為對上述所說明實(shí)施例的可能性修改的實(shí)例，本發(fā)明的電子消息 傳送系統(tǒng)可被配置成提供在如上所說明在RAM處理中將消息作為數(shù)據(jù) 包，以及如在現(xiàn)有技術(shù)中所使用的作為被存儲在硬盤驅(qū)動器(HDD)上的文 件來處置之間進(jìn)行選擇。S卩，當(dāng)想要傳送到接收者服務(wù)器處的接收者的 消息從發(fā)送者被接收時(shí)，發(fā)送郵件服務(wù)器可被配置成將部分或全部這個(gè) 消息寫入到HDD用于存儲。在RAM處理期間在停電情況下，通過提供 例如備份存儲系統(tǒng)，向HDD存儲部分或全部消息的這個(gè)選項(xiàng)補(bǔ)充了如上 所述的本發(fā)明的基于RAM的處理。這樣的經(jīng)修改的系統(tǒng)被示例于圖12A 中，其示出通過使用可配置的RAM/HDD消息處理方案，當(dāng)消息處置過 程發(fā)生在郵件服務(wù)器內(nèi)時(shí)的其流程圖?？傮w上由參考符號1070表示的消 息處置過程開始于在步驟1072中系統(tǒng)接受來自發(fā)送者服務(wù)器的消息。部 分還是全部給定消息應(yīng)該被保存到HDD的配置被存儲在配置存儲1074 中。在步驟1076在配置存儲1074中所規(guī)定的配置被檢查。判斷1078被 進(jìn)行，以確定給定消息是否要部分地或全部地被保存到HDD。如果判斷 1078的答案是YES，部分或全部消息應(yīng)該被保存到HDD,則在步驟1080 至少一部分消息被寫入HDD上的臨時(shí)存儲。然后在步驟1082郵件服務(wù)
器從HDD讀取這個(gè)被存儲的消息，然后前進(jìn)到如上所述的步驟1084處 的傳送序列，包括例如在上述所說明的圖9B中所示的傳送確認(rèn)及后期消 息建立。如果判斷1078的答案是NO，消息不應(yīng)該被保存到HDD，然后 郵件服務(wù)器直接前進(jìn)到步驟1084處的傳送序列。附加地，跟著傳送步驟 1084，郵件服務(wù)器做出判斷1086，以再次確定消息是否已經(jīng)被保存到 HDD。如果判斷1086的答案是YES，部分或全部消息已經(jīng)被保存到HDD， 則在步驟1088，被保存的消息可被任選地從HDD中除去。如果判斷1086 的答案是NO，消息還未曾被保存到HDD，則在步驟1090消息處理被簡 單地結(jié)束。這個(gè)可配置的RAM/HDD消息處理是有利的，因?yàn)樗试S管 理者配置傳送速度和在系統(tǒng)失敗事件下的消息恢復(fù)確定性之間的優(yōu)選平 衡。
作為另外一種選擇，可配置的RAM/HDD消息處理可被修改以基于 預(yù)定的系統(tǒng)閾來確定是否給定消息應(yīng)該被保存到HDD。在郵件服務(wù)器內(nèi) 這樣的基于閾的過程類似于圖12A中所示例的過程，但是，基于閾的過 程檢査郵件服務(wù)器相對于已知系統(tǒng)性能閾(例如存儲器使用)的目前狀態(tài)， 以確定特定的消息是否應(yīng)該被保存到HDD。基于閾的過程1095的細(xì)節(jié) 被示例于圖12B?；陂摰倪^程1095基本上類似于如圖12A中所示的消 息處置過程1070，但是附加地包括步驟1096以相對于目前的狀態(tài)比較系 統(tǒng)閾。在這個(gè)比較步驟1096，郵件服務(wù)器相對于已知的系統(tǒng)性能閾，如 存儲器使用、硬驅(qū)動器的使用及產(chǎn)出能力，對系統(tǒng)的目前狀態(tài)進(jìn)行比較。 然后進(jìn)行判斷1098，以確定這個(gè)預(yù)定的閾是否已經(jīng)得到滿足。如果判斷 1098是YES，特定的閾被超過，則在步驟1080消息被寫入HDD。如果 判斷1098是NO，特定的閾尚未得到滿足，則消息被導(dǎo)引到步驟1084處 的傳送序列。這樣的基于閾的系統(tǒng)是有利的，因?yàn)楣芾碚呖稍O(shè)置系統(tǒng)使 用閾或"危險(xiǎn)等級"，其規(guī)定當(dāng)系統(tǒng)資源接近緊迫的使用等級時(shí)，何時(shí)開 始存儲且前轉(zhuǎn)處理以確保在系統(tǒng)失敗情況下的消息恢復(fù)。
通道選擇器插槽管理
郵件服務(wù)器技術(shù)中的另一考慮是使用插槽連接用于服務(wù)器之間的
e-mail傳輸。作為簡要的背景，插槽是一種用于建立過程之間的物理的遠(yuǎn) 程或當(dāng)?shù)剡B接的機(jī)制。經(jīng)由其網(wǎng)絡(luò)通信設(shè)施，插槽與操作系統(tǒng)(例如UNIX)
的標(biāo)準(zhǔn)輸入/輸出(i/o)功能流服務(wù)對接。插槽功能建立通信終點(diǎn)并且返回
文件描述符，借此描述符訪問那個(gè)插槽。插槽具有與它聯(lián)系的插槽地址， 包括端口號和當(dāng)?shù)刂鳈C(jī)的網(wǎng)絡(luò)地址。
經(jīng)典的插槽通信模型是在圖13A中被示例的單插槽模型。在如圖 13A所示的單插槽模型1100中，發(fā)送服務(wù)器(起點(diǎn))1102與接收服務(wù)器(終 點(diǎn))之間的通信發(fā)生在專用的單插槽通道1106之間。
現(xiàn)在結(jié)合圖13A參考圖13B，典型的插槽建立和通信過程被說明。 圖13B示出用于傳輸e-mail的標(biāo)準(zhǔn)過程序列1110的流程圖，通過建立起 點(diǎn)1102與終點(diǎn)1104之間的插槽連接1106，所述序列使用服務(wù)器之間的 插槽通信。典型地，在服務(wù)器還不具有插槽連接的網(wǎng)絡(luò)上或在互聯(lián)網(wǎng)上
的位置處，在發(fā)送服務(wù)器開始發(fā)送消息到接收者服務(wù)器的任何時(shí)間，所 述序列被啟動。參考圖13B，現(xiàn)有技術(shù)插槽連接過程可被概括如下
a. 在步驟1112，在發(fā)送服務(wù)器(起點(diǎn))建立插槽。
b. 在步驟1114，從發(fā)送服務(wù)器到接收服務(wù)器(終點(diǎn))連接插槽。
c. 在步驟1116，接收者服務(wù)器選擇接受插槽連接。 一旦連接被建立 且被接受，則插槽通信通道可用于在起點(diǎn)和終點(diǎn)之間傳遞信息，包括標(biāo) 準(zhǔn)電子消息協(xié)議對話數(shù)據(jù)和消息內(nèi)容。
d. 在步驟1118，發(fā)送服務(wù)器發(fā)送數(shù)據(jù)到接收服務(wù)器并且從接收服務(wù)
器接收數(shù)據(jù)。
e. 在步驟1120接收服務(wù)器發(fā)送和接收數(shù)據(jù)。
f. 跟著步驟1120，進(jìn)行判斷1122以確定是否在發(fā)送和接收服務(wù)器 之間需要更多的數(shù)據(jù)被傳遞。如果判斷1122的答案是YES，在發(fā)送和 接收服務(wù)器之間更多的數(shù)據(jù)需要被交換，則過程經(jīng)由步驟1108和1110
而循環(huán)回來。如果判斷1122的答案是NO，數(shù)據(jù)流是完整的，則在步驟 1124發(fā)送服務(wù)器結(jié)束連接。
當(dāng)兩側(cè)(即起點(diǎn)和終點(diǎn))通過插槽被連接時(shí)，其保持工作。任一側(cè)可 中斷或關(guān)閉連接。所述連接可被用來將多個(gè)e-mail消息(來自等待隊(duì)列) 傳輸?shù)浇K點(diǎn)服務(wù)器。 一旦完成由任一個(gè)服務(wù)器所進(jìn)行的傳輸、中斷或關(guān) 閉，所述連接被切斷且插槽消失。在現(xiàn)有技術(shù)的服務(wù)器之間的e-mail傳 輸中，從插槽建立到信息傳遞到連接關(guān)閉和插槽消失的序列是標(biāo)準(zhǔn)的和 一致的?？傮w上，開式插槽將僅存在于已經(jīng)存在到終點(diǎn)位置的連續(xù)消息/ 數(shù)據(jù)流的情況(即，在完成當(dāng)前消息的傳輸之前，到所述位置的新消息被 呈現(xiàn)到插槽)。
在現(xiàn)有技術(shù)的經(jīng)典單插槽通信過程中存在各種固有的問題。在圖 13A和13B所示例的現(xiàn)有技術(shù)過程中，e-mail傳輸通過涉及多個(gè)數(shù)據(jù)事 務(wù)處理的對話協(xié)議而進(jìn)行。這個(gè)對話協(xié)議包括協(xié)議信號交換(即握手)以及 用于消息本身的多個(gè)數(shù)據(jù)事務(wù)處理兩者。在目前的現(xiàn)有技術(shù)中，帶有被 單獨(dú)約束的插槽的專用線程必須等待對應(yīng)的發(fā)送和接收服務(wù)器之間的特 定消息的全部數(shù)據(jù)事務(wù)處理的完成。每個(gè)并發(fā)的線程/插槽對被專門用于 與特定位置的對話，并且當(dāng)各個(gè)消息/對話被啟動和終止時(shí)，被建立和終 止。為了進(jìn)行到多個(gè)終點(diǎn)的多個(gè)同時(shí)的e-mail傳輸，發(fā)送服務(wù)器必須產(chǎn) 生對應(yīng)于多個(gè)終點(diǎn)的多個(gè)插槽。最高效的目前實(shí)踐使用多線程化應(yīng)用設(shè) 計(jì)，其中一個(gè)線程管理一個(gè)插槽。在這種情況下，允許的潛在的同時(shí)插 槽的數(shù)目由根據(jù)基礎(chǔ)操作系統(tǒng)環(huán)境所建立的約束，可以由發(fā)送服務(wù)器來 處置的可能的同時(shí)線程的數(shù)目來控制。然而，通過目前可用的郵件服務(wù) 器可產(chǎn)生的同時(shí)線程的數(shù)目受到容納郵件服務(wù)器的計(jì)算機(jī)的基礎(chǔ)操作系 統(tǒng)的限制。因此，到多個(gè)終點(diǎn)的同時(shí)e-mail傳輸?shù)乃俾?對于給定e-mail 服務(wù)器的一般e-mail傳輸速率)受到可由服務(wù)器的操作系統(tǒng)支持的同時(shí)線 程和插槽的數(shù)目的限制。因此，在這種類型的架構(gòu)中，資源停滯和爭奪 是常見的議題。
被示例于圖13C和13D的服務(wù)器之間的數(shù)據(jù)通信中的最新進(jìn)步包 括使用用于計(jì)算機(jī)服務(wù)器的選擇器(因此，單線程)來管理服務(wù)器之間的 多插槽通道上的數(shù)據(jù)流，以便于將消息從發(fā)送者服務(wù)器(起點(diǎn))傳輸?shù)狡渌?的接收者服務(wù)器(終點(diǎn))。選擇器基本上代替了先前所說明的多線程的插槽 管理功能。這個(gè)現(xiàn)有技術(shù)過程通過使用傳輸控制協(xié)議(TCP)來進(jìn)行，所述 協(xié)議是用于提供全雙工、過程到過程連接的互聯(lián)網(wǎng)傳輸層協(xié)議。
首先參考圖13C，現(xiàn)有技術(shù)的數(shù)據(jù)傳輸?shù)牟宀弁ǖ篮瓦x擇器方案被 加以說明?，F(xiàn)有技術(shù)通信過程涉及三個(gè)主要組件l)插槽通道(或簡單地， 通道)、選擇器、以及接收服務(wù)器(或終點(diǎn))。如圖13C中所示，多插槽通 道及選擇器方案1130包括多個(gè)插槽通道(由分別由參考號1132A-C所指 示的通道A-C表示)。每個(gè)插槽通道作為數(shù)據(jù)的連接路由而被建立。插槽 通道1132A-C的每一個(gè)經(jīng)歷向選擇器1136的登記1134。實(shí)質(zhì)上，選擇器 充當(dāng)往返于郵件服務(wù)器的全部通信的"看門人(gatekeeper)",用于看管 入站和出站通信上的標(biāo)簽，并且選擇器可負(fù)責(zé)許多同時(shí)通信通道。
現(xiàn)在結(jié)合圖13C參考圖13D，現(xiàn)有技術(shù)的TCP插槽通道和選擇器方 案被加以說明。在現(xiàn)有技術(shù)的TCP過程1140中，在步驟1142插槽通道 作為數(shù)據(jù)的連接路由被建立。響應(yīng)于多個(gè)通信請求，多個(gè)插槽通道被建 立。在步驟1144，在步驟1142所建立的每個(gè)插槽通道向選擇器1136進(jìn) 行登記，從而規(guī)定終點(diǎn)位置(例如IP地址)和它想要接收的事件類型(例如 插槽寫入、讀取等)。然后選擇器在步驟1146啟動所請求的與終點(diǎn)的連接， 然后在步驟1148輪詢通過對應(yīng)的通道所登記的活動。在判斷1150中， 選擇器確定數(shù)據(jù)是否正通過插槽連接之一而來。如果判斷1150的答案是 NO，不存在進(jìn)入或出去的數(shù)據(jù)，則在步驟1148選擇器輪詢數(shù)據(jù)通信活 動。如果判斷1150的答案是YES，數(shù)據(jù)正在通過插槽連接之一傳輸，則 選擇器繼續(xù)進(jìn)行到判斷1152以確定數(shù)據(jù)傳輸?shù)姆较?。如果判?152確 定數(shù)據(jù)傳輸方向是從發(fā)送者服務(wù)到接收者服務(wù)器的OUTBOUND,則在步 驟1154選擇器將數(shù)據(jù)導(dǎo)引到終點(diǎn)。如果判斷1152確定數(shù)據(jù)傳輸方向是
INBOUND，則在步驟1156選擇器作用于數(shù)據(jù)。由選擇器所采取的動作 由在這個(gè)情況下為TCP的協(xié)議來確定。在這個(gè)現(xiàn)有技術(shù)過程1140中，通 道必須確定它已經(jīng)接收到的數(shù)據(jù)是否足夠來完成給定任務(wù)。如果存在不 足的數(shù)據(jù)，則通道將等待來自選擇器的附加數(shù)據(jù)，并且選擇器返回到步 驟1148用來輪詢另外的活動。一旦從選擇器已經(jīng)接收到完整的協(xié)議消息， 則基于協(xié)議，通道將作用于所接收的全部數(shù)據(jù)。如果通道發(fā)出響應(yīng)，則 消息被發(fā)送回到選擇器以便于通過步驟1148和1154傳送到終點(diǎn)。如果 不需要來自通道的響應(yīng)，則在步驟1159選擇器關(guān)閉連接。通信插槽可在 任一端被中斷或關(guān)閉。
如圖13C和13D中所示的現(xiàn)有技術(shù)插槽通道和選擇器TCP過程展示 出眾多問題。在現(xiàn)有技術(shù)過程1140中，在選擇器內(nèi)進(jìn)行處理邏輯，而通 道僅管理到選擇器的請求。圖13D的這個(gè)現(xiàn)有技術(shù)處理目前被用在網(wǎng)服 務(wù)器，用于管理超文本傳輸協(xié)議(HTTP)通信，其使用單步請求/響應(yīng)范例。 即，整個(gè)過程是基于來自起點(diǎn)的一個(gè)請求以及來自終點(diǎn)的一個(gè)響應(yīng)。申 請人己經(jīng)發(fā)現(xiàn)雖然圖13D所示的插槽通道和選擇器TCP過程比圖13A 和13B的經(jīng)典單插槽-單通信通道過程在數(shù)據(jù)通信上提供一些改進(jìn)，但是 對于多步驟協(xié)議，如在e-mail傳送中所使用的那些協(xié)議，過程1140仍然 被視為無效率的且不適合的。
為了避開現(xiàn)有技術(shù)的上述問題，并且將插槽通信過程適配于e-mail 傳送，申請人已經(jīng)設(shè)計(jì)了若干通信方法，其提供為現(xiàn)有技術(shù)的插槽通信 方法提供了替換。尤其地，基于通道和選擇器TCP方法，申請人已經(jīng)開 發(fā)出經(jīng)改善的電子消息服務(wù)器，但是提供超出圖13E和13F中所示例的 插槽通道和選擇器方案的附加優(yōu)點(diǎn)。具體地，本發(fā)明的插槽通道和選擇 器TCP過程為插槽通道提供狀態(tài)管理和緩沖器大小設(shè)置，以便于允許在 緩沖器中存儲不完整的命令，由此適應(yīng)與變化大小的數(shù)據(jù)進(jìn)行的多步驟 通信?？勺兙彌_器大小及處置從選擇器到插槽通道的不完整讀取和寫入 的能力的這一添加，由此將數(shù)據(jù)處理從選擇器移動到通道。申請人提出
這個(gè)添加是從現(xiàn)有技術(shù)通道和選擇器方法的顯著變化，并且此外，申請 人已經(jīng)發(fā)現(xiàn)將處理邏輯從選擇器移動到插槽通道在郵件服務(wù)器數(shù)據(jù)處 置能力上提供遠(yuǎn)高于所期望的結(jié)果的改善，正如緊接著在以下進(jìn)一步詳 細(xì)說明的那樣。
首先參考圖13E,本發(fā)明的多插槽/線程模型1160包括如在現(xiàn)有技術(shù)
中的多個(gè)插槽(例如在圖13C中所示)，但是選擇器1162現(xiàn)在用來調(diào)節(jié)多 個(gè)終點(diǎn)(由分別由參考號1164A-C所指示的終點(diǎn)A-C所表示)之間的通信。 實(shí)質(zhì)上，在實(shí)際的數(shù)據(jù)處理發(fā)生于通道的同時(shí)，選擇器1162充當(dāng)數(shù)據(jù)的 看門人。參考圖13F，緊接著在以下描述與模型1160相聯(lián)系的過程。
結(jié)合圖13E，參考圖13F，本發(fā)明的使用插槽通道和選擇器方案的 TCP過程1170被示例。TCP過程1170包括與圖13D的現(xiàn)有技術(shù)插槽通 信過程1140相同的步驟1142-1154。然而，在數(shù)據(jù)流方向(INBOUND或 OUTBOUND)的確定之后，本發(fā)明過程與現(xiàn)有技術(shù)過程不同。在這點(diǎn)上， 一旦INBOUND數(shù)據(jù)從終點(diǎn)被接收到，則在步驟1172選擇器分配適當(dāng)大 小的緩沖器并且將數(shù)據(jù)導(dǎo)引到插槽用于處理。然后在通道處判斷1174被 進(jìn)行，以確定所接收的數(shù)據(jù)是否足夠來完成協(xié)議命令。如果判斷1174的 答案是NO，不存在足夠的信息來完成即將到來的任務(wù)，則過程返回到步 驟1148來輪詢附加的數(shù)據(jù)。如果判斷1174的答案是YES,完整的協(xié)議 消息已經(jīng)被接收到，則在步驟1176插槽通道根據(jù)所采用的協(xié)議來處理數(shù) 據(jù)。在判斷1178，在插槽通道確定來自插槽通道的響應(yīng)是否應(yīng)該被發(fā)送 到終點(diǎn)。如果判斷1178的答案是YES，則處理步驟1176的結(jié)果被導(dǎo)引 到步驟1148以便于傳送到終點(diǎn)。如果判斷1178的答案是NO，則不需要 通道響應(yīng)，則在步驟1180通道指令選擇器關(guān)閉連接，并且在步驟1159 選擇器關(guān)閉連接。連接還可被終點(diǎn)中斷。
上述所說明的通道和選擇器TCP方法可被用來經(jīng)由SMTP和其它電 子消息協(xié)議發(fā)送和接收e-mail。雖然選擇器正在等待來自給定插槽通道的 終點(diǎn)的響應(yīng)，但是選擇器可自由地啟動、管理其它的插槽連接、與之通
信或關(guān)閉之。這個(gè)方法是有利的，因?yàn)橥ㄟ^顯著增加數(shù)據(jù)傳輸?shù)男剩?br> 它大大增加了 SMTP數(shù)據(jù)業(yè)務(wù)量的產(chǎn)出能力，以及由此e-mail傳送服務(wù) 器的性能。
在由申請人開發(fā)創(chuàng)新之前，現(xiàn)有技術(shù)e-mail傳送技術(shù)產(chǎn)生32個(gè)消息 /第二峰值產(chǎn)出。借助由申請人進(jìn)行的上述創(chuàng)新的含括，但是沒有本發(fā)明 的本插槽通道和選擇器TCP過程，消息傳送系統(tǒng)實(shí)現(xiàn)了 150個(gè)消息/第二 峰值產(chǎn)出。在實(shí)際實(shí)施本發(fā)明的上述插槽通道和選擇器TCP過程之前， 預(yù)計(jì)的SMTP email傳送的性能改善比己經(jīng)實(shí)現(xiàn)的150個(gè)消息/第二峰值產(chǎn) 出(對于10000字節(jié)的消息)得到大約50至75。/。的改善。然而， 一旦被實(shí) 施，已經(jīng)發(fā)現(xiàn)與較早所說明的由申請人開發(fā)的改善相組合，本發(fā)明的 插槽通道和選擇器TCP過程產(chǎn)生超過800個(gè)消息/第二(對于10000消息) 的消息產(chǎn)出，從而導(dǎo)致比由申請人沒有插槽通道和選擇器TCP過程所實(shí) 現(xiàn)的性能得到突出的530%的增加，以及比已知的現(xiàn)有技術(shù)得到2500%的 增加。申請人提出這個(gè)改善是重大的且非預(yù)期的。
參考圖13E和F所說明的通道和選擇器方法還可被應(yīng)用到無狀態(tài)協(xié) 議，如用戶數(shù)據(jù)報(bào)協(xié)議(UDP)。在這種情況下的數(shù)據(jù)傳輸過程類似于上面 所說明的TCP方案，但是使用無狀態(tài)協(xié)議，其既不保證傳送也不要求連 接。緊接著在以下參考圖13G對這些概念進(jìn)一步詳細(xì)說明。
圖13G示例使用UDP的數(shù)據(jù)通信過程，其總體上由參考號1190表 示。在通信通道插槽已經(jīng)被建立且通道插槽已經(jīng)向選擇器登記之后，在 步驟1192通道插槽建立且向選擇器發(fā)送數(shù)據(jù)報(bào)包(例如，UDP包)。然后 在步驟1194數(shù)據(jù)報(bào)包被選擇器傳遞到終點(diǎn)，然后在步驟1148選擇器輪 詢數(shù)據(jù)傳輸活動。 一旦從終點(diǎn)接收到響應(yīng)，則在步驟1172選擇器分配適 當(dāng)?shù)木彌_器并且響應(yīng)被傳遞到始發(fā)的通道。如圖13G中所示的UDP通信 比圖13F的TCP通信較為簡單，因?yàn)閳D13G的通信過程是基于無狀態(tài)協(xié) 議，使得發(fā)送者與接收服務(wù)器之間的完整通信由單個(gè)請求和單個(gè)響應(yīng)組 成。如先前，選擇器可處置許多同時(shí)的UDP通信。
使用UDP的通道選擇器插槽管理過程可被用在例如DNS解析器， 以極大地改善DNS査詢過程的速度。本發(fā)明的DNS解析器利用插槽通 道和選擇器過程，以通過使用標(biāo)準(zhǔn)的DNS協(xié)議來發(fā)送和請求域名査詢數(shù) 據(jù)。這樣的DNS解析器可包括在始發(fā)的郵件服務(wù)器本身內(nèi)，以便于方便 傳輸和接收e-mail。使用TCP或UDP的通道選擇器插槽管理過程可與例 如上述所說明的可傳送性確認(rèn)過程相組合。
在本發(fā)明的DNS解析器實(shí)際實(shí)施之前，通過使用插槽通道和選擇器 過程的預(yù)計(jì)DNS解析(即査詢)的性能改善比具有每秒50個(gè)查詢的平均峰 值性能速率的目前現(xiàn)有技術(shù)的方法(BIND)得到大約100%的改善。未預(yù)期 地，申請人已經(jīng)發(fā)現(xiàn)基于本發(fā)明插槽通道和選擇器過程的DNS解析器 產(chǎn)生驚人的每秒3400個(gè)査詢的速度，因此比現(xiàn)存技術(shù)提供6800%的性能 增加。
插槽通道和選擇器過程可與例如本發(fā)明的上述API過程相組合，以 便于實(shí)現(xiàn)較高性能的API應(yīng)用，其在從服務(wù)器到API應(yīng)用的消息傳輸上 具有非常低的等待時(shí)間。
廣泛地，這個(gè)書面內(nèi)容已經(jīng)公開了至少在通過互聯(lián)網(wǎng)對接的消息系 統(tǒng)中、用于處理來自發(fā)送者且想要傳送到至少一個(gè)接收者的消息的方法， 所述發(fā)送者通過發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)，以及所述接收者通過接收 者服務(wù)器對接到互聯(lián)網(wǎng)，其中消息包括至少接收者信息和消息體。所述 方法包括在依賴于接收者信息來發(fā)送消息之前，借助通過互聯(lián)網(wǎng)建立 從發(fā)送者服務(wù)器到接收者服務(wù)器的臨時(shí)測試連接，測試接收者信息，以 便于提供消息到接收者的可傳送性的指示，而無需使用SMTP VRFY命 令。
雖然利用具有特定相應(yīng)取向的各種組件已經(jīng)對上述說明的每個(gè)實(shí)施 例加以示例，但是應(yīng)該理解到本發(fā)明可采取各種特定的配置，使各種組 件被定位在寬范圍的位置及相互取向上，并且仍然保持在本發(fā)明的實(shí)質(zhì) 和范圍內(nèi)。此外，適合的等效物可代替或添加到各種組件中而被使用，
這樣的替代物或添加的組件的功能和使用被保持以便為本領(lǐng)域中那些普 通技術(shù)人員所熟悉，并且因此被認(rèn)為是屬于本發(fā)明的范圍。例如，雖然
主要利用e-mail消息收發(fā)的情況，己經(jīng)對每個(gè)上述所說明的實(shí)施例加以 討論，但是本發(fā)明的電子消息傳送系統(tǒng)可被容易地配置成適應(yīng)其它類型 的電子消息，如例如往返于蜂窩電話及其它手提裝置的消息。
因此，本實(shí)例要被視為是示例性的，而不是限制性的，并且本發(fā)明 并不被局限于在此所給出的細(xì)節(jié)，而是可在在所附權(quán)利要求的范圍內(nèi)被 修改。
權(quán)利要求
1. 在通過互聯(lián)網(wǎng)對接的消息系統(tǒng)中，一種用于處理來自發(fā)送者且想要傳送到至少一個(gè)接收者的消息的方法，所述發(fā)送者通過能夠與接收者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，所述消息包括至少接收者信息及消息體，所述方法包括借助于通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的連接，測試所述接收者信息，以便于提供所述消息到所述接收者的可傳送性指示，而無需使用SMTP VRFY命令。
2. 根據(jù)權(quán)利要求1所述的方法，其中所述建立連接是一個(gè)臨時(shí)的測 試連接，并且在依賴于所述接收者信息來發(fā)送所述消息之前被完成。
3. 根據(jù)權(quán)利要求1所述的方法，其中所述建立連接是在依賴于所述 接收者信息來發(fā)送所述消息之前被完成；以及基于所述指示，執(zhí)行下述之一(i)將所述消息通過到所述接收者的所 述連接導(dǎo)引到所述接收者服務(wù)器，以及(ii)放棄所述消息的傳送。
4. 根據(jù)權(quán)利要求1所述的方法，其中測試所述接收者信息是根據(jù)所 述接收者信息來確認(rèn)所述消息到所述接收者的可傳送性，其中確認(rèn)包括 通過互聯(lián)網(wǎng)建立所述發(fā)送者服務(wù)器與所述接收者服務(wù)器之間的所述連 接，以及從所述發(fā)送者服務(wù)器，通過使用所述連接利用所述接收者服務(wù)器來 驗(yàn)證所述接收者信息，以便于不使用SMTPVRFY命令而提供所述接收 者是否通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)上的指示，所述指示是所述 接收者的確通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)的肯定確認(rèn)以及示出所 述接收者并未通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)的否定中的一個(gè)。
5. 根據(jù)權(quán)利要求1、 2所述的方法，進(jìn)一步包括 基于所述指示，執(zhí)行下述之一(i)通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的傳送連接，然后將所述消息導(dǎo)引到所述接收者 服務(wù)器以便于傳送到所述接收者，以及(ii)放棄所述消息到所述接收者的 傳送。
6. 根據(jù)權(quán)利要求1、 2所述的方法，進(jìn)一步包括 建立有關(guān)所述消息可傳送性的記錄。
7. 根據(jù)權(quán)利要求4所述的方法，進(jìn)一步包括基于所述指示，執(zhí)行下述之一(i)響應(yīng)于所述肯定確認(rèn)，將如此所產(chǎn) 生的所述消息通過所述連接導(dǎo)引到所述接收者服務(wù)器以便于傳送到所述 接收者，以及(ii)響應(yīng)于所述否認(rèn)，放棄所述消息的傳送。
8. 根據(jù)權(quán)利要求1、 2、 3、 4所述的方法，其中所述消息進(jìn)一步包括發(fā)送者信息，所述方法進(jìn)一步包括在將所述消息導(dǎo)引到所述接收者服務(wù)器之前，或在建立所述傳送連接之前，在所述發(fā)送者服務(wù)器處選擇多個(gè)IP地址；根據(jù)一預(yù)定規(guī)則集，規(guī)定所述多個(gè)IP地址中的某一個(gè)；以及 將所述多個(gè)IP地址中的所述某一個(gè)含括，作為所述消息的所述發(fā)送者信息的一部分。
9. 根據(jù)權(quán)利要求4所述的方法，進(jìn)一步包括 建立有關(guān)所述指示的記錄。
10. 根據(jù)權(quán)利要求l、 2、 3、 4所述的方法，其中所述消息系統(tǒng)包括用于處理數(shù)據(jù)的電子存儲器以及用于存儲文件的硬驅(qū)動器，以及所述方法進(jìn)一步包括將所述消息作為數(shù)據(jù)在所述電子存儲器中處置，而無需將所述消息 作為所述文件之一存儲在所述硬驅(qū)動器中。
11. 根據(jù)權(quán)利要求4所述的方法，其中所述連接是臨時(shí)測試連接并且所述驗(yàn)證是通過所述臨時(shí)測試連接進(jìn)行的。
12. 根據(jù)權(quán)利要求11所述的方法進(jìn)一步包括基于所述指示，執(zhí)行下述之一(i)響應(yīng)于所述肯定確認(rèn)，通過組合至 少所述接收者信息和消息體產(chǎn)生所述消息，然后通過互聯(lián)網(wǎng)建立所述發(fā) 送者服務(wù)器和所述接收者服務(wù)器之間的傳送連接，然后通過所述傳送連 接將如此產(chǎn)生的所述消息導(dǎo)引到所述接收者服務(wù)器，以便于傳送到所述200480019321.0接收者，以及(ii)響應(yīng)于所述否認(rèn)，放棄所述消息的傳送。
13. 根據(jù)權(quán)利要求1、 2或11所述的方法，其中測試所述接收者信息或使用所述臨時(shí)測試連接包括查詢接收者服務(wù)器以證實(shí)接收者信息是有效的。
14. 根據(jù)權(quán)利要求1、 2或11所述的方法，其中測試所述接收者信息或使用所述臨時(shí)測試連接包括確保接收者服務(wù)器的可用性以接入收進(jìn)的消息。
15. 在通過互聯(lián)網(wǎng)對接的消息系統(tǒng)中， 一種用于處理來自發(fā)送者且想要傳送到至少一個(gè)接收者的消息的方法，所述發(fā)送者通過能夠與接收者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，所述方法包括在所述發(fā)送者服務(wù)器處，從所述發(fā)送者接收用于定義所述消息的多個(gè)離散數(shù)據(jù)包，所述多個(gè)離散數(shù)據(jù)包中的至少一個(gè)包括接收者信息且所述多個(gè)離散數(shù)據(jù)包的至少另一個(gè)包括消息體；在依賴于所述接收者信息來發(fā)送所述消息之前，借助于通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的連接，測試所述接收者信息，以便于提供所述消息到所述接收者的可傳送性指示，而無需使用SMTPVRFY命令，以及；基于所述指示，執(zhí)行下述之一(i)通過組合至少所述接收者信息以及消息體，然后將所述消息通過所述連接導(dǎo)引到所述接收者服務(wù)器，以便于傳送到所述接收者，以及(ii)放棄所述消息的傳送。
16. 根據(jù)權(quán)利要求15所述的方法，其中借助于通過互聯(lián)網(wǎng)建立臨 時(shí)測試連接而實(shí)現(xiàn)所述接收者信息的所述測試，以及其中導(dǎo)引所述消息 是通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的傳送連接。
17. 根據(jù)權(quán)利要求16所述的方法，其中所述消息進(jìn)一步包括發(fā)送 者信息，以及其中產(chǎn)生所述消息包括在所述發(fā)送者服務(wù)器處選擇多個(gè)IP地址，根據(jù)一預(yù)定的規(guī)則集，規(guī)定所述多個(gè)IP地址中的某一個(gè)；以及 將所述多個(gè)IP地址中的所述某一個(gè)含括，作為所述消息的所述發(fā)送 者信息的一部分。
18. 根據(jù)權(quán)利要求15或16所述的方法，其中從所述發(fā)送者接收所 述多個(gè)離散數(shù)據(jù)包包括處理由人類用戶所產(chǎn)生的所述多個(gè)離散數(shù)據(jù)包。
19. 根據(jù)權(quán)利要求15或16所述的方法，其中從所述發(fā)送者接收所 述多個(gè)離散數(shù)據(jù)包包括處理由軟件應(yīng)用所產(chǎn)生的所述多個(gè)離散數(shù)據(jù)包。
20. 根據(jù)權(quán)利要求19所述的方法，進(jìn)一步包括 將所述軟件應(yīng)用與數(shù)據(jù)庫對接；在所述數(shù)據(jù)庫中定義觸發(fā)事件，以便于當(dāng)所述觸發(fā)事件發(fā)生在所述 數(shù)據(jù)庫中時(shí)，所述軟件應(yīng)用自動地產(chǎn)生所述多個(gè)離散數(shù)據(jù)包。
21. 在通過互聯(lián)網(wǎng)對接的消息系統(tǒng)中， 一種用于處理來自發(fā)送者且 想要傳送到至少一個(gè)接收者的消息的方法，所述發(fā)送者通過能夠與接收 者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，所述方法包括在所述發(fā)送者服務(wù)器處，從所述發(fā)送者接收用于定義所述消息的多 個(gè)離散數(shù)據(jù)包，所述多個(gè)離散數(shù)據(jù)包中的至少一個(gè)包括接收者信息且所 述多個(gè)離散數(shù)據(jù)包的至少另一個(gè)包括消息體；根據(jù)所述接收者信息，確認(rèn)所述消息到所述接收者的可傳送性，這 是通過通過互聯(lián)網(wǎng)建立所述發(fā)送者服務(wù)器與所述接收者服務(wù)器之間的連 接，以及從所述發(fā)送者服務(wù)器，通過所述連接利用所述接收者服務(wù)器來驗(yàn)證 所述接收者信息，以便于不使用SMTPVRFY命令而提供所述接收者是 否通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)上的指示，所述指示是所述接收 者的確通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)的肯定確認(rèn)以及示出所述接 收者并未通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)的否定中的一個(gè)；以及基于所述指示，執(zhí)行下述之一(i)響應(yīng)于所述肯定確認(rèn)，通過組合至 少所述接收者信息和消息體產(chǎn)生所述消息，然后通過所述連接將如此產(chǎn) 生的所述消息導(dǎo)引到所述接收者服務(wù)器，以便于傳送到所述接收者，以 及(ii)響應(yīng)于所述否認(rèn)，放棄所述消息的傳送。
22. 在通過互聯(lián)網(wǎng)對接的消息系統(tǒng)中， 一種用于處理來自發(fā)送者且 想要傳送到至少一個(gè)接收者的消息的方法，所述發(fā)送者通過能夠與接收者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，所述方法包括在所述發(fā)送者服務(wù)器處，從所述發(fā)送者接收用于定義所述消息的多 個(gè)離散數(shù)據(jù)包，所述多個(gè)離散數(shù)據(jù)包中的至少一個(gè)包括接收者信息且所述多個(gè)離散數(shù)據(jù)包的至少另一個(gè)包括消息體；根據(jù)所述接收者信息，確認(rèn)所述消息到所述接收者是可傳送的，這是通過通過互聯(lián)網(wǎng)建立所述發(fā)送者服務(wù)器與所述接收者服務(wù)器的臨時(shí)測試 連接，以及從所述發(fā)送者服務(wù)器，通過所述臨時(shí)測試連接利用所述接收者服務(wù)器來驗(yàn)證所述接收者信息，以便于不使用SMTP VRFY命令而提供所述 接收者是否通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)上的指示，所述指示是 所述接收者的確通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)的肯定確認(rèn)以及示 出所述接收者并未通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)的否定中的一 個(gè)；以及基于所述指示，執(zhí)行下述之一(i)響應(yīng)于所述肯定確認(rèn)，通過組合至 少所述接收者信息和消息體產(chǎn)生所述消息，然后通過互聯(lián)網(wǎng)建立所述發(fā) 送者與所述接收者之間的傳送連接，然后通過所述傳送連接將如此產(chǎn)生 的所述消息導(dǎo)引到所述接收者服務(wù)器，以便于傳送到所述接收者，以及 (ii)響應(yīng)于所述否認(rèn)，放棄所述消息的傳送。
23. —種經(jīng)修改的消息服務(wù)器，其被配置用來代替對接到互聯(lián)網(wǎng)用 于處理來自發(fā)送者且想要傳送到至少一個(gè)接收者的消息的未修改的消息 服務(wù)器，所述發(fā)送者通過能夠與接收者服務(wù)器通信的所述未修改的消息 服務(wù)器對接到互聯(lián)網(wǎng)上，所述未修改的消息服務(wù)器包括被配置用于將消 息作為消息文件保存到其上的硬驅(qū)動器，以及所述未修改的消息服務(wù)器被配置成將所述消息文件前轉(zhuǎn)到所述接收者服務(wù)器，所述經(jīng)修改的消息 服務(wù)器包括用于從所述發(fā)送者接收用來定義所述消息的多個(gè)離散數(shù)據(jù)包的裝 置，所述多個(gè)離散數(shù)據(jù)包中的至少一個(gè)包括接收者信息且所述多個(gè)離散數(shù)據(jù)包的至少另一個(gè)包括消息體，所述經(jīng)修改的接收裝置包括電子存儲器，用于將所述多個(gè)離散數(shù)據(jù)包保存在其中；以及用于處理所述多個(gè)離散數(shù)據(jù)包并且通過組合至少所述接收者信息和消息體來產(chǎn)生所述消息的裝置。
24. 根據(jù)權(quán)利要求23所述的經(jīng)修改的消息服務(wù)器，進(jìn)一步包括裝置，用于在依賴于所述接收者信息來發(fā)送所述消息之前，借助于通過互聯(lián)網(wǎng)建立從所述經(jīng)修改的消息服務(wù)器到所述接收者服務(wù)器的連接，測試所述接收者信息，以便于不使用SMTPVRFY命令而提供所述接收者是否通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)上的指示，所述指示是 所述接收者的確通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)的肯定確認(rèn)以及示出所述接收者并未通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)的否定中的一 個(gè)。
25. 根據(jù)權(quán)利要求24所述的經(jīng)修改的消息服務(wù)器，其中所述處理裝置被配置成基于指示，執(zhí)行下述之一(i)響應(yīng)于所述肯定確認(rèn)，將如此產(chǎn)生的所述消息通過所述連接導(dǎo)引到所述接收者服務(wù)器，以便于傳送 到所述接收者，以及(ii)響應(yīng)于所述否認(rèn)，放棄所述消息的傳送。
26. 根據(jù)權(quán)利要求24所述的經(jīng)修改的消息服務(wù)器，其中所述處理裝置被配置成僅在所述測試裝置提供所述肯定確認(rèn)之后才產(chǎn)生所述消息。
27. 在通過互聯(lián)網(wǎng)對接的消息系統(tǒng)中， 一種用于處理來自發(fā)送者的一消息組的方法，所述發(fā)送者通過能夠與多個(gè)接收者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，所述消息組中的每一個(gè)想要傳送到接收者， 所述方法包括在所述發(fā)送者服務(wù)器處，從所述發(fā)送者接收用于定義所述消息組的 多個(gè)離散數(shù)據(jù)包，對于所述消息組中對應(yīng)的一個(gè)消息，所述多個(gè)離散數(shù) 據(jù)包中的至少一個(gè)包括接收者信息且所述多個(gè)離散數(shù)據(jù)包的至少另一個(gè) 包括消息體；通過對于所述消息組中的每一個(gè)消息，將至少所述接收者信息與消 息體進(jìn)行組合而產(chǎn)生所述消息組；以及基于所述消息組中每一個(gè)消息的至少所述接收者信息和所述消息體 之一，以根據(jù)預(yù)定規(guī)則集的次序來設(shè)置所述消息組。
28. 根據(jù)權(quán)利要求27所述的方法，對于所述消息組中的每一個(gè)消 息，進(jìn)一步包括在依賴于所述接收者信息來發(fā)送所述消息組中的所述一個(gè)消息之 前，借助于通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù)器到所述多個(gè)接收者服務(wù) 器中對應(yīng)的一個(gè)的連接，測試所述接收者信息，以便于提供到所述多個(gè) 接收者中對應(yīng)一個(gè)的可傳送性指示，而無需使用SMTPVRFY命令，以 及；基于所述指示，執(zhí)行下述之一(i)通過所述連接來導(dǎo)弓I所述消息組中 的所述一個(gè)消息以便于通過所述多個(gè)接收者服務(wù)器中的所述對應(yīng)的一個(gè) 傳送到所述多個(gè)接收者之一，以及(ii)放棄所述消息組中所述一個(gè)消息的傳送。
29. 根據(jù)權(quán)利要求27所述的方法，對于所述消息組中的每一個(gè)消 息，進(jìn)一步包括在依賴于所述接收者信息來發(fā)送所述消息組中的對應(yīng)一個(gè)消息之 前，借助于通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù)器到所述多個(gè)接收者服務(wù) 器中對應(yīng)一個(gè)的臨時(shí)測試連接，測試所述接收者信息，以便于提供到所 述多個(gè)接收者中對應(yīng)一個(gè)的可傳送性指示，而無需使用SMTPVRFY命令，以及；基于所述指示，執(zhí)行下述之一(i)通過互聯(lián)網(wǎng)建立從所述發(fā)送者到所 述多個(gè)接收者服務(wù)器中對應(yīng)一個(gè)的傳送連接，以及通過所述傳送連接來 導(dǎo)引所述消息組中的所述對應(yīng)的一個(gè)消息以便于通過所述多個(gè)接收者服 務(wù)器中的所述對應(yīng)的一個(gè)傳送到所述多個(gè)接收者之一，以及(ii)放棄所述 消息組中所述一個(gè)消息的傳送。
30. 根據(jù)權(quán)利要求27所述的方法，其中所述多個(gè)離散數(shù)據(jù)包中的 又一個(gè)包括用于所述消息組中對應(yīng)一個(gè)消息的發(fā)送者信息，以及其中產(chǎn) 生所述消息組進(jìn)一步包括在所述發(fā)送者服務(wù)器處選擇多個(gè)IP地址，根據(jù)一預(yù)定的規(guī)則集，規(guī)定所述多個(gè)IP地址中的某一個(gè)；以及將所述多個(gè)IP地址中的所述某一個(gè)含括，作為所述消息組中每一個(gè) 消息的所述發(fā)送者信息的一部分。
31. 在通過互聯(lián)網(wǎng)對接的消息系統(tǒng)中， 一種用于處理來自發(fā)送者且想要傳送到至少一個(gè)接收者的消息的方法，所述發(fā)送者通過能夠與接收者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，所述方法包括在所述發(fā)送者服務(wù)器處，從所述發(fā)送者接收用于定義所述消息的多 個(gè)離散數(shù)據(jù)包，所述多個(gè)離散數(shù)據(jù)包中的至少一個(gè)包括接收者信息且所 述多個(gè)離散數(shù)據(jù)包的至少另一個(gè)包括消息體；將所述多個(gè)離散數(shù)據(jù)包通過應(yīng)用程序接口導(dǎo)引到多個(gè)外部應(yīng)用之 一，用于執(zhí)行至少下述之一(i)根據(jù)第一預(yù)定規(guī)則集，修改所述多個(gè)離散 數(shù)據(jù)包，(ii)根據(jù)第二預(yù)定規(guī)則集，向所述多個(gè)離散數(shù)據(jù)包添加附加的數(shù) 據(jù)包，以及(iii)根據(jù)第三預(yù)定規(guī)則集，排序所述多個(gè)離散數(shù)據(jù)包，并且因此，用于提供多個(gè)所得到的數(shù)據(jù)包；通過所述應(yīng)用程序接口從所述多個(gè)外部應(yīng)用之一接收所述多個(gè)所得 到的數(shù)據(jù)包；通過組合所述多個(gè)所得到的數(shù)據(jù)包的至少部分來產(chǎn)生所述消息；通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的連接；以及將所述消息通過所述連接導(dǎo)引到所述接收者服務(wù)器，以便于傳送到 所述接收者。
32. —種通過互聯(lián)網(wǎng)對接的消息系統(tǒng)，用于處理來自發(fā)送者且想要 傳送到至少一個(gè)接收者的消息，所述發(fā)送者通過能夠與接收者服務(wù)器通 信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，所述消息包括至少接收者信息和消息體，所述消息系統(tǒng)包括測試裝置，用于在依賴于所述接收者信息來發(fā)送所述消息之前，借 助于通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的臨時(shí)測 試連接，測試所述接收者信息，以便于提供所述消息到所述接收者的可傳送性指示，而無需使用SMTP VEFY命令。
33. 根據(jù)權(quán)利要求32所述的系統(tǒng)，其中所述建立連接是一個(gè)臨時(shí)的測試連接。
34. 根據(jù)權(quán)利要求32或33所述的消息系統(tǒng)，進(jìn)一步包括 選擇性傳送裝置，用于基于所述指示，執(zhí)行下述之一(i)通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的傳送連接，然后將所述消息導(dǎo)引到所述接收者服務(wù)器以便于傳送到所述接收者，以及(ii)放棄所 述消息到所述接收者的傳送。
35. 根據(jù)權(quán)利要求32或33所述的消息系統(tǒng)，進(jìn)一步包括用于處 理數(shù)據(jù)的電子存儲器及用于存儲文件的硬驅(qū)動器，其中所述消息系統(tǒng)被 配置成將所述消息作為數(shù)據(jù)在電子存儲器中處理，而無需將所述消息作 為所述文件之一而存儲在所述硬驅(qū)動器中。
36. 根據(jù)權(quán)利要求32所述的系統(tǒng)，進(jìn)一步包括選擇性傳送裝置，用于基于所述指示，執(zhí)行下述之一(i)將所述消息通過所述連接導(dǎo)弓I到所述接收者服務(wù)器以便于傳送到所述接收者，以及 (ii)放棄所述消息的傳送。
37. —種通過互聯(lián)網(wǎng)對接的消息系統(tǒng)，用于處理來自發(fā)送者且想要傳送到至少一個(gè)接收者的消息，所述發(fā)送者通過發(fā)送者服務(wù)器對接到互 聯(lián)網(wǎng)上并且所述接收者通過接收者服務(wù)器對接到互聯(lián)網(wǎng)上，所述消息包括至少發(fā)送者信息、接收者信息和消息體，所述消息系統(tǒng)包括測試裝置，其用于根據(jù)所述接收器信息，確認(rèn)所述消息到所述接收者的可傳送性，這是通過通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的連接，以及從所述發(fā)送者服務(wù)器，通過使用所述連接利用所述接收者服務(wù)器來驗(yàn)證所述接收者信息，以便于不使用SMTP VRFY命令而提供所述接收 者是否通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)上的指示，所述指示是所述 接收者的確通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)的肯定確認(rèn)以及示出所 述接收者并未通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)的否定中的一個(gè)。
38. 根據(jù)權(quán)利要求37所述的消息系統(tǒng)，進(jìn)一步包括選擇性傳送裝置，用于基于所述指示，執(zhí)行下述之一(i)響應(yīng)于所述肯定確認(rèn)，將如此 所產(chǎn)生的所述消息通過所述連接導(dǎo)引到所述接收者服務(wù)器以便于傳送到 所述接收者，以及(ii)響應(yīng)于所述否認(rèn)，放棄所述消息的傳送。
39. —種通過互聯(lián)網(wǎng)對接的消息系統(tǒng)，用于處理來自發(fā)送者且想要 傳送到至少一個(gè)接收者的消息，所述發(fā)送者通過能夠與接收者服務(wù)器通 信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，所述消息包括至少接收者信息和消 息體，所述消息系統(tǒng)包括測試裝置，其用于根據(jù)所述接收器信息，確認(rèn)所述消息到所述接收 者的可傳送性，這是通過通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的連接，以及從所述發(fā)送者服務(wù)器，通過使用所述臨時(shí)測試連接利用所述接收者 服務(wù)器來驗(yàn)證所述接收者信息，以便于不使用SMTP VRFY命令而提供所述接收者是否通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)上的指示，所述指 示是所述接收者的確通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)的肯定確認(rèn)以 及示出所述接收者并未通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)的否定中的一個(gè)。
40. 根據(jù)權(quán)利要求39所述的消息系統(tǒng)，進(jìn)一步包括選擇性傳送裝 置，用于基于所述指示，執(zhí)行下述之一(i)響應(yīng)于所述肯定確認(rèn)，通過組 合至少所述接收者信息和消息體而產(chǎn)生所述消息，然后通過互聯(lián)網(wǎng)建立 所述發(fā)送者服務(wù)器與所述接收者服務(wù)器之間的傳送連接，然后將如此所 產(chǎn)生的所述消息通過所述傳送連接導(dǎo)引到所述接收者服務(wù)器以便于傳送 到所述接收者，以及(ii)響應(yīng)于所述否認(rèn)，放棄所述消息的傳送。
41. 一種通過互聯(lián)網(wǎng)對接的消息系統(tǒng)，用于處理來自發(fā)送者且想要 傳送到至少一個(gè)接收者的消息，所述發(fā)送者通過能夠與接收者服務(wù)器通 信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，所述消息系統(tǒng)包括-接收裝置，在所述發(fā)送者服務(wù)器處，其用于從所述發(fā)送者接收用于 定義所述消息的所述多個(gè)離散數(shù)據(jù)包，所述多個(gè)離散數(shù)據(jù)包中的至少一 個(gè)包括接收者信息且所述多個(gè)離散數(shù)據(jù)包的至少另一個(gè)包括消息體；測試裝置，其用于在依賴于所述接收者信息來發(fā)送所述消息之前， 借助于通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的臨時(shí) 測試連接，測試所述接收者信息，以便于提供所述消息到所述接收者的 可傳送性指示，而無需使用SMTPVRFY命令；以及選擇性傳送裝置，其基于所述指示，執(zhí)行下述之一(i)通過組合至少 接收者信息和消息體產(chǎn)生所述消息，然后通過互聯(lián)網(wǎng)建立從發(fā)送者服務(wù) 器到接收者服務(wù)器的傳送連接，然后通過所述傳送連接將所述消息導(dǎo)引 到所述接收者服務(wù)器，以便于傳送到所述接收者，以及(ii)放棄所述消息 的傳送。
42. —種通過互聯(lián)網(wǎng)對接的消息系統(tǒng)，用于處理來自發(fā)送者且想要 傳送到至少一個(gè)接收者的消息，所述發(fā)送者通過能夠與接收者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，所述消息系統(tǒng)包括接收裝置，在所述發(fā)送者服務(wù)器處，其用于從所述發(fā)送者接收用于 定義所述消息的所述多個(gè)離散數(shù)據(jù)包，所述多個(gè)離散數(shù)據(jù)包中的至少一 個(gè)包括接收者信息且所述多個(gè)離散數(shù)據(jù)包的至少另一個(gè)包括消息體；測試裝置，其用于在依賴于所述接收者信息來發(fā)送所述消息之前， 借助于通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的連 接，測試所述接收者信息，以便于提供所述消息到所述接收者的可傳送 性指示，而無需使用SMTPVRFY命令，以及；選擇性傳送裝置，其基于所述指示，執(zhí)行下述之一(i)通過組合至少 接收者信息和消息體產(chǎn)生所述消息，然后通過所述連接將所述消息導(dǎo)引 到所述接收者服務(wù)器，以便于傳送到所述接收者，以及(ii)放棄所述消息 的傳送。
43.—種通過互聯(lián)網(wǎng)對接的消息系統(tǒng)，用于處理來自發(fā)送者且想要傳送到至少一個(gè)接收者的消息，所述發(fā)送者通過能夠與接收者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，所述消息系統(tǒng)包括接收裝置，在所述發(fā)送者服務(wù)器處，其用于從所述發(fā)送者接收用于 定義所述消息的所述多個(gè)離散數(shù)據(jù)包，所述多個(gè)離散數(shù)據(jù)包中的至少一 個(gè)包括接收者信息且所述多個(gè)離散數(shù)據(jù)包的至少另一個(gè)包括消息體；測試裝置，其用于根據(jù)所述接收器信息，確認(rèn)所述消息到所述接收 者的可傳送性，這是通過通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的連接，以及從所述發(fā)送者服務(wù)器，通過所述連接利用所述接收者服務(wù)器來驗(yàn)證所述接收者信息，以便于不使用SMTP VRPY命令而提供所述接收者是 否通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)上的指示，所述指示是所述接收 者的確通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)的肯定確認(rèn)以及示出所述接 收者并未通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)的否定中的一個(gè)；以及選擇性傳送裝置，用于基于所述指示，執(zhí)行下述之一(i)響應(yīng)于所述 肯定確認(rèn)，通過組合至少所述接收者信息和消息體而產(chǎn)生所述消息，然 后將如此所產(chǎn)生的所述消息通過所述連接導(dǎo)引到所述接收者服務(wù)器以便 于傳送到所述接收者，以及(ii)響應(yīng)于所述否認(rèn)，放棄所述消息的傳送。
44. 一種通過互聯(lián)網(wǎng)對接的消息系統(tǒng)，用于處理來自發(fā)送者且想要 傳送到至少一個(gè)接收者的消息，所述發(fā)送者通過能夠與接收者服務(wù)器通 信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，所述消息系統(tǒng)包括接收裝置，在所述發(fā)送者服務(wù)器處，其用于從所述發(fā)送者接收用于 定義所述消息的所述多個(gè)離散數(shù)據(jù)包，所述多個(gè)離散數(shù)據(jù)包中的至少一 個(gè)包括接收者信息且所述多個(gè)離散數(shù)據(jù)包的至少另一個(gè)包括消息體；測試裝置，其用于根據(jù)所述接收器信息，確認(rèn)所述消息到所述接收 者是可傳送的，這是通過通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的臨時(shí)測 試連接，以及從所述發(fā)送者服務(wù)器，通過所述臨時(shí)測試連接利用所述接收者服務(wù)器來驗(yàn)證所述接收者信息，以便于不使用SMTP VRFY命令而提供所述接收者是否通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)上的指示，所述指示是 所述接收者的確通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)的肯定確認(rèn)以及示 出所述接收者并未通過所述接收者服務(wù)器對接到互聯(lián)網(wǎng)的否定中的一個(gè)；以及選擇性傳送裝置，用于基于所述指示，執(zhí)行下述之一(i)響應(yīng)于所述 肯定確認(rèn)，通過組合至少所述接收者信息和消息體而產(chǎn)生所述消息，然 后通過互聯(lián)網(wǎng)建立所述發(fā)送者服務(wù)器與接收者服務(wù)器之間的傳送連接， 然后將如此所產(chǎn)生的所述消息通過所述傳送連接導(dǎo)引到所述接收者服務(wù) 器以便于傳送到所述接收者，以及(ii)響應(yīng)于所述否認(rèn)，放棄所述消息的 傳送。
45. 在通過互聯(lián)網(wǎng)對接的消息系統(tǒng)中， 一種用于處理來自發(fā)送者且想要傳送到至少一個(gè)接收者的消息的方法，所述發(fā)送者通過能夠與接收 者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，所述消息系統(tǒng)包括用于 處理數(shù)據(jù)的電子存儲器，所述方法包括將所述消息作為數(shù)據(jù)在所述電子存儲器中處置。
46. 根據(jù)權(quán)利要求45所述的方法，其中所述消息系統(tǒng)進(jìn)一步包括 用于存儲文件的硬驅(qū)動器，以及其中對所述消息的所述處置包括處置 所述消息，而無需將所述消息作為所述文件之一來存儲在所述硬驅(qū)動器 中。
47. 根據(jù)權(quán)利要求45所述的方法，進(jìn)一步包括 在所述發(fā)送者服務(wù)器處，將所述消息分成多個(gè)離散數(shù)據(jù)包，所述多個(gè)離散數(shù)據(jù)包中的至少一個(gè)包括接收者信息且所述多個(gè)離散數(shù)據(jù)包的至 少另一個(gè)包括消息體；以及通過應(yīng)用程序接口，將所述多個(gè)離散數(shù)據(jù)包導(dǎo)引到多個(gè)外部應(yīng)用之 一，用于執(zhí)行至少下述之一(i)根據(jù)第一預(yù)定規(guī)則集，修改所述多個(gè)離散 數(shù)據(jù)包，(ii)根據(jù)第二預(yù)定規(guī)則集，向所述多個(gè)離散數(shù)據(jù)包添加附加的數(shù) 據(jù)包，以及(m)根據(jù)第三預(yù)定規(guī)則集，排序所述多個(gè)離散數(shù)據(jù)包，并且因 此，用于提供多個(gè)所得到的數(shù)據(jù)包。
48. 根據(jù)權(quán)利要求47所述的方法，進(jìn)一步包括 通過所述應(yīng)用程序接口 ，從所述多個(gè)外部應(yīng)用之一接收所述多個(gè)所得到的數(shù)據(jù)包；通過組合所述多個(gè)所得到的數(shù)據(jù)包的至少部分來產(chǎn)生所述消息； 通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的連接；以及將所述消息通過所述連接導(dǎo)引到所述接收者服務(wù)器，以便于傳送到 所述接收者。
49. 在通過互聯(lián)網(wǎng)對接的消息系統(tǒng)中， 一種用于處理來自發(fā)送者的 消息的方法，所述發(fā)送者通過能夠與多個(gè)接收者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，所述消息想要傳送到接收者，所述方法包括在所述發(fā)送者服務(wù)器處，將所述消息分成多個(gè)離散數(shù)據(jù)包，所述多 個(gè)離散數(shù)據(jù)包中的至少一個(gè)包括接收者信息且所述多個(gè)離散數(shù)據(jù)包的至 少另一個(gè)包括消息體；在依賴于所述接收者信息來發(fā)送所述消息之前，借助于通過互聯(lián)網(wǎng) 建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的連接，測試所述接收者 信息，以便于提供到所述接收者的可傳送性指示，而無需使用SMTPVRFY命令；以及基于所述指示，執(zhí)行下述之一(i)通過所述連接導(dǎo)引所述消息以便于 通過所述接收者服務(wù)器傳送到所述接收者，以及(ii)放棄所述消息的傳送。
50. 在通過互聯(lián)網(wǎng)對接的消息系統(tǒng)中， 一種用于處理來自發(fā)送者的消息的方法，所述發(fā)送者通過能夠與接收者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，所述消息想要傳送到接收者，所述方法包括在所述發(fā)送者服務(wù)器處，將所述消息分成多個(gè)離散數(shù)據(jù)包，所述多個(gè)離散數(shù)據(jù)包中的至少一個(gè)包括接收者信息且所述多個(gè)離散數(shù)據(jù)包的至 少另一個(gè)包括消息體；在依賴于所述接收者信息來發(fā)送所述消息之前，借助于通過互聯(lián)網(wǎng) 建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的臨時(shí)測試連接，測試所 述接收者信息，以便于提供到所述接收者的可傳送性指示，而無需使用SMTPVRFY命令；以及基于所述指示，執(zhí)行下述之一(i)通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù) 器到所述接收者服務(wù)器的傳送連接，以及通過所述連接導(dǎo)引所述消息以 便通過所述接收者服務(wù)器傳送到所述接收者，以及(ii)放棄所述消息的傳送。
51. 在通過互聯(lián)網(wǎng)對接的消息系統(tǒng)中， 一種用于處理來自發(fā)送者的 一消息組的方法，所述發(fā)送者通過能夠與多個(gè)接收者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，所述消息組想要傳送到接收者，所述方法包 括在所述發(fā)送者服務(wù)器處，將所述消息組中的每個(gè)消息分成多個(gè)離散 數(shù)據(jù)包，對于所述消息組中的對應(yīng)消息，所述多個(gè)離散數(shù)據(jù)包中的至少 一個(gè)包括接收者信息且所述多個(gè)離散數(shù)據(jù)包的至少另一個(gè)包括消息體；基于所述消息組中每一個(gè)消息的至少所述接收者信息和所述消息體 之一，以根據(jù)預(yù)定規(guī)則集的次序來設(shè)置所述消息組。
52. 根據(jù)權(quán)利要求51所述的方法，進(jìn)一步包括將所述多個(gè)離散數(shù)據(jù)包通過應(yīng)用程序接口導(dǎo)引到多個(gè)外部應(yīng)用之 一，用于執(zhí)行至少下述之一(i)根據(jù)第一預(yù)定規(guī)則集，修改所述多個(gè)離散 數(shù)據(jù)包，(ii)根據(jù)第二預(yù)定規(guī)則集，向所述多個(gè)離散數(shù)據(jù)包添加附加的數(shù) 據(jù)包，以及(iii)根據(jù)第三預(yù)定規(guī)則集，排序所述多個(gè)離散數(shù)據(jù)包，并且因 此，用于提供多個(gè)所得到的數(shù)據(jù)包
53. 在通過互聯(lián)網(wǎng)對接的消息系統(tǒng)中， 一種用于處理來自發(fā)送者且 想要傳送到至少一個(gè)接收者的消息的方法，所述發(fā)送者通過能夠與接收 者服務(wù)器通信的發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，所述消息系統(tǒng)包括用于 處理數(shù)據(jù)的電子存儲器以及用于存儲文件的硬驅(qū)動器，所述方法包括選擇至少下述之一(i)將所述消息作為數(shù)據(jù)在所述電子存儲器中處 置，而無需將所述消息作為所述文件之一存儲在所述硬驅(qū)動器中，以及 (ii)將所述消息作為所述文件之一存儲在所述硬驅(qū)動器中。
54. 根據(jù)權(quán)利要求53所述的方法，其中所述消息包括至少接收者信息和消息體，所述方法進(jìn)一步包括在依賴于所述接收者信息來發(fā)送所述消息之前，借助于通過互聯(lián)網(wǎng) 建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的臨時(shí)測試連接，測試所 述接收者信息，以便于提供所述消息到所述接收者的可傳送性指示，而無需使用SMTP VEFY命令。
55. 根據(jù)權(quán)利要求54所述的方法，進(jìn)一步包括基于所述指示，執(zhí)行下述之一(i)通過互聯(lián)網(wǎng)建立從所述發(fā)送者服務(wù) 器到所述接收者服務(wù)器的傳送連接，然后將所述消息導(dǎo)引到所述接收者 服務(wù)器以便于傳送到所述接收者，以及(ii)放棄所述消息到所述接收者的 傳送
56.根據(jù)權(quán)利要求53所述的方法，其中所述消息包括至少接收者信息和消息體，所述方法進(jìn)一步包括在依賴于所述接收者信息來發(fā)送所述消息之前，借助于通過互聯(lián)網(wǎng) 建立從所述發(fā)送者服務(wù)器到所述接收者服務(wù)器的連接，測試所述接收者信息，以便于提供到所述接收者的可傳送性指示，而無需使用SMTP VRFY命令，以及；基于所述指示，執(zhí)行下述之一(i)將所述消息通過所述連接導(dǎo)引到所 述接收者服務(wù)器，再到所述接收者，以及(ii)放棄所述消息的傳送。
全文摘要
公開了在通過互聯(lián)網(wǎng)對接的消息系統(tǒng)中，一種用于處理來自發(fā)送者且想要傳送到至少一個(gè)接收者的消息的方法，所述發(fā)送者通過發(fā)送者服務(wù)器對接到互聯(lián)網(wǎng)上，以及所述接收者通過接收者服務(wù)器對接到互聯(lián)網(wǎng)上，其中所述消息包括至少接收者信息及消息體。所述方法包括在依賴于接收者信息來發(fā)送消息之前，借助于通過互聯(lián)網(wǎng)建立從發(fā)送者服務(wù)器到接收者服務(wù)器的臨時(shí)測試連接，來測試接收者信息，以便于提供所述消息到接收者的可傳送性指示，而無需使用SMTP VRFY命令。
文檔編號G06F11/00GK101390071SQ200480019321
公開日2009年3月18日 申請日期2004年7月6日 優(yōu)先權(quán)日2003年7月7日
發(fā)明者凱利·A·萬塞, 小維克托·加諾拉, 斯科特·T·布朗 申請人:科爾德斯帕克有限責(zé)任公司