本備忘錄的狀態
本文檔講述了一種Internet社區的Internet標準跟蹤協議，它需要進一步進行討論和建
議以得到改進。請參考最新版的“Internet正式協議標準”(STD1)來獲得本協議的標準化
程度和狀態。本備忘錄的發布不受任何限制。
版權聲明
Copyright(C)TheInternetSociety(2001).
IESG聲明
此POP3協議的擴展是供服務器使用，來描述服務器治理員采取的對策的。它不是POP3
進一步擴展之實現的保證。普通的觀點是，出于單純的從一個郵件服務器下載郵件的目的，
POP3協議應該保持簡單。假如需要更復雜的操作，應該使用IMAP協議。第7節的第一段
應該仔細閱讀。
目錄
1．介紹 2
2．這篇文檔使用的約定。 2
3．一般命令和響應語法 3
4．參數和響應長度 3
5.CAPA命令 4
6.功能的初始集合 4
6.1TOP功能 5
6.2.USER功能 5
6.3.SASLcapability 5
6.4.RESP-CODES功能 5
6.5.LOGIN-DELAY功能 6
6.6PipELINING功能 6
6.7EXPIRE功能 7
6.8UIDL功能 8
6.9IMPLEMENTATION功能 8
7.POP3的未來擴展 9
8.擴展POP3響應碼 9
8．1初始化POP3響應碼 9
9．IANA考慮 10
10.安全考慮 10
11.致謝 11
12.參考文獻 11
13.作者地址 11
14.完整版權說明 12

