Đồ án web server mailing list và mail system nhằm xây dựng IM hoàn chỉnh - 3 doc

<local-part> ::= <dot-string> | <quoted-string>
<name> ::= <a> <ldh-str> <let-dig>
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig> ::= <a> | <d>
<let-dig-hyp> ::= <a> | <d> | "-"
<dot-string> ::= <string> | <string> "." <dot-string>
<string> ::= <char> | <char> <string>
<quoted-string> ::= """ <qtext> """
<qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
<char> ::= <c> | "\" <x>
<dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
<number> ::= <d> | <d> <number>
<CRLF> ::= <CR> <LF>
<CR> ::= the carriage return character (ASCII code 13)
<LF> ::= the line feed character (ASCII code 10)
<SP> ::= the space character (ASCII code 32)
<snum> ::= one, two, or three digits representing a decimal
integer value in the range 0 through 255
<a> ::= any one of the 52 alphabetic characters A through Z
in upper case and a through z in lower case
<c> ::= any one of the 128 ASCII characters, but not any
<special> or <SP>
<d> ::= any one of the ten digits 0 through 9
<q> ::= any one of the 128 ASCII characters except <CR>,
<LF>, quote ("), or backslash (\)
<x> ::= any one of the 128 ASCII characters (no exceptions)
<special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
| "," | ";" | ":" | "@" """ | the control characters (ASCII
codes 0 through 31 inclusive and 127)
Chú ý dấu suyệt ngược “\” là một ký tự định đặt, nó được dùng chỉ định ký tự kế
tiếp được dùng một cách chính xác (thay cho sự thông dịch thông thường của nó) ví

dụ như "Khanh\,Sam" sẽ được dùng chỉ định một ký tự một trường chín tự đơn với
dấu phẩy là ký tự thứ sáu của trường.
Thường những host được biết đến bằng những cái tên, nó được biên dịch thành địa
chỉ của mỗi host. Lưu ý tên phần tử của các Domain phải là tên chính thức, không
dùng tên hiệu hay bí danh.
Thỉnh thoảng một host không biết đến chức năng biên dịch và sự giao tiếp bị khoá.
Để phớt lờ chướng ngại này hai cấu trúc dạng số cũng được chấp nhận cho “names”
của host. Một dạng là một số nguyên hệ thập phân nằm sau ký hiệu giới hạn “#” nó
chỉ định số này là địa chỉ của host. Một dạng khác là bốn số nguyên nhỏ bao trong
dấu ngoặc vuông và cách nhau bởi những dấu chấm như "[123.255.37.2]". Nó chỉ
định một địa chỉ 32 bit- ARPA internet trong bốn trường 8 bit.
Dòng đánh dấu thời gian và dòng đường dẫn trở về thường được định nghĩa như ví
dụ sau :
<return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF>
<time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF>
<stamp> ::= <from-domain> <by-domain> <opt-info> ";"
<daytime>
<from-domain> ::= "FROM" <SP> <domain> <SP>
<by-domain> ::= "BY" <SP> <domain> <SP>
<opt-info> ::= [<via>] [<with>] [<id>] [<for>]
<via> ::= "VIA" <SP> <link> <SP>
<with> ::= "WITH" <SP> <protocol> <SP>
<id> ::= "ID" <SP> <string> <SP>
<for> ::= "FOR" <SP> <path> <SP>
<link> ::= The standard names for links are registered with the Network
Information Center ( Tên chuẩn cho những liên kết được đăng ký với Net Work
Information Center)
<protocol> ::= The standard names for protocols are registered with the
Network Information Center. (Tên chuẩn cho những protocol được đăng ký với Net
Work Information Center)

<daytime> ::= <SP> <date> <SP> <time>
<date> ::= <dd> <SP> <mon> <SP> <yy>
<time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
<dd> ::= the one or two decimal integer day of the month in
the range 1 to 31.
<mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
"JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
<yy> ::= the two decimal integer year of the century in the range 00 to 99.
<hh> ::= the two decimal integer hour of the day in the range 00 to 24.
<mm> ::= the two decimal integer minute of the hour in the range 00 to 59.
<ss> ::= the two decimal integer second of the minute in the range 00 to 59.
<zone> ::= "UT" for Universal Time (the default) or other time zone
designator (as in [2]).
Ví dụ : Return Path
Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:>
Ví dụ : dòng đánh dấu thời gian :
Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT
Một reply SMTP bao gồm một số ba chữ số (được truyền như ba ký tự chữ số) theo
sau là một số văn bản (text). Số đó được dành cho các chương trình tự động để xác
định trạng thái đưa vào kế tiếp. Text ở trên có ý nghĩa cho user con người (không
phải máy). Ba chữ số đó được ấn định chứa đầy đủ thông tin được mã hoá Sender-
SMTP không cần kiểm tra text đó và có thể huỷ bỏ hay chuyển nó qua một user
thích hợp. Đặc biệt text này có thể độc lập với Receiver-SMTP và độc lập với ngữ
cảnh, do có sự giống nhau trong những text khác nhau từng mã reply. Nguyên lý
của những mã reply cho trong phụ lục E. thông thường một reply được định nghĩa
là chuổi gồm: một mã ba chữ số, <SP>, một dòng text, và <CRLF>, hay một reply
nhiều dòng (như định nghĩa trong phụ lục E) chỉ những lệnh EXPN và HELP có
kết quả là những reply nhiều dòng trong những tình huống bình thường, tuy nhiên
những reply nhiều dòng được chấp nhận cho nhiều lệnh.
1. Những mã Reply cho một nhóm các chức năng:

500 Lỗi cú pháp, không chấp nhập lệnh
[nó có thể bao gồm những lỗi như: lệnh quá dài]
501 Lỗi cú pháp trong những đối số hay những tham số
lệnh không được cung cấp
dòng lệnh sai
tham số của lệnh không được cung cấp
Trạng thái hệ thống, hay trả lời giúp đỡ về hệ thống
214 Message giúp đỡ
[thông tin về làm thế nào để dùng receiver hay ý nghĩa của
một lệnh không chuẩn đặc biệt ; reply này rất có ích cho người
sử dụng]
220 <domain> dịch vụ sẳn sàng
221 <domain> dịch vụ đóng kênh giao chuyển
421 <domain> dịch vụ không dùng được, đóng kênh giao chuyển
[nó có thể là một reply cho nhiều lệnh nếu dịch vụ đó biết
reply này phải shut down]
250 Hành dộng mail yêu cầu ok, hoàn thành
251 User không cục bộ, sẽ hướng đến “forward-path”
450 Không lấy hành động mail yêu cầu: mailbox không có hiệu lực
[chẳng hạn như mailbox không tìm thấy, không truy xuất được]
451 Bỏ qua hành động được yêu cầu; lỗi trong quá trình xử lý
551 User không cục bộ, vui lòng thử lại <forward-path>
452 Không nhận hành động được yêu cầu : lưu trữ của hệ thống
không đủ
552 Bỏ qua hành động mail yêu cầu: vượt quá chỉ định lưu trữ
553 Không nhận hành động được yêu cầu : không chấp nhận tên
mailbox [như sai cú pháp mailbox].
554 Khởi động việc nhận mail; kết thúc với <CLRF>.<CLRF> giao
chuyển bị sai.
2. Thứ tự của danh sách những mã Reply số :

211 Tình trạng hệ thống, hay reply giúp đỡ hệ thống.
214 Message giúp đỡ. Thông tin làm thế nào để dùng receiver hay
ý nghĩa của một lệnh không chuẩn đặc biệt ; reply này rất có
ích cho user.
220 <domain> dịch vụ sẳn sàng
221 <domain> dịch vụ đóng kênh giao chuyển
250 Hành động mail yêu cầu OK, hoàn thành
251 User không cục bộ; sẽ hướng đến <forward-path>
354 Khởi động việc nhập mail; kết thúc với <CLRF>. <CLRF>
421 <domain> dịch vụ không sử dụng được, đóng kênh giao
chuyển {nó có thể là một reply cho nhiều lệnh nếu dịch vụ đó
biết reply này phải shut down]
450 Không lấy hành động mail yêu cầu; mailbox không hiệu lực
[như mailbox bận]
450 Bỏ qua hành động được yêu cầu ; lỗi cục bộ trong quá trình
xử lý
451 Không nhận hành động được yêu cầu; lưu trữ của hệ thống
không đủ.
500 Lỗi cú pháp; không chấp nhận lệnh
[nó có thể bao gồm những lỗi như: lệnh quá dài]
501 Lỗi cú pháp trong tham số hay đối số
502 Lệnh không được cung cấp
503 Dòng lệnh sai
504 Tham số của dòng lệnh không được cung cấp
550 Không nhận hành động được yêu cầu ; mailbox không hiệu lực
[như mailbox không tìm thấy hay không truy cập được]
551 User không cục bộ; vui lòng thử <forward-path>
552 Bỏ qua hành động mà mail yêu cầu, vượt quá chỉ định lưu trữ
554 Không nhận hành động được yêu cầu; tên mailbox không được
chấp nhận. [như sai cú pháp mailbox] giao chuyển sai.

3. Sự liên tục của những Command & Reply :
Sự giao tiếp giữa Sender-SMTP và Receiver-SMTP được chỉ định là một cuộc hội
thoại tuần tự do Sender-SMTP điều khiển. Chẳng hạn như Sender-SMTP sinh ra
một lệnh và Receiver-SMTP trả lời với một reply. Sender-SMTP phải chờ sự trả lời
này trước khi gửi thêm lệnh.
Một reply quan trọng là chào hỏi kết nối. Thông thường một Receiver-SMTP sẽ gửi
một reply 220 “service ready” khi kết nối hoàn thành. Sender-SMTP phải chờ
message chào hỏi này trước khi gửi các lệnh.
Lưu ý: tất cả các reply kiểu chào hỏi dùng tên chính thức của host server là từ đầu
tiên theo sau mã reply
Ví dụ : 220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF>
Bảng bên dưới liệt kê những reply thành công và thất bại cho mỗi lệnh nó phải được
gia nhập vào một cách nghiêm ngặt để một Receiver-SMTP có thể thay thế text
trong các reply nhưng ý nghĩa và hành động được định bởi mã số và bởi chuỗi
command reply đặc trưng không thể bị thay đổi.
*- Những chuỗi COMMAND-REPLY
Mỗi lệnh được liệt kê với các reply có thể của nó. Những tiền tố được dùng trước
những reply có thể là “P” để khởi đầu (không dùng trong SMTP) “I” cho phần giữa,
“S” cho sự thành công và “E” cho lỗi. Reply 421 (dịch vụ không hiệu lực, đóng
kênh giao chuyển) có thể cho một số lệnh nếu receiver-SMTP nhận biết rằng nó
phải shut down. Sự liệt kê sau đây là cấu trúc cơ bản cho sơ đồ trạng thái (state
diagram) trong phần B.
CONNECTION ESTABLISHMENT (thiết lập kết nối)
S: 220
F: 421
HELLO
S: 250
E: 500, 501, 504, 421
MAIL
S: 250

F: 552, 451, 452
E: 500, 501, 421
RCPT
S: 250, 251
F: 550, 551, 552, 553, 450, 451, 452
E: 500, 501, 503, 421
DATA
I: 354 -> data -> S: 250
F: 552, 554, 451, 452
F: 451, 554
E: 500, 501, 503, 421
RSET
S: 250
E: 500, 501, 504, 421
SEND
S: 250
F: 552, 451, 452
E: 500, 501, 502, 421
SOML
S: 250
F: 552, 451, 452
E: 500, 501, 502, 421
SAML
S: 250
F: 552, 451, 452
E: 500, 501, 502, 421
VRFY
S: 250, 251
F: 550, 551, 553
E: 500, 501, 502, 504, 421

EXPN
S: 250
F: 550
E: 500, 501, 502, 504, 421
HELP
S: 211, 214
E: 500, 501, 502, 504, 421
NOOP
S: 250
E: 500, 421
QUIT
S: 221
E: 500
TURN
S: 250
F: 502
E: 500, 503
B- Sơ đồ trạng thái (STATE DIAGRAM)
Dưới đây là sơ đồ trạng thái cho một sự thi hành SMTP đơn giản. Chỉ một chữ số
đầu tiên của những mã reply được sử dụng . Đây là một bảng trạng thái cho từng
nhóm lệnh SMTP những nhóm lệnh này được xác định bằng cách xây dựng một mô
hình cho mỗi lệnh và sau đó gom những lệnh đó lại với nhau với những mô hình
giống nhau về cấu trúc.
Cho mỗi lệnh có ba kết quả “thành công” (S), “thất bại” (F), “lỗi” (E) trong sơ đồ
trạng thái sau chúng ta dùng ký hiệu B cho “begin” và ký hiệu W cho “wait for
reply”.
Đầu tiên sơ đồ trình bày cho hầu hết các lệnh SMTP :
Sơ đồ này mô hình cho những lệnh sau:
HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP,
NOOP, QUIT, TURN

Một sơ đồ phức tạp hơn mô hình cho lệnh DATA :
Lưu ý: “data” ở đây là một chuỗi những dòng gửi từ Sender-SMTP đến Receiver-
SMTP không cần sự trả lời cho đến khi dòng cuối cùng được gửi.
C- Chi tiết
1. Sự thực thi tối thiểu :
Hợp lệ để làm cho SMTP có thể làm việc, sự thực thi tối thiểu sau được yêu cầu cho
tất cả các Receiver-SMTP
COMMANDS HELO
MAIL
RCPT
DATA
RSET
NOOP
QUIT
2. Tính trong suốt :
Không có một sự cung cấp nào cho tính trong suốt dữ liệu, chuổi ký tự
<CRLF>.<CRLF> kết thúc mail text và không được user gửi đi. Thông thường user
không nhận biết được sự “ngăn cản” những chuổi ký tự đó. Để cho phép tất cả các
text đã soạn thảo của user được truyền một cách rõ ràng những thủ tục sau đây được
sử dụng.
1> Trước khi gửi một dòng dữ liệu mail, Sender-SMTP kiểm tra ký tự đầu tiên của
dòng đó. Nếu nó là một dấu chấm, một dấu chấm phụ được thêm vào đầu dòng.
2> Khi Receiver-SMTP nhận một dòng dữ liệu mail nó kiểm tra dòng đó. Nếu dòng
đó chỉ có một dấu chấm đơn thì nó là kết thúc của mail. Nếu ký tự đầu tiên là một
dấu chấm và theo sau là những ký tự khác nằm trên cùng dòng. Thì ký tự đầu tiên
đó bị xoá.
Mail data có thể chứa các ký tự mã ASCII (128 ký tự) tất cả các ký tự được phân
phát đến mailbox của người nhận bao gồm phần định dạng và những ký tự điều
khiển khác. Nếu kênh chuyển giao cung cấp một luồng dữ liệu 8 bit (octet), những
mã ASCII 7 bit trên được vận chuyển đúng điều chỉnh lại trong hệ bát phân với bit

cao nhất bị xoá về 0.
Nó có thể cần thiết để biến đổi dữ liệu được nhận hay lưu trữ . Trong một số hệ
thống, điều này cần thiết cho những host dùng một tập hợp ký tự khác với tập
ASCII , như tập ký tự cục bộ của chúng hay dữ liệu lưu trong những bảng ghi nhiều
hơn chuổi. Nếu những thay đổi trên là cần thiết, chúng phải khôi phục lại (biến đổi
hai chiều) được nếu những biến đổi đó được áp dụng cho mail được chia ca.
3. Kích thước :
Có vài đối tượng đòi hỏi kích thước nhỏ nhất lớn nhất. Đó là tất cả tất cả sự thực thi
phải có để nhận những đối tượng có kích thước tối thiểu, nhưng không bắt buộc
phải gửi những đối tượng lớn hơn kích thước này
user : Chiều dài tổng cộng lớn nhất của user name là 64 ký tự.
domain : Chiều dài tổng cộng lớn nhất của domain name hay số là 64 ký tự.
path : Chiều dài tổng cộng lớn nhất của một dòng lệnh bao gồm những từ lệnh và
<CRLF> là 512 ký tự.
text line (dòng văn bản) : Chiều dài tổng cộng lớn nhất của dòng văn bản bao gồm
<CRLF> là 1000 ký tự (không tính dấu chấm ở đầu được nhân lên cho vấn đề trong
suốt).
recipients buffer : Tổng số recipient lớn nhất là 100 recipient.
* Lỗi vượt quá quyền được giới hạn có thể được báo cáo bằng cách dùng những
mã reply. Ví dụ như :
500 Line too long.(dòng quá dài)
501 Path too long (đường dẫn quá dài)
552 Too many recipients.(quá nhiều recipient)
552 Too much mail data (quá nhiều mail data)
PHỤ LỤC
A. Dịch vụ vận chuyển TCP
Transmission Control Protocol (điều khiển giao chuyển [3]) được dùng trong
ARPA Internet và trong một số mạng theo tiêu chuẩn US DoD cho các giao thức
liên mạng .
* Thiết lập kết nối :

Một kênh giao chuyển SMTP là một kết nối được thiết lập the người gửi
process port U and the receiver process port L. nó là một kết nối full duplex đơn
giản được dùng như kênh kết nối trên protocol này được gán một dịch vụ port 25
(31 hệ mười) đó là L=25.
* Truyền dữ liệu :
Kết nối TCP hổ trợ truyền những byte 8 bit. Dữ liệu SMTP là những ký tự 7
bit mã ASCII. Mỗi ký tự được truyền như một byte 8 bit với bit cao nhất bị xoá về
0.

B. Dịch vụ vận chuyển NCP
ARPANET Host-to-Host Protocol [4] (được cung cấp bởi Network Control
Program) có thể được dùng trong ARPANET .
* Thiết lập kết nối :
Kênh giao chuyển SMTP được thiết lập qua NCP giữa người gửi process
socket U và receiver process socket L. The Initial Connection Protocol [5] là kết
quả là kết quả tiếp theo một cặp kết nối simplex. Cặp kết nối này được dùng như
kênh giao chuyển . protocol này được gán toàn bộ socket 25 , đó là L=25.
* Truyền dữ liệu:
Kết nối NCP data được thiết lập trong chế độ 8 bit. SMTP data là những ký tự
ASCII 7 bit . Mỗi ký tự được truyền như một byte 8 bit với bit cao nhất bị xoá về 0.
C. NTTS
Network Independent Transport Service [6] (dịch vụ vận chuyển mạng độc lập) có
thể được dùng .
* Thiết lập kết nối :
Kênh giao chuyển SMTP được thiết lập qua NTTS sender process và receiver
process. Sender process thi hành CONNECT ban đầu và chờ receiver process thực
thi ACCEPT ban đầu .
* Truyền dữ liệu :
Kết nối NTTS hổ trợ giao chuyển các byte 8 bit . SMTP data là những ký tự ASCII
7 bit . Mỗi ký tự được truyền như một byte 8 bit với bit cao nhất bị xoá về 0.

D. Dịch vụ vận chuyển X.25
Nó có thể dùng X.25 service [7] cung cấp bởi Public Data Networks một cách trực
tiếp , tuy nhiên nó được đề nghị một protocol đáng tin cậy chẳng hạn như TCP được
dùng ở trên kết nối X.25.
E. Nguyên lý của các mã Reply
Ba chữ số của mã reply mỗi chữ có một ý nghĩa đặc biệt. Ký tự đầu tiên biểu thị
response, good hay bad hay không hoàn tất. Một sender-SMTP thật sẽ có thể xác
nhận hành động kế tiếp của nó (tiến hành theo kế hoạch, làm lại, cắt giảm bớt, )
bằng một cách đơn giản là kiểm tra chữ số đầu tiên này. Một Sender-SMTP muốn
biết một cách gần đúng các kiểu lỗi xảy ra (như mail system error, command syntax
error) có thể kiểm tra chữ số thứ hai, để dành chữ số thứ ba cho việc kết thúc sự sắp
đặt tăng dần của thông tin.
* Có năm giá trị cho chữ số đầu tiên của mã reply:
1yz Positive Preliminary reply (reply khẳng định ban đầu ) :
Lệnh này được chấp nhận nhưng hành động yêu cầu sẽ được giữ hoãn lại, trì
hoãn sự xác nhận thông tin trong reply này. Sender-SMTP sẽ gữi một lệnh khác
định rõ tiếp tục hay bỏ qua hành động này.
[ Lưu ý: SMTP không có lệnh nào thừa nhận kiểu reply này, vàdo đó không có lệnh
tiếp tục hay bỏ qua].
2yz Positive Completion reply (reply khẳng định sự hoàn thành) :
Hành động được yêu cầu hoàn tất một cách thành công, một yêu cầu mới có thể
được bắt đầu .
3yz Positive Intermediate reply (reply khẳng định giữa chừng) :
Lệnh này được chấp nhận nhưng hành động yêu cầu sẽ được giữ hoãn lại, trì hoãn
sự nhận thông tin thêm. Sender-SMTP sẽ gữi một lệnh khác định rõ thông tin này.
Reply này được dùng trong những nhóm lệnh tuần tự.
4yz Transient Negative Completion reply (reply phủ định sự hoàn thành ngắn hạn):
Lệnh này không được chấp nhận và hành động yêu cầu không xảy ra, tuy nhiên
trạng thái lỗi là tạm thời, hành động có thể được yêu cầu trở lại. Người gửi sẽ quay
trở lại bắt đầu chuổi lệnh (nếu có) khó gán một nghĩa “tức thời” cho nó khi hai site

khác nhau (Receiver và sender-SMTPs) phải đồng ý sự thông dịch. Mỗi reply loại
này có một giá trị thời gian khác nhau nhưng Sender-SMTP được khuyến khích thử
lại. Một quy tắc lật trang để xác định nếu một reply đặc vào trong loại 4yz hay 5yz
(xem bên dưới) thì những reply đó là 4yz nếu chúng có thể được lặp lại mà không
cần thay đổi gì trong cấu trúc lệnh hay trong những thuộc tính của người gửi hay
người nhận (như một lệnh được lặp lại một cách giống nhau và Receiver –SMTP
không đưa ra một sự thực thi mới).
5yz Permanent Negative Completion reply (reply phủ định sự hoàn thành dài hạn):
Lệnh này không được chấp nhận và hành động được yêu cầu không xảy ra .
Sender-SMTP ngăn cản việc lặp lại yêu cầu (trong chuổi tuần tự đó). Ngay cả một
số hoàn cảnh lỗi “dài hạn” có thể hiệu chỉnh được, do đó user muốn hướng
Sender-SMTP khởi tạo lại chuổi lệnh đó bằng cách chỉ đạo hành động tại một số
thời điểm trong tương lai(như: sau khi chính tả đã được thay đổi, hay user đó thay
đổi trạng thái account ) .
a/ Chữ số thứ hai mã hoá những loại trả lời(response) đặc trưng :
* x0z Syntax : Những reply này xem xét lỗi cú pháp, những lệnh đúng cú pháp
không đưa vào một loại chức năng nào. Và không thực thi các lệnh không cần thiết.
* x1z Information : Những reply này để yêu cầu thông tin, như trạng thái hay
giúp đỡ.
* x2z Connections : Những reply này tham khảo đến kênh giao chuyển.
* x3z : Cho đến hiện tại chưa được đặc tả.
* x4z : Cho đến hiện tại chưa được đặc tả.
* x5z Mail system : Reply này chỉ định tình trạng của receiver mail system vis-
a-vis yêu cầu truyền hay hoạt động hệ thống mail khác .
b/ Chữ số thứ ba mang lại một mức độ ý nghĩa nhiều hơn cho mỗi loại (category)
Được đặc tả bởi chữ số thứ hai. Danh sách các reply minh hoạ điều này. Mỗi reply
text được đề nghị nhiều hơn là lệnh, và có thể thay đổi tuỳ theo lệnh với những kết
hợp của lệnh đó. Trong sự kiểm soát khác những mã reply này phải theo sự đặc tả
nghiêm ngặt trong phần này sự thực thi của người nhận sẽ không phát sinh ra mã
mới cho tình trạng khác nhau không đáng kể của những gì được đặc tả ở đây.

Nhưng những mã thích hợp hơn đã được định nghĩa sẳn.
Ví dụ như, một lệnh như NOOP chẳng hạn nó thực thi thành công không cần đề
nghị Sender-SMTP một thông tin mới nào sẽ trả về một reply 250. Câu trả lời là
502 khi lệnh yêu cầu một hành động non-site-specific không thực thi được. Một sự
cải tiến cho điều đó là reply 504 cho một lệnh được thực thi nhưng nó yêu cầu một
tham số không thực thi.
Reply text có thể dài hơn một dòng đơn, trong trường hợp này một text hoàn tất
phải được đánh dấu do đó người gửi biết khi nào nó có thể ngưng đọc reply này.
Điều này đòi hỏi một định dạng để chỉ định một reply nhiều dòng.
Định dạng cho các reply nhiều dòng quy định tất cả các dòng, chấp nhận chổ cuối
cùng và bắt đầu của mã reply, theo sau đó là một dấu gạch nối “-” (dấu trừ) theo sau
là text dòng cuối cùng sẽ bắt đầu với mã reply theo ngay sau đó là <SP> , các text
và <CRLF>.
Cho ví dụ:
123-First line
123-Second line
123-234 text beginning with numbers
123 The last line
Trong một số trường hợp Sender-SMTP cần tìm mã reply theo sau là <SP> ở đầu
dòng, và phớt lờ tất cả các dòng trước. Một ít trường hợp có dữ liệu quan trọng cho
người gửi trong reply “text” người gửi sẽ nhận biết trường hợp này từ ngữ cảnh hiện
hành.
PHẦN 2 GIAO THỨC POP3 (POST OFFICE PROTOCOL VERSION 3)
I . GIỚI THIỆU:
Nghi thức POP3 được cải tiến từ nghi thức POP ( Post Office Protocol ).
Trên internet một loại nào đó nhỏ hơn node thường không thực tế để duy trì một hệ
thống vận chuyển message (Message Transport System: MTS), ví dụ như một
workstation không có đủ tài nguyên (recycle, disk space) hợp lệ để cho phép một
SMTP server và một hệ thống phân phát mail cục bộ kết hợp giữ thường trú và
chạy một cách liên tục . Thường thì nó có thể rất đắt (hay không thích hợp) để giữ

một personal computer nối với một IP-style network trong một thời gian dài (node
đó được biết sẽ thiếu tài nguyên như “connectivity”) .
Mặc dù vậy, để có thể quản lý mail rất hữu hiệu trên những node nhỏ hơn này. Và
chúng thường hổ trợ một User Agent (UA) để giúp đỡ công việc điều khiển mail.
Để giải quyết vấn đề một node có thể cung cấp một thực thể MTS đưa ra một
maildrop service đến những node được cấp nhỏ hơn này. Post Office Protocol -
Version 3 (POP3) được dùng cho phép một workstation truy xuất động đến một
maildrop trên một server host. Thường điều đó có nghĩa là POP3 được dùng để
chấp nhận một workstation gọi mail được server đang giữ cho nó.
Khi một user agent trên một client host mong muốn đưa một message vào trong hệ
thống vận chuyển, nó thiết lập một kết nối SMTP đến host chia ca của nó( host chia
ca này có thể, hay không cần POP3 server host cho client host đó).
II. THAO TÁC CƠ BẢN
Ban đầu server host bắt đầu một POP3 service bằng cách lắng nghe trên TCP port
110. Khi một client host mong muốn dùng POP3 service, nó thiết lập một kết nối
TCP với server host đó. Khi kết nối được thiết lập, POP3 server gửi một chào hỏi.
Client và server POP3 sau đó trao đổi những lệnh và các trả lời cho đến khi kết nối
đó được đóng hay loại bỏ.
Lệnh trong POP3 bao gồm một từ khoá (keyword) theo sau có thể là một hay
nhiều đối số tất cả các lệnh được kết thúc bởi một cặp CRLF. Các từ khoá và đối số
được tách riêng ra bởi một ký tự trắng đơn , từ khoá dài 3 hay 4 ký tự. Mỗi đối số
có thể lên đến chiều dài 40 ký tự.
Các trả lời trong POP3 bao gồm phần chỉ định trạng thái và một từ khoá có thể theo
sau là thông tin thêm vào. Tất cả các trả lời được kết thúc bởi một cặp CRLF. Chỉ
có hai loại trả lời là: chỉ định trạng thái khẳng định (“+OK”) và phủ định (“-
ERR”) .

Trả lời cho các lệnh là trả lời nhiều dòng. Trong trường hợp này, nó cho phép chỉ
định một cách rõ ràng, sau khi gửi dòng đầu tiên của câu trả lời và một CRLF, một
số dòng thêm vào được gửi đi, mỗi dòng kết thúc bằng một cặp CRLF. Khi tất cả

các dòng của trả lời đã được gửi đi bao gồm một số kết thúc hệ bát phân
(termination octe) (mã 046 hệ mười, “.” ) và một cặp CRLF. Nếu dòng nào của trả
lời nhiều dòng bắt đầu với termination octet dòng đó là "byte-stuffed" bằng cách
(pre-pending) treo termination octet đó của dòng trả lời. Kể từ đây một trả lời nhiều
dòng được kết thúc với năm octet "CRLF.CRLF". Khi xem xét một trả lời nhiều
dòng client kiểm tra xem nếu dòng đó bắt đầu với termintion octet. Nếu đúng và
nếu những octet theo sau khác với CRLF, octet đầu tiên của dòng này (termination
octet) được bỏ đi. Nếu đúng và nếu những ký tự kết thúc theo ngay sau nó, thì trả
lời từ POP3 server này được kết thúc với một dòng chứa “.CRLF” không được coi
là một phần của trả lời nhiều dòng đó.
Một phiên POP3 tiến hành qua một số trạng thái trong thời gian sống của nó. Khi
kết nối TCP được mở và một POP3 server gửi một chào hỏi. Hội nghị sẽ đi vào
trạng thái xác nhận (AUTHORIZATION). Trong trạng thái này client phải định
danh nó đến POP3 server. Khi client định danh thành công, server thu được những
tài nguyên kết hợp với maildrop của client, và hội nghị đi vào trạng thái giao dịch
(TRANSACTION). Trong trạng thái này client yêu cầu các hành động trong vai trò
của POP3 server khi client phát ra lệnh QUIT, hội nghị đi vào trạng thái cập nhật
(UPDATE). Trong trạng thái này giải phóng các tài nguyên thu nhận được trong
trạng thái giao dịch và nói goodbye. Sau đó kết nối TCP đóng lại.
Một POP3 server có thể có một khoảng thời gian tự động logout không chủ động.
Và nó phải tồn tại trong khoảng thời gian ít nhất là 10 phút. Trong khoản thời gian
nhận các lệnh từ client đủ để reset khoảng thời gian tự động logout đó. Đến khi hết
hiệu lực, hội nghị không đi vào trạng thái UPDATE, server sẽ đóng kết nối TCP mà
không remove hay gửi một message nào cho client.
III. TRẠNG THÁI XÁC NHẬN (Authorization State)
Khi kết nối TCP được mở ra bởi một cleint. POP3 server sẽ xuất ra một dòng chào
hỏi nó có thể là một chuổi nào đó được kết thúc bởi CRLF.
Ví dụ :
S: +OK POP3 server ready
Chào hỏi đó là một POP3 reply. POP3 server bao giờ cũng sẽ truyền đi một trả lời

khẳng định như chào hỏi trên.
Phiên POP3 hiện nằm trong trạng thái AUTHORIZATION. Client phải định danh
và xác nhận nó với POP3 server. Có hai cơ chế thích hợp để thực hiện. Sự kết hợp
lệnh USER và PASS , và lệnh APOP.
Để xác nhận dùng sự kết hợp lệnh USER và PASS. Đầu tiên client phải phát một
lệnh USER, nếu POP3 server trả lời với một chỉ thị trạng thái khẳng định (“+OK”),
thì client có thể phát đi lệnh PASS để hoàn tất sự xác nhận hay lệnh QUIT để kết
thúc POP3 session. Nếu POP3 server trả lời với một chỉ thị trạng thái phủ nhận (“-
ERR”) cho lệnh USER, thì client có thể phát ra một lệnh xác nhận mới hay có thể
phát một lệnh QUIT.
Khi client phát ra một lệnh PASS, POP3 server dùng cặp đối số từ lệnh USER và
PASS để xác định nếu client sẽ được cho truy xuất đến maildrop thích hợp.
Khi POP3 server đã được xác định bằng các lệnh xác nhận, nó cho client truy xuất
đến những mailbox thích hợp, sau đó POP3 server thu được một khoá truy xuất loại
trừ trên maildrop, vì sự cần thiết để ngăn chặn message bị sửa đổi hay bị loại bỏ
trước khi hội nghị đi vào trạng thái UPDATE. Nếu thu nhận khoá thành công POP3
server trả lời với một chỉ định trạng thái khẳng định. Và lúc này hội nghị đi vào
trạng thái TRANSACTION mà không có message nào bị đánh dấu để xoá. Nếu
maildrop không mở được vì một số lý do nào đó (ví du : một khoá không thể nhận
được, phía client bị từ chối truy cập tới maildrop thích hợp đó, hay maildrop không
được phân tích cú pháp ), POP3 server trả lời với một chỉ định trạng thái phủ định
(nếu một khoá được thu nhận nhưng POP3 server dự định trả lời với một chỉ định
trạng thái phủ định, POP3 server phải giải phóng khoá trước khi loại bỏ lệnh đó ).
Sau khi trả về một chỉ định trạng thái phủ định server phải đóng kết nối, nếu server
không đóng kết nối client có thể phát một lệnh xác nhận mới và bắt đầu trở lại, hoặc
là client phát ra một lệnh QUIT.
Sau khi POP3 server mở được maildrop nó gán một số thứ tự cho mỗi message và
biểu thị kích thước của mỗi message trong hệ bát phân (octet), message đầu tiên
trong maildrop được gán thứ tự là “1”, message thứ hai là “2” … Trong các lệnh và
các trả lời POP3 tất cả các số thứ tự và kích thước của message được trình bày dựa

trên hệ 10 (decimal)
Đây là những tóm tắt cho ba lệnh POP3 bàn luận ở trên :
• USER name
- Đối số: Một chuổi định danh một mailbox (được yêu cầu), nó chỉ có ý nghĩa với
server.
- Giới hạn : Chỉ có thể được cho trong trạng thái AUTHORIZATION sau khi POP3
chào hỏi hay sau khi một lệnh USER PASS không thành công .
- Câu trả lời có thể :
+OK tên mailbox có hiệu lực
-ERR không chấp nhận tên mailbox
Ví dụ Ï:
C: USER mrose
S: +OK mrose is a real hoopy frood

C: USER frated
S: -ERR sorry, no mailbox for frated here
• PASS string
- Đối số: Một password cho mailbox hay server (được yêu cầu)
a server/mailbox-specific password (required)
- Giới hạn : Chỉ có thể dược cho trong trạng thái AUTHORIZATION sau khi một
lệnh user thành công.
- Discussion: (thảo luận) : Kể từ đây lệnh PASS chỉ có một đối số, một POP3
server có thể xử lý khoảng trống trong đối số này như là một phần của password,
thay vì là để tách đối số ra .
- Câu trả lời có thể:
+OK khoá maildrop và sẳn sàng
-ERR password không hiệu lực
-ERR không được phép khoá maildrop
Ví dụ :
C: USER mrose

S: +OK mrose is a real hoopy frood
C: PASS secret
S: +OK mrose's maildrop has 2 messages (320 octets)

C: USER mrose
S: +OK mrose is a real hoopy frood
C: PASS secret
S: -ERR maildrop already locked
QUIT
- Đối số: không
- Giới hạn: không
- Câu trả lời có thể:
+OK
IV. TRẠNG THÁI GIAO DỊCH (Transaction)
Khi client định danh nó đến POP3 server thành công và POP3 server đã khoá và
mở maildrop thích hợp, POP3 session bây giờ trong trạng thái TRANSACTION ø
client có thể phát nhiều lần các lệnh POP3 sau đây. Sau mỗi lệnh POP3 server phát
ra một câu trả lời. Cuối cùng client phát ra một lệnh QUIT và POP3 session đi vào
trạng thái UPDATE .
Đây là các lệnh POP3 có hiệu lực trong trạng thái TRANSACTION:
• STAT
- Đối số: không
- Giới hạn : Chỉ có thể được cho trong trạng thái TRANSACTION.
- Discussion: (thảo luận) : POP3 server phát ra một trả lời khẳng định với một dòng
chứa thông tin của maildrop. Dòng này được gọi là một "drop listing" cho maildrop
đó.