1．介紹
郵局協議第3版[POP3]使用廣泛。但是，當它包含某些可選的命令時（以及某些已經發
布的協議擴展），它缺乏一種機制，來對這些擴展或動作變化提供公開的支持。
目前這些可選特征和擴展只能通過探測的方式檢測到，假如可行的話。這種方式至少是
缺乏效率的，甚至可能更壞。因此，某些客戶端有用于人工配置POP3功能的選項。
因為POP3的一個最重要的特征是它的簡單，所以擴展的數目最好比較少。但是，某些
擴展是必需的（比如提供改善的安全性的擴展[POP-AUTH]），而其它的只在特定情況下是值
得要的。另外，需要一種發現服務器的方法。
此備忘錄對RFC1939[POP3]進行改進，以提供一種機制用來聲明對可選命令，擴展，和
無條件服務器行為的支持。它包含了已經配置的功能的初始配置，這些配置因服務器而異，
以及許多新功能（SASL,RESP-CODES,LOGIN-DELAY,PIPELINING,EXPIRE和
IMPLEMENTATION)。這篇文檔也對POP3的錯誤信息進行了擴展，這樣機器的可解析代碼就能
夠提供給客戶端。還包含響應碼的初始設置。另外，還定義了一個POP3命令和響應的[ABNF]
規格說明。
公開的評論應該發送到IETF　POP3擴展郵件列表<ietf-pop3ext@imc.org>。想訂閱的
話，可以向<ietf-pop3ext-request@imc.org>發送一條包含SUBSCRIBE的消息。
2．這篇文檔使用的約定。
　　這篇文檔里的"REQUIRED","MUST","MUSTNOT","SHOULD","SHOULDNOT",
和“MAY”的解釋和“KeyWordsforuseinRFCstoIndicateRequirementLevels”[KEYWORDS]
里描述的一樣。
在例子中，“C:”和“S:”表是客戶端和服務器端分別發送的信息。
3．一般命令和響應語法
POP3命令和響應的一般形式使用[ABNF]進行描述：
POP3命令：
command=keyword*(SPparam)CRLF;最大255八位組
keyword=3*4VCHAR
param=1*VCHAR
POP3響應
response=greeting/single-line/capa-resp/multi-line
capa-resp=single-line*capability"."CRLF
capa-tag=1*cchar
capability=capa-tag*(SPparam)CRLF;最大512八位組
cchar=%x21-2D/%x2F-7F
;可打印ASCII碼,“.”除外
dot-stuffed=*CHARCRLF;必須以圓點填充
gchar=%x21-3B/%x3D-7F
;可打印的ASCII碼，“<"除外
greeting="+OK"[resp-code]*gchar[timestamp]*gcharCRLF
;最大512八位組
multi-line=single-line*dot-stuffed"."CRLF
rchar=%x21-2E/%x30-5C/%x5E-7F
;可打印的ASCII碼，“/”和“]”除外
resp-code="["resp-level*("/"resp-level)"]"
resp-level=1*rchar
schar=%x21-5A/%x5C-7F
;可打印的ASCII碼,“［”除外
single-line=status[SPtext]CRLF;最大512八位組
status="+OK"/"-ERR"
text=*schar/resp-code*CHAR
timestamp="<"*VCHAR">"
;必須符合RFC-822的msg-id規定
4．參數和響應長度
這里的闡述增加了RFC1939提出的命令和參數長度限制。
一個命令的最大長度從47字符（4字符的命令，單空格，40個字符變量，CRLF）增加
到255八位組，包括有限CRLF。
支持CAPA命令的服務器必須支持長達255八位組的命令。服務器也必須支持任何支持
的功能所指定的最大命令長度。
命令響應的第一行的最大長度（包括開始的問候）還是512八位組不變（包括有限CRLF）。
5.CAPA命令
POP3的CAPA命令返回POP3服務器支持的功能列表。它在AUTHORIZATION和TRANSACTION
狀態下均可使用。
一個功能描述必須記錄在功能通告于何種狀態下，以及在哪種狀態下命令有效。
在AUTHORIZATION狀態下可用的功能必須在兩種狀態下都予以通告。
假如某個功能在兩種狀態下都被通告了，但是在身份驗證之后參數可能不同。這種可能
性必須在功能描述中說明。
（這些要求答應一個客戶端在不使用任何TRANSACTION-only功能，以及任何在身份驗證之
后參數值可能不同的功能時，只發送一個CAPA命令。）
假如身份驗證這步商定了一個完整性保護層，客戶端應該在驗證重新發送CAPA命令，
以阻止活動的down-negotiation攻擊。
每個功能都可能激活額外的協議命令，額外的參數和已存在命令的響應，或者描述服務
器行為的一個方面。這些細節在相應的功能描述中闡述。
第3節描述了使用[ABNF]的CAPA響應。當一個功能響應描述了一個可選命令時，
<capa-tag>應該和命令要害詞一樣。CAPA響應標記對大小寫敏感。
CAPA
參數：無
限制：無
討論：-ERR響應表明功能命令沒有實現，客戶端必須像以前一樣對功能進行探測。
-OK響應后面緊跟著的就是一個功能列表，一行一個功能。每個功能名后面可能都有一
個空格和由空格分隔的一個參數列表。每個功能行被限制在512八位組以內（包括CRLF在
內）。功能列表碰到包含一個終止八位組（“.”）和一個CRLF對時結束。
可能的響應：+OK–ERR
例子：
C:CAPA
S:+OKCapabilitylistfollows
S:TOP
S:USER
S:SASLCRAM-md5KERBEROS_V4
S:RESP-CODES
S:LOGIN-DELAY900
S:PIPELINING
S:EXPIRE60
S:UIDL
S:IMPLEMENTATIONShlemazle-Plotz-v302
S:.
6.功能的初始集合
這節定義了POP3功能的一個初始集合。這些包括可選POP3命令，已經發布的POP3擴
展，以及POP3服務器之間的行為差異，這種差異能夠影響到客戶端。
注重到沒有APOP功能，盡管APOP在[POP3]中是可選命令。客戶端通過包含在一個尖括
號（“<>”）里的初始驗證的問候語的存在與否來發現服務器對APOP的支持。因此，APOP功
能為服務器聲明同樣的事情引進了兩種方法。
6.1TOP功能
CAPA標記：TOP
參數：無
附加命令：TOP
影響的標準命令：無
聲明的狀態/可能的不同：兩者/沒有
命令有效的狀態：TRANSACTION
規范參考：[POP3]
討論：TOP功能表明TOP可選命令可用。
6.2.USER功能
CAPAtag:USER
參數：無
附加命令:USERPASS
受影響的標準命令:無
聲明的狀態/可能的不同：兩者/沒有
命令有效的狀態：AUTHENTICATION
規范參考：[POP3]
討論:USER功能表明支持USER和PASS命令，盡管它們可能不是對所有用戶都可用。
6.3.SASLcapability
CAPA標記:SASL
參數:支持的SASL機制
附加命令:AUTH
受影響的標準命令：無
聲明的狀態/可能的不同：兩者/沒有
命令有效的狀態：AUTHENTICATION
規范參考：[POP-AUTH,SASL]
討論:POP3AUTH命令[POP-AUTH]答應使用帶POP3的[SASL]的認證機制.SASL功能表明
AUTH命令可用，并且支持base64編碼的另一參數，此參數可選，是為初始的客戶端響應而
設的，如SASL里所述。SASL功能的參數是受支持的SASL機制列表，列表由空格分隔。
6.4.RESP-CODES功能
CAPA標記:RESP-CODES
參數:無
附加命令:無
受影響的標準命令:無
聲明的狀態/可能的不同:兩者/沒有
命令有效的狀態:n/a
規范參考:此文檔
討論:RESP-CODES性能表明任何由此服務器發送的響應文本，只要是由一個左方括號
（“[”]）開始的，它就是擴展響應編碼（參見第8節）。
6.5.LOGIN-DELAY功能
CAPA標記:LOGIN-DELAY
參數:多個登陸間的最小間隔秒數;AUTHENTICATION狀態下可以跟上USER。
附加命令:無
受影響的標準命令:USERPASSAPOPAUTH
聲明的狀態/可能的不同：兩者/有
命令有效的狀態:n/a
規范參考:此文檔
討論：POP3客戶經常登陸來檢查是否有新郵件。不幸的是，創建一個連接，驗證用戶，
以及打開用戶的郵箱非常消耗服務器的資源。許多POP3服務器試圖通過要求登陸之間有一
個延遲的方式來降低服務器負載。LOGIN-DELAY功能包括一個整型參數，它表示在一個對
PASS,APOP,或AUTH命令的“+OK”響應之后，接受另一個驗證之前，延遲的秒數。答應
用戶配置郵件檢查間隔的客戶端應該使用這個功能來確定答應的最小間隔。發布LOGIN-
DELAY的服務器應該強制此實現。
假如最小登陸延遲可以因用戶而異（就是說，LOGIN-DELAY參數在驗證之后可以改變），
服務器必須在AUTHENTICATION時設置用戶能夠配置的最大值。這可能是當前所有用戶使用
中的最大值（這樣的話每個服務器就只有一個值），或者是服務器答應為任意用戶設置的最
大值。服務器應該在AUTHENTICATION狀態下給LOGIN-DELAY參數附加“USER”標記，以通
知客戶端在驗證之后可以獲取一個更加精確的值。服務器應該在TRANSACTION下公布那個更
加精確的值。（“USER”標記答應客戶端決定是否需要另一個CAPA命令。）
服務器通過帶或不帶LOGIN-DELAY的出錯響應來拒絕驗證，這樣強制LOGIN-DELAY。參
見第8.1.1節獲取更多信息。
6.6PIPELINING功能
CAPA標記：PIPELINING
參數：無
附加命令：無
受影響的標準命令：全部
聲明的狀態/可能的不同:兩者/沒有
命令有效的狀態:n/a
規范參考:此文檔
討論：PIPELINING功能表明服務器能夠同時接收多個命令；客戶端在發送另一個命令
之前不需要等待前一個命令的響應。假如一個服務器支持PIPELINING，它必須輪流處理每
個命令。假如一個客戶端使用PIPELINING，它必須跟蹤它發送的命令，并將服務器響應按
順序和命令進行匹配。假如客戶端或服務器使用緩沖寫，它就不能超過下面轉輸層的窗口尺
寸。
某些POP3客戶端有一個選項來聲明服務器支持“重迭POP3命令”。此功能就去除了在
客戶端配置PIPELINING的必要性。
這和ESMTPPIPELINING大體上是同義的，但是，因為SMTP[SMTP]往往有較短的命令和
響應，在組合復合命令和將它們作為一個單元發送時很有好處。在POP中有這樣的情況（比
如，USER和PASS能分批處理，復合RETR和/或DELE命令能成組發送），因為POP擁有較短
的命令和某時過于冗長的響應，所以還有一個好處是，在還在接收早期命令響應時可以發送
新命令（比如，在處理一個UIDL響應時發送RETR和/或DELE命令）。
6.7EXPIRE功能
CAPA標記：EXPIRE
參數：服務器保證的最小保存期，或者是NEVER;在AUTHENTICATION狀態下可以跟上
USER。
附加命令：無
受影響的標準命令：無
聲明的狀態/可能的不同：兩者/有
命令有效的狀態：n/a
規范參考:此文檔
討論：盡管POP3答應客戶端在服務器上遺留消息，RFC1939[POP3]對這樣可能引起的
問題提出了警告，并且答應服務器在著站點策略的基礎上刪除消息。
EXPIRE功能通過答應服務器通知客戶端起作用的策略的方式，避免了RFC1939里提到
的問題。EXPIRE功能的參數表示服務器上的消息的最小保存期，以天計算。
EXPIRE0表明不答應客戶端在服務器上遺留郵件；當會話進入UPDATE狀態時，服務器
可以對每個用RETR下載的消息暗地執行一個DELE。
EXPIRENEVER聲明服務器不會刪除消息。
一個“保存期”的概念被有意弄得模糊。服務器可能設置一個截止期，當一條消息加到
郵箱時，當客戶端通過LIST或UIDL命令察覺到一條消息的存在時，當一條消息遵照某種方
式動作（比如TOP或者RETR）時，或者當一些其它事件發生時。EXPIRE功能不能提供關于
任何特定消息何時到期的精確表示。此功能的本意在于使客戶端更輕易地按一種符合站點策
略和用戶意愿的方式行事。例如，對任何試圖配置一個“遺留郵件在服務器上”期限，并且
此期限大于或等于服務器聲明值的某個比例時，客戶端就可能會顯示一個警告信息。
假如一個站點使用任何自動刪除策略，它就應該使用EXPIRE功能來聲明這一點。
EXPIRE功能，假如參數不是0或NEVER的話，就是用來使客戶端知道服務器答應郵件
遺留在服務器上，并向其展示一個有效的最小值。
答應用戶無限期遺留消息的站點應該用EXPIRENEVER聲明這一點。
假如超期策略因用戶而異的話（就是說，EXPIRE參數可能在驗證之后改變），服務器必
須在AUTHENTICATION時聲明能夠為任意用戶設置的最小值。這個值可能是當前所有用戶使
用中的最小值（這樣的話每個服務器就只有一個值），或者甚至是服務器答應為任意用戶設
置的最小值。服務器必須在AUTHENTICATION狀態下向EXPIRE的參數附加“USER”標記，以
通知客戶端在驗證之后可以獲取一個更精確的值。服務器應該在TRANSACTION狀態下聲明這
個更精確的值。（“USER”標記答應客戶端決定是否需要另外的CAPA命令）。
一個站點的消息超期策略可能根據已經執行的用戶動作或者其它因素對待消息。比如，
站點可能在60天后刪除未見過的消息，在15天后刪除完全或者部分見過的消息。
聲明的EXPIRE值是保存期的最小值，當前站點策略下的任何范疇或狀態，以及任何用
戶（在AUTHENTICATION狀態下）或特定用戶都適用此值。也即，EXPIRE告訴客戶端消息處
于所有環境下可以在服務器上停留的最小天數。

例：
EXPIRE5USER
EXPIRE30
EXPIRENEVER
EXPIRE0
第一個例子表明服務器在五天后刪除消息，但是這個期限因用戶而異，并且通過在
TRANSACTION狀態下發送另一個CAPA命令可以獲得一個更精確的值。第二個例子表明服務
器在30天后刪除消息。在第三個例子中，服務器聲明它將不刪除消息。第四個例子說明站
點不答應消息留在服務器上。
6.8UIDL功能
CAPA標記：UIDL
參數：無
附加命令：UIDL
受影響的標準命令：無
聲明的狀態/可能的不同：兩者/無
命令有效的狀態：TRANSACTION
規范參考:[POP3]
討論：UIDL功能表明支持可選UIDL命令。
6.9IMPLEMENTATION功能
CAPA標記：IMPLEMENTATION
參數：字符串，給服務器提供實現信息
附加命令：無
受影響的標準命令：無
聲明的狀態/可能的不同：兩者（或者只有TRANSACTION）/無
命令有效的狀態：n/a
規范參考:此文檔
討論：識別出特定服務器的實現（比如，在登陸時）經常是很有用的。通常使用歡迎標
記，但是必須猜測字符串是不是一個實現ID。
IMPLEMENTATION功能的參數由一個或更多的標志服務器的標記組成。（注重因為CAPA
響應標記參數用空格分隔，因此IMPLEMENTATION功能的參數不帶參數可能很方便，這樣的
話它就是一個單獨的標記了。）
一般地，服務器在兩種狀態下聲明IMPLEMENTATION。但是，某個服務器可能選擇只在
TRANSACTION狀態下聲明。
服務器可能在歡迎標記和IMPLEMENTATION功能中都包括有實現ID。
客戶端禁止更改它們基于服務器實現的行為。相反地，服務器和客戶端應該在私有擴展
上達成一致意見。
7.POP3的未來擴展
POP3的未來擴展大體來說是令人氣餒的，因為POP3的有效性是建立在它的簡潔性基礎
上的。POP3的本意是作為一個download-and-delete協議；郵件存取功能可以在IMAP
[IMAP4]中獲得。任何為附加郵箱提供支持，或者答應向服務器上傳消息，或者偏離了POP
的download-and-delete模型的擴展，都是非常令人氣餒的，因而不大可能被IETF標準批
準。
客戶端不能對基本的功能要求任何擴展，驗證命令(APOP,AUTH[6.3節]和USER/PASS)
是個例外。
第9節說明了附加功能是如何定義的。
8.擴展POP3響應碼
未擴展的POP3對大部分命令只能夠說明是成功或是失敗。不幸的是，客戶端經常需要
有關失敗原因的更多信息，以便適當地從中恢復。這在響應一個失敗的登陸時非凡重要(有
許多客戶端配置試圖解碼一個PASS命令結果的錯誤文本，以在“不能得到郵箱密碼”和“破
壞性登陸”之間區別)。
這一規范修定了POP3標準，使它答應一個可選的響應碼，此響應碼包含在方括號里面，
位于一個“+OK”或“-ERR”響應中的可讀部分的開始。支持這個擴展的客戶端能在向用戶
顯示可讀文本之前刪除方括號里面的信息。緊接著左方括號字符的是一個響應碼，它由客戶
端用一種大小寫不敏感的方式來進行解釋。
響應碼是分等級的，一個“／”分隔不同等級的錯誤細節。客戶端必須忽略不知道的關
于響應碼的等級細節。這一點很重要，因為它是在將來為響應碼提供更多細節的必要條件。
第3節用[ABNF]描述了響應碼。
假如一個服務器支持擴展的響應碼，它通過在CAPA響應中包含RESP-CODES的方式來
聲明。
例：
C:APOPmrosec4c9334bac560ecc979e58001b3e22fb
S:-ERR[IN-USE]DoyouhaveanotherPOPsessionrunning?
8．1初始化POP3響應碼
此規范定義了兩個用來確定登陸失敗原因的POP3響應碼.第9節說明了附加的響應碼
是如何定義的。
8．1．1LOGIN-DELAY響應碼
當AUTH,USER（見注重),PASSo或者APOP響應為一個-ERR時發生，表明用戶最近
登陸過，并且不答應再次登陸直到過了登陸延時期。
注重：對USER命令返回LOGIN-DELAY響應碼避免了驗證用戶，但是向用戶說明那個特
定的用戶已經存在。除非服務器正在工作的環境中，用戶名不是秘密的（比如，許多流行的
email客戶端在一個外發郵件頭里面公開POP服務器和用戶名），或者當服務器存取受到控
制，又或者當服務器能夠確認那個連接是同一個用戶的，此外服務器最好別對USER命令發
送此響應碼。服務器也保存打開郵箱的花費，在某些環境中這是最費時的步驟。
8．1．2IN-USE響應碼
AUTH,APOP,或者PASS的響應為-ERR時發生。它表明驗證成功，但是用戶的郵箱目前
正在使用中（可能是另一個POP3客戶端）。
9．IANA考慮
此文檔要求IANA維持兩個新的注冊項：POP3功能和POP3響應碼。
新的POP3功能必須使用標準格式或IESG批準實驗性RFC，并且不能以字母“X”開頭。
新的POP3功能必須包含以下信息：
CAPA標記
參數
附加命令
受影響的標準命令
聲明的狀態/可能的不同
命令有效的狀態
規范參考
討論
另外，POP3命令和響應的新的長度限制可能需要包括在內。
新的POP3響應碼必須在一個RFC或者其它的永久的、輕易獲得的參考中定義，并且細
節要足夠具體，這樣相互獨立的實現間的相互協作才有可能。（這是在[IANA]里面描述的“規
范要求”策略）。
新的POP3響應碼說明必須包含以下信息：完整的響應碼，對哪個響應（+OK或-ERR）
或命令有效，以及它的意義和期望的客戶端行為的定義。
10.安全考慮
一個功能列表能反映關于服務器驗證機制的信息，此機制用來確定某些攻擊是否會成
功。但是，答應客戶端自動檢測更健壯的機制的可獲取性，答應客戶端使用它們的同時改變
它們的配置，這些措施能夠全面改善一個站點的安全性。
8.1節討論了對USER命令使用的LOGIN-DELAY響應碼的安全問題。
11.致謝
這篇文檔的部分修改有賴于IETFPOP3擴展郵件列表上及其之外的評論和討論。感謝花
時間評論此文檔和提供建議的人們的幫助，非凡是AlexeyMelnikov,HaraldAlvestrand,
和MikeGahrns。
12.參考文獻
[ABNF]Crocker,D.andP.Overell,"AugmentedBNFforSyntax
Specifications:ABNF",RFC2234,November1997.
[IANA]Narten,T.andH.Alvestrand,"GuidelinesforWritingan
IANAConsiderationsSectioninRFCs",BCP26,RFC2434,
October1998.
[IMAP4]Crispin,M.,"InternetMessageaccessPRotocol--
Version4rev1",RFC2060,December1996.
[KEYWORDS]Bradner,S.,"KeywordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.
[PIPELINING]Freed,N.,"SMTPServiceExtensionforCommand
Pipelining",RFC2197,September1997.
[POP3]Myers,J.andM.Rose,"PostOfficeProtocol--Version
3",STD53,RFC1939,May1996.
[POP-AUTH]Myers,J.,"POP3AUTHenticationcommand",RFC1734,
December1994.
[SASL]Myers,J.,"SimpleAuthenticationandSecurityLayer
(SASL)",RFC2222,October1997.
[SMTP]Postel,J.,"SimpleMailTransferProtocol",STD10,RFC
821,August1982.
13.作者地址
RandallGellens
QUALCOMMIncorporated
6455LuskBlvd.
SanDiego,CA92121-2779
USA
Phone:+16196515115
Fax:+16198457268
EMail:randy@qualcomm.com

ChrisNewman
InnosoftInternational,Inc.
1050LakesDrive
WestCovina,CA91790
USA
EMail:chris.newman@innosoft.com
LaurenceLundblade
QUALCOMMIncorporated
6455LuskBlvd.
SanDiego,Ca,92121-2779
USA
Phone:+16196583584
Fax:+16198457268
EMail:lgl@qualcomm.com
14.完整版權說明
Copyright(C)TheInternetSociety(1998).AllRightsReserved.
Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany

kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsUChcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurpoSEOf
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.
Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.
Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.