Tải bản đầy đủ (.doc) (34 trang)

Tìm hiểu giao thức SMTP POP3

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (261.01 KB, 34 trang )

CHƯƠNG 3
CÁC NGHI THỨC TRUYỀN NHẬN
χ
Công việc phát triển các hệ thống Mail (Mail System) đòi hỏi hình thành các chuẩn
về Mail. Điều này giúp cho việc gởi nhận các thông điệp được đảm bảo , làm cho
những người ở các nơi khác nhau có thể trao đổi thông tin cho nhau.
Có 2 chuẩn về Mail quan trọng nhất và được sử dụng nhiều nhất từ trước đến nay là
X.400 và SMTP ( Simple Mail Transfer Protocol). SMTP thường đi kèm với chuẩn
POP3 và do hạn chế của SMTP mà ngày nay người ta dùng chuẩn mở rộng của nó là
ESMTP (Extended SMTP). Mục đích chính của X.400 là cho phép các mail có thể
được truyền nhận thông qua các loại mạng khác nhau bất chấp cấu hình phần cứng,
hệ điều hành mạng , giao thức truyền dẫn được dùng. Còn mục đích của chuẩn
SMTP miêu tả cách điều khiển các thông điệp trên mạng Internet. Điều quan trọng
của chuẩn SMTP là giả định máy nhận phải dùng giao thức SMTP gởi Mail cho 1
Server luôn luôn hoạt động. Sau đó, người nhận sẽ đến lấy Mail của họ từ Server
khi nào họ muốn dùng giao thức POP (Post Office Protocol), ngày nay POP được
cải tiến thành POP3 (Post Officce Protocol vertion 3). Các giao thức Mail thông
dụng : chuẩn X.400, chuẩn MAIP, SMTP (ESMTP), POP3 . Ở đây chỉ trình bày
chi tiết về POP3 và SMTP .
Phần 1
Giao thức SMTP (Simple Mail transfer Protocol )
***
Bộ phận chính của hệ thống Internet Mail chính là các MTA ( Message Transfer
Agent), các MTA giữ 1 vai trò quan trọng trong việc chuyển giao email. Ví dụ sau khi
một người sử dụng gửi một bức mail tới hàng đợi message, MTA sẽ lấy đó và chuyển nó
tới một MTA khác. Quá trình đó sẽ tiếp tục tiếp diễn cho đến khi message đến được nơi
nhận. Để có thể liên lạc với các MTA thông qua kết nối TCP các MTA của hệ thống
Internet Mail có thể sử dụng nhiều nghi thức khác nhau để chuyển giao các thông tin
(X400,ESMTP, ), Nhưng ở đây ta chỉ xét nghi thức SMTP. Đây là một nghi thức cho
phép chuyển mail từ điểm này sang điểm khác cho đến đích trên mạng Internet. Nó được
cấu tạo bởi tập các câu lệnh để Client có thể yêu cầu Sever thực hiện một số tác vụ và tập


các câu trả lời để Server hồi đáp lại cho Client về kết quả thực hiện các tác vụ đó. Một
chương trình muốn gởi được mail thì nó phải biết địa chỉ của một SMTP server. Server
này có nhiệm vụ chuyển mail đến nơi cần thiết.
I- Giới thiệu
Một đặc trưng quan trọng của SMTP là khả năng chia ca Mail qua môi trường dịch vụ
giao chuyển, một dịch vụ giao chuyển cung cấp một môi trường truyền thông liên quá
trình (Interprocess Communication Environment –IPCE ). Một môi trường truyền thông
liên quá trình có thể bao gồm một Network, vài Network, hay một tập hợp con của
Network. Điều đó quan trọng cho việc thực hiện hệ thống giao chuyển (hay các IPCE)
one-to-one với Network, một quá trình có thể giao tiếp với một quá trình khác thông qua
việc nhận biết IPCE. Mail là ứng dụng hay là cách dùng của giao tiếp liên quá trình, Mail
có thể giao tiếp giữa các quá trình trong những IPCE khác bằng cách chia ca thông qua
một quá trình được kết nối đến hai (hay nhiều ) IPCE. Chi tiết hơn Mail có thể chia ca
giữa những Host trên hệ thống giao chuyển khác nhau bằng một Host trên cả hai hệ
thống chuyển giao.
II- Mô hình SMTP
SMTP được thiết kế dựa trên mô hình giao tiếp sau: như kết quả của một yêu cầu
Mail của user . Sender- SMTP thiết lập một kênh hai đường vận chuyển đến một
receiver- SMTP . Receiver- SMTP có thể là đích đến cuối cùng hay một trung gian.
Những lệnh SMTP được sinh ra bởi Sender-SMTP gửi đến Receiver- SMTP. Những
reply SMTP được gửi từ Receiver- SMTP đến Sender- SMTP trong sự đáp ứng cho
những lệnh đó.
Khi một kênh giao chuyển được thiết lập sender-SMTP gửi đi 1 lệnh Mail biểu thị
cho Sender của mail đó. Nếu Receiver-SMTP có thể chấp nhận mail, nó trả lời với một
OK reply. Sau đó Sender-SMTP gửi một lệnh RCPT nhận diện Receiver mail nếu
Receiver-SMTP có thể chấp nhận mail nó trả lời với 1 OK reply nếu không nó sẽ lời với
1 reply bác bỏ receiver đó (nhưng không phải toàn bộ sự giao dịch đó). Sender- SMTP và
Receiver- SMTP có thể điều đình với vài recipient, khi những recipient đã được dàn xếp
Sender-SMTP gửi mail data kết thúc với một chuỗi đặc biệt nếu receiver xử lý mail data
thành công nó trả lời với 1 OK reply. Cuộc hội thoại một cách chủ ý lock –step (one-at-a-

time).
Sơ đồ trên là mô hình cho cách dùng SMTP.
SMTP cung cấp những cơ chế giao chuyển Mail một cách trực tiếp từ Host của
User gửi đến host của user nhận khi cả hai host được kết nối đến cùng dịch vụ giao
chuyển hay qua nhiều SMTP-Sever tiếp vận khi host xuất phát hay đích đến không được
kết nối đến cùng dịch vụ chuyển giao. Để có thể cung cấp khả năng tiếp vận SMTP-Sever
phải được cung cấp tên của host đến cùng chẳng hạn như hạn của Mailhost đến .
Đối số của lệnh mail là 1 reverse-path nó đặc tả mail đó từ đâu đến; đối số cho
RCPT là 1 Forward-path nó đặc tả mail đó đi đến đâu. Forward-path là một lộ trình
nguồn, reverse-path là một lộ trình trở về (nó có thể được dùng để trả về một message
cho sender- khi xảy ra lỗi với 1 message được tiếp vận).
Khi cùng một message được gửi cho nhiều recipient SMTP khuyến khích chuyển
giao chỉ một bản sao của data cho tất cả các Receiver ở cùng một host đích.
Sender
SMTP
Receiver
SMTP
User
File
System
File
Syste
m
SMTP
Commands/Replies
and Mail
Sender-SMTP Receiver-SMTP
Những command và reply mail có những cú pháp khắc khe. Những reply cũng có
một mã số. Trong những thí dụ theo sau sẽ xuất hiện những lệnh (commands) và những
trả lời (replies) , một danh sách các lệnh và reply hoàn chỉnh trong phần 4.

Các command và reply không phân biệt kiểu chữ hoa hay thường. Lưu ý, điều này
không đúng với tên của User mailbox. Cho một số host tên của user có phân biệt kiểu
chữ, SMTP phải thi hành đầy đủ việc nhận kiểu chữ và giữ gìn kiểu chữ của những user
name như chúng đã xuất hiện trong những đối số của mailbox. Host names không phân
biệt kiểu chữ.
Các command và reply là những ký tự được tạo ra từ tập ký tự ASCII{1}, khi dịch
vụ vận chuyển cung cấp một kênh chuyển giao 8 bit (octet). Mỗi một ký tự 7 bit được
truyền đúng bằng cách chuyển nó về hệ 8 (octet) với bit có thứ tự cao nhất bị xóa về 0.
Khi đặc tả cấu trúc thông thường của command và reply, một đối số (hay một ký
hiệu đặc biệt ) sẽ được biểu thị bằng một biến meta-linguistic (hay một hằng số), ví dụ
như : “<string>”, hay “<reverse-path>”. Ở đây dấu ngoặc nhọn chỉ định chúng là những
biến meta-linguistic. Tuy nhiên các đối số thì dùng dấu ngoặc nhọn một cách literal. Ví
dụ như, một reverse-path thực được bao trong dấu ngoặc nhọn như,
“<>” là một trường hợp của <reverse-path> (dấu ngoặc
nhọn được giao chuyển trong command và reply là mã thực của nó).
III . Mail
1- Khái quát :
Có 3 bước cho sự giao dịch SMTP mail. Giao dịch được bắt đầu với yêu cầu Mail
mang sự nhận diện sender, tiếp theo sau là một chuỗi của một hay nhiều lệnh RCPT trao
những thông tin của receiver, sau đó một lệnh DATA cho mail data.Và cuối cùng là phần
chỉ định kết thúc mail data xác nhận giao dịch đó.
 Bước đầu tiên trong thủ tục là lệnh MAIL <reverse-path> chứa mailbox nguồn
MAIL <SP> FROM : <reverse-path> <CRLF>
Lệnh này báo cho receiver biết một giao dịch mail mới sẽ bắt đầu và để reset tất cả
các bảng trạng thái và các buffer của nó bao gồm tất cả recipient hay mail data. Nó phát
ra reverse-path có thể được dùng để báo lỗi. Nếu được chấp nhận receiver-SMTP trả về
một reply 250 OK.
<Reverse-path> có thể chứa nhiều hơn một mailbox.<Reverse-path> là một lộ trình
nguồn trở về liệt kê các host và mailbox nguồn. Host đầu tiên trong reverse-path sẽ là
host gữi lệnh này.

 Bước thứ hai trong thủ tục này là lệnh RCPT
RCPT <SP> To : <forward-path> <CRLF>
Lệnh này phát đi một forward-path nhận diện recipient. Nếu được chấp nhận
receiver-SMTP trả về một reply 250 OK. Và lưu lại forward-path. Nếu recipient không
nhận biết thì receiver trả về reply 550 Failure. Bước thứ hai của thủ tục này có thể lặp lại
nhiều lần.
Forward-path có thể chứa nhiều hơn một mailbox. Forward-path là lộ trình nguồn
liệt kê các host và mailbox đích. Host đầu tiên trong <forword-path> sẽ là host nhận lệnh
này.
 Bước thứ ba trong thủ tục là lệnh DATA
DATA <CRLF>
Nếu chấp nhận receiver-SMTP trả về một reply 354 và coi tất cả các dòng nối tiếp đó
là message text. Khi văn bản cuối cùng được nhận và lưu trữ receiver-SMTP gửi một
reply 250 OK.
Kể từ mail data được gửi trên kênh chuyển giao, điểm kết thúc của mail data phải
được chỉ định để hội thoại command và reply có thể bắt đầu trở lại. SMTP chỉ định kết
thúc của mail data bằng cách gửi một dòng chứa chỉ một dấu chấm.
Chú ý rằng mail data bao gồm những mục (item) memo header chẳng hạn như
Subject, To, Cc, From.
Phần chỉ định kết thúc của mail data cũng xác nhận sự giao dịch mail và báo cho
receiver-SMTP biết để xử lý việc lưu trữ recipient và mail data ngay lúc đó. Nếu được
chấp nhận receiver-SMTP trả về một reply 250 OK. Lệnh DATA sẽ chỉ fail nếu giao dịch
mail không hoàn thành (ví dụ không có receiver) hoặc nếu tài nguyên không có hiệu lực.
Thủ tục trên là một ví dụ của một giao dịch mail. Những lệnh này chỉ được dùng
trong những trật tự được trình bày ở trên. Ví dụ :
Một minh họa cách dùng những lệnh này tron
ut; end with <CRLF>.<CRLF>
S: Blah blah blah
S: etc. etc. etc.
S: <CRLF>.<CRLF>

R: 250 OK
Bây giờ mail được chấp nhận cho Jones và Brown. Green không có một mailbox
trên Beta host.
2- Sự định hướng :
Có một số trường hợp thông tin của đích đến trong <forward-path> bị sai nhưng
receiver-SMTP biết đích đến đúng. Trong trường hợp như vậy một trong những reply
sau sẽ được dùng để cho phép sender tiếp xúc đích đến đúng :
 251 User not local ; will forward to <forward-path>
Reply này chỉ cho receiver-SMTP biết mailbox của user đó nằm trên một host
khác và chỉ định forward-path đúng để sau đó sử dụng. Lưu ý một trong hai host hay
user hay cả hai có thể khác nhau . Receiver chịu trách nhiệm cho việc phân phối
những message.
 551 User not local ; please try <forward-path>
Reply này chỉ cho receiver-SMTP biết mailbox của user nằm trên một host khác
và chỉ định forward-path đúng để sử dụng . Lưu ý host hoặc là user hay cả hai có thể
khác nhau . Receiver từ chối chấp nhận mail cho user A. Sender phải định hướng lại
cho mail đó tuỳ theo những thông tin được cung cấp hoặc là trả trả lời error cho user
khởi đầu.Ví dụ sau minh hoạ cách dùng của những đáp ứng này :
S: RCPT TO:
R: 251 User not local; will forward to <>
Hay
S: RCPT TO:<>
R: 551 User not local; please try
3- Kiểm tra và mở rộng :
SMTP cung cấp thêm những điểm đặc trưng, các lệnh để kiểm tra một user name
hay mở rộng một danh sách địa chỉ được làm với lệnh VRFY và EXPN nó dùng đối số
kiểu chuổi ký tự. Với lệnh VRFY chuỗi đó là một user name, và câu trả lời(response) có
thể bao gồm full name của user đó và phải bao gồm mailbox của user đó. Với lệnh EXPN
chuổi đó định danh một danh sách địa chỉ và câu trả lời có nhiều dòng có thể chứa full
name của các user đó và phải chứa những mailbox trên danh sách địa chỉ (mailing list).

Nếu một host được bổ sung lệnh VRFY hay EXPN thì ít nhất những mailbox cục
bộ phải được thừa nhận như là“user names”. Nếu một host chọn lựa để thừa nhận những
chuổi khác như “user names” thì điều đó được cho phép.
Trong một số host sự phân biệt giữa một mailing list và một bí danh cho single
mailbox hơi mơ hồ. Từ đó một cấu trúc dữ liệu phổ biến có thể giữ cả hai kiểu phần tử
và nó có thể dùng các mailing list của một mailbox. Nếu một yêu cầu được tạo ra để kiểm
tra một mailing list một câu trả lời khẳng định có thể được cho nếu trên message nhận
được đã được định địa chỉ nó sẽ được phân phát cho tất cả mọi người trong danh sách đó.
Mặt khác một lỗi sẽ được báo cáo (e.g., "550 That is a mailing list, not a user"). Nếu một
yêu cầu được tạo ra để mở rộng một user name một câu trả lời khẳng định có thể được
cấu hình bằng cách trả về một danh sách chứa một tên hay một lỗi có thể được báo cáo
(e.g., "550 That is a user name, not a mailing list").
Trong trường hợp một reply nhiều dòng (thường cho EXPN) là một mailbox được
đặc tả trên từng dòng của reply đó một cách chính xác. Trong trường hợp này một yêu
cầu nhập nhằng khó hiểu như : “VRFY Smith” có hai câu trả lời của Smith phải là "553
User ambiguous".
Ví dụ kiểm tra một user name
S: VRFY Smith
R: 250 Fred Smith <>
Hay
S: VRFY Smith
R: 251 User not local; will forward to <>
Hay
S: VRFY Jones
R: 550 String does not match anything.
Hay
S: VRFY Jones
R: 551 User not local; please try <>
Hay
S: VRFY Gourzenkyinplatz

R: 553 User ambiguous.
Trường hợp mở rộng một mailbox list đòi hỏi một reply nhiều dòng xem trong ví
dụ sau: mở rộng một mailing list (danh sách địa chỉ)
S: EXPN Example-People
R: 250-Jon Postel <>
R: 250-Fred Fonebone <>
R: 250-Sam Q. Smith <>
R: 250-Quincy Smith <@USC-ISIF.ARPA:>
R: 250-<> R: 250 <>
Hay
S: EXPN Executive-Washroom-List
R: 550 Access Denied to You.
Những đối số chuổi ký tự của lệnh VRFY và EXPN không thể vượt qua giới hạn
được quyền trên sự bổ sung đa dạng của user name và khái niệm mailbox. Trên một số hệ
thống nó có thể dành riêng cho đối số của lệnh EXPN để là một file name cho một file
chứa một mailing list nhưng lại có một qui ước đa dạng của việc đặc tên file trong
internet.
Lệnh VRFY và EXPN không được bao gồm trong sự thực thi tối thiểu (trình bày
trong phần sau) và không được đòi hỏi để làm việc thay ca khi chúng được thực thi.
4- Sending and Mailing :
Mục đích chính của SMTP là phân phối những message đến những mailbox của
user . Một dịch vụ rất phổ biến được cung cấp bởi một số host là để phân phối những
message đến những terminal của user( cung cấp cho user làm việc trên host đó) . Sự phân
phát đến những mail box của user được gọi là “mailing”, sự phân phát đến những user
terminal được gọi là “sending”. Bởi vì một số host có sự thực thi của sending gần giống
với sự thực thi của mailing chúng là hai chức năng được liên kết với SMTP. Mặc dù lệnh
sending không bao gồm trong yêu cầu thực thi tối thiểu( xem phần sau). Những user có
khả năng điều khiển việc ghi message lên những terminal của họ. Hầu hết các host cho
phép chấp nhận hay từ chối những message.
Ba lệnh sau được định nghĩa để cung cấp những option cho sending. Chúng được

dùng trong giao dịch mail thay cho lệnh MAIL và cung cấp cho receiver-SMTP những
ngữ nghĩa giao dịch đặc biệt
SEND <SP> FROM:<reverse-path> <CRLF>
Lệnh SEND đòi hỏi mail data được gửi đến user terminal. Nếu user đó không hoạt
động (hay không chấp nhận những terminal message) trên host đó một reply 450 có thể
được trả cho một lệnh RCPT. Giao chuyển mail thành công khi message đó được phân
phát đến terminal.
SOML <SP> FROM:<reverse-path> <CRLF>
Lệnh này là SEND Or MAIL đòi hỏi mail data được phân phát đến terminal của
user nếu user đó đang hoạt động (và chấp nhận những message terminal) trên host đó.
Nếu user không hoạt động (haykhông chấp nhận terminal message) thì mail data được
đưa vào trong mailbox của user . Giao chuyển mail thành công khi message đó được
phân phát đến terminal hay mailbox.
SAML <SP> FROM:<reverse-path> <CRLF>
Lệnh này là SEND And MAIL đòi hỏi mail data được phân phát đến terminal của
user nếu user đó đang hoạt động (và chấp nhận những message terminal) trên host đó.
Trong những tất cả trường hợp mail data được đưa vào trong mailbox của user. Giao
dịch mail thành công khi message đó được phân phát đến mailbox.
Những mã reply tương tự được dùng cho lệnh MAIL cũng được dùng cho những
lệnh này.
5- Opening and Closing :
Ngay thời điểm mà kênh giao chuyển được open có một sự trao đổi để đảm bảo
những host đó đang giao tiếp với những host khác.
Hai lệnh sau được dùng trong việc đóng mở kênh truyền
HELLO <SP> <domain><CRLF>
QUIT <CRLF>
Trong lệnh HELLO host này gửi đi những nhận dạng lệnh của nó có thể được
dịch như "HELLO, I am <domain>".
* Ví dụ mở kết nối :
Opening R : 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready

S : HELO USC-ISIF.ARPA
R: 250 BBN-UNIX.ARPA
* Ví dụ đóng kết nối :
Closing S: QUIT
R :221 BBN-UNIX.ARPA Service transmission channel.
6- Chia ca (Relaying) :
Forward-path có thể là một lộ trình nguồn của form
"@ONE, @TWO:JOE@THREE"
với ONE ,TWO, THREE là các host.
Form này được dùng để nhấn mạnh sự phân biệt giữa một address và một route.
Mailbox là một address tuyệt đối, và route là thông tin về việc lấy chúng như thế nào .
Những thành phần của forward-path được chuyển đến reverse-path khi message
đó được chia ca từ một server SMTP đến một server-SMTP khác. Reverse-path là một lộ
trình nguồn trở về (khác với một lộ nguồn là từ vị trí hiện hành của message đến điểm
khởi đầu của message đó). Khi một server SMTP xóa phần nhận dạng của nó trong
forward-path và chèn phần nhận dạng của nó vào trong reverse-path, nó phải dùng cái
tên mà nó được biết tới trong môi trường mà nó sẽ gửi vào, không phải là môi trường mà
mail từ đó đến, trong trường hợp server-SMTP được biết đến với những tên khác nhau
trong những môi trường khác nhau.
Nếu một message đến một SMTP thành phần đầu tiên của forward-path không
phải là phần nhận dạng của SMTP đó, thành phần này không bị xoá trong forward-path
và được dùng để xác định SMTP kế để gửi message đến. Trong trường hợp này SMTP
thêm phần nhận dạng của nó vào reverse-path
Dùng lộ trình nguồn receiver-SMTP nhận mail để chia ca đến một server-SMTP
khác. Receiver-SMTP đó có thể chấp nhận hoặc bác bỏ công việc chia ca cho mail, như
cách nó chấp nhận hay bác bỏ mail cho một user cục bộ. Receiver-SMTP thay đổi những
đối số lệnh bằng cách chuyển phần nhận dạng của nó từ forward-path vào chổ mở đầu
của reverse-path. Sau đó receiver-SMTP trở thành sender-SMTP, thiết lập một kênh
truyền đến SMTP kế trong forward-path,và gửi mail đó cho nó.
Host đầu tiên trong reverse-path sẽ là host gửi các lệnh SMTP và host đầu tiên

trong forward-path sẽ là host các nhận các lệnh SMTP .
Lưu ýrằng forward-path và reverse-path xuất hiện trong các lệnh và các reply
SMTP, nhưng nó không cần thiết xuất hiện trong message . Nó không cần thiết cho
những đường dẫn và cú pháp đặc biệt này xuất hiện trong những field của message
header như "To:" , "From:", "CC:",….
Nếu một server-SMTP chấp nhận công việc chia ca mail và sau đó thấy forward-
path không đúng hay mail đó không thể được phân phát được vì bất cứ lí do nào, thì nó
phải xây dựng một message thông báo "undeliverable mail" (mail không thể phân phát)
và gửi nó đến nơi xuất phát của mail không thể phân phát đó(được chỉ định trong reverse-
path). Message thông báo này phải là từ server-SMTP tại host đó. Dĩ nhiên những
server-SMTP sẽ không gữi những message thông báo về những sự cố xảy ra cho message
thông báo đó. Một cách ngăn chặn sự lặp lại trong việc thông báo lỗi là đặc tả một null
reverse-path trong lệnh MAIL của message một thông báo. Khi một message thông báo
như vậy được chia ca nó được dùng để loại bỏ reverse-path null. Một lệnh MAIL với null
reverse-path như dưới đây:
MAIL FROM:< >
Thông báo này nằm trong trả lời cho một message được khởi động bởi JOE tại
HOSTW và gửi thông qua HOSTX đến HOSTY với chỉ thị chia ca nó đến HOSTZ, nó là
bước đầu tiên trong việc trả về message thông báo .
Ví dụ message thông báo mail không thể phân phát
S: MAIL FROM:<>
R: 250 ok
S: RCPT TO:<@HOSTX.ARPA:>
R: 250 ok
S: DATA R: 354 send the mail data, end with .
S: Date: 23 Oct 81 11:22:33 S: From:
S: To:
S: Subject: Mail System Problem
S:
S: Sorry JOE, your message to lost.

S: HOSTZ.ARPA said this:
S: "550 No Such User"
S: .
R: 250 ok
8-Thay đổi vai trò :
Lệnh TURN có thể dùng để đảo vai trò của hai chương trình đang giao tiếp trên
kênh giao chuyển.
Nếu chương trình A đang là sender-SMTP hiện hành và nó gửi lệnh TURN và
nhận một reply OK(250) thì chương trình A trở thành receiver-SMTP.
Nếu chương trình B đang hiện hành receiver-SMTP hiện hành và nó gửi lệnh
TURN và nhận một reply OK(250) thì chương trình B trở thành sender-SMTP.
Để từ chối thay đổi vai trò receiver gửi reply 502
Lưu ý là lệnh này không bắt buộc. Thường nó không được dùng trong tình trạng
kênh giao chuyển là TCP. Tuy nhiên khi trị giá cho việc thiết lập kênh giao chuyển cao,
lệnh này có thể rất có ích. Ví dụ như lệnh này có ích trong việc hổ trợ là trao đổi mail
dùng hệ thống public switched telephone làm một kênh giao chuyển, đặc biệt nếu một số
host đề cử các host khác cho việc trao đổi mail.
IV. Đặc tả SMTP
A. Những lệnh SMTP (Commands SMTP)
1. Ngữ nghĩa lệnh :
Những lệnh SMTP định nghĩa sự truyền mail hay chức năng của hệ thống mail
được yêu cầu bởi user. Những lệnh SMTP là những chuỗi ký tự kết thúc bằng <CRLF>.
Bản thân mã lệnh là những ký tự chữ (alphabetic) kết thúc bởi <SP> nếu có những tham
số theo sau và <CRLF> khác. Cú pháp của những mailbox phải tuân theo những thoả
hiệp phía receiver. Những reply SMTP được bàn đến trong phần B.
Một sự giao dịch mail bao gồm vài đối tượng dữ liệu được giao tiếp khi những
đối số cho các lệnh khác nhau. Reverse-path là đối số của lệnh MAIL. Forward-path là
đối số của lệnh RCPT. Và mail data là đối số của lệnh DATA. Ba đối số và những đối
tượng dữ liệu được duy trì cho đến khi xác nhận truyền xong bởi sự chỉ định kết thúc của
mail data thì thật sự kết thúc giao dịch. Mô hình cho nó là những buffer riêng biệt được

cung cấp để giữ kiểu của đối tượng dữ liệu. Một số lệnh đặc trưng sinh ra thông tin được
gắn vào một buffer đặc trưng, hay làm cho một hay nhiều buffer bị xoá.
 HELLO (HELO) : Lệnh này dùng định danh sender-SMTP đến receiver-SMTP.
Field đối số chứa host name của sender-SMTP. Receiver-SMTP định danh nó đến
sender-SMTP trong trả lời bắt tay cho việc kết nối, và trong câu trả lời cho lệnh
này.Lệnh này và một reply OK để xác nhận cả hai sender-SMTP và receiver-SMTP
đang trong tình trạng khởi động, điều đó là: không có một giao dịch mail nào đang
tiến hành và tất cả các bảng trạng thái và buffer đã được xoá.
 MAIL : Lệnh này được dùng khởi tạo một giao dịch mail trong đó mail data được
phân phối đến một hay nhiều mailbox. Feild đối số chứa một reverse-path. Rever _se
- path bao gồm một danh sách các host tuỳ ý và mailbox của user. Khi danh sách các
host hoàn tất nó là một lộ trình nguồn “trở về” và chỉ định mail đó được chia ca thông
qua mỗi host trên danh sách đó (host đầu tiên trong list là host chia ca gần nhất). List
này được dùng như một lộ trình nguồn để trả về sender những thông báo không thể
phân phát. Tại mỗi host chia ca nó thêm phần định danh của bản thân vào chổ bắt đầu
của list đó và phải dùng tên của nó được biết trong IPCE nơi nó sẽ chia ca mail đến
đó, đúng hơn là ICPE có mail đến từ đó (nếu chúng khác nhau). Trong một số loại
message thông báo lỗi (ví dụ thông báo mail không thể phân phát) reverse-path có thể
là null.
 RECIPIENT (RCPT) : Lệnh này dùng định danh một recipient (người nhận) mail
data riêng lẻ, nhiều recipient được đặc tả bằng nhiều lệnh này. Forward-path bao
gồm một danh sách các host tuỳ ý và một mailbox đích được yêu cầu. Khi danh sách
host đó hoàn tất. Nó là một lộ trình nguồn và chỉ định mail phải được chia ca đến host
kế tiếp trên list đó. Nếu receiver-SMTP không thực thi chức năng chia ca nó có thể
dùng được reply này và sẽ cho một unknown local user (550). Khi mail được chia ca,
host chia ca phải chuyển phần định danh nó từ chổ bắt đầu forward-path và đặt vào
chổ bắt đầu của reverse-path. Khi mail trải ra tới đích cuối cùng (forward-path chỉ
chứa một mailbox đích) receiver-SMTP Insert nó vào trong mailbox đích trong sự
đồng ý với thoả hiệp host mail của nó.
Ví dụ mail được nhận tại host chia ca A với những đối số:

FROM:<>
TO:<@HOSTA.ARPA,@HOSTB.ARPA:>
Sẽ được chia ca đến host B với đối số
FROM:<@HOSTA.ARPA:>
TO:<@HOSTB.ARPA:>.
Lệnh này sinh ra đối số forward-path của nó được gắn vào forward-path buffer.
 DATA(DATA) : Receiver xử lý những dòng theo sau lệnh này khi mail data từ
sender đến. Nó làm cho mail data từ lệnh này được ghi vào data buffer. Mail data này
có thể chứa những ký tự của 128 mã ACII. Data mail được kết thúc bằng một dòng
chỉ chứa một dấu chấm. Đó là một dãy ký tự "<CRLF>. <CRLF>" (xem phần 4.D.2).
Và đó là chỉ định kết thúc của mail data.
Sự chỉ định kết thúc một chuổi đòi hỏi receiver phải xử lý việc lưu trữ những
thông tin giao dịch mail ngay lập tức. Quá trình xử lý này dùng thông tin trong
reverse-path buffer, forward-path buffer, mail data buffer, và khi hoàn tất lệnh này
những buffer đó sẽ bị xoa
ược nhận, những message được chia ca sẽ có nhiều dòng đánh dấu thời gian.
Khi một receiver-SMTP tạo ra “final delivery” của một message nó insert vào
chổ bắt đầu của mail data một dòng return-path . Dòng return-path đó bảo quản thông
tin trong “reverse-path” từ lệnh mail. Ơ đây deliver final có nghĩa là message đó rời
khỏi thế giới SMTP. Thông thường có nghĩa là nó đã được chuyển đến user đích .
nhưng trong một số trường hợp nó có thể được xử lý nữa và và được giao chuyển bởi
hệ thống mail khác.
Có thể cho mailbox trong return path là khác biệt với mailbox thật sự của
sender, ví dụ như nếu những trả lời error được dùng phân phát một lỗi đặc biệt điều
khiển mailbox.
Hai đoạn trước ý nói mail data cuối cùng sẽ bắt đầu với một dòng return path
theo sau là một hay nhiều dòng đánh dấu thời gian , sau những dòng này sẽ là phần
header và body của mail data [2].
Sự đề cập đặc biệt cần thiết cho sự trả lời (response) và sự hành động tiếp nữa
được yêu cầu khi quá trình xữ lý theo sau sự chỉ định kết thúc mail data là sự thành

công cục bộ. Điều này có thể phát sinh nếu sau khi chấp nhận một vài recipient và
data mail receiver-SMTP thấy mail data đó có thể được phân phát đến một số
recipient thành công nhưng lại không thể đến những người khác (ví dụ như xảy ra vấn
đề về việc chỉ định vị trí của mailbox). Trong tình trạng như vậy câu trả lời cho lệnh
DATA phải là một reply OK. Nhưng receiver-SMTP phải soạn và gửi về nơi xuất xứ
của message đó một message thông báo “undelivered mail”. Một thông báo đơn liệt
kê tất cả các recipient không nhận được message, hay những message thông báo riêng
lẽ phải được gửi cho từng recipient một , tất cả những thông báo mail không thể phân
phát được gửi dùng lệnh MAIL (ngay cả nếu kết quả đó từ quá trình xử lý một lệnh
SEND, SOML, hay SAML ).
Ví dụ cho đường dẫn trả về và nhận đánh dấu thời gian nhận
Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:>
Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST
Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST
Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST
Date: 27 Oct 81 15:01:01 PST
From:
Subject: Improved Mailing System Installed
To: This is to inform you that
 SEND (SEND) : Lệnh này dùng khởi tạo một giao dịch mail trong đó mail data được
phân phát đến một hay nhiều terminal. Field đối số chứa một reverse-path. Lệnh này
thành công nếu message được phân phát đến một terminal.
Reverse-path bao gồm một list các host và mailbox sender tuỳ ý khi list đó hoàn
tất, nó là một lộ trình nguồn “trở về” và chỉ định mail đã được chia ca thông qua các
host trong list đó (host đầu tiên trong list là host chia ca gần nhất) danh sách này được
dùng như một lộ trình nguồn để trả về cho sender những thông báo về việc không
phân phát được. Khi mỗi host chia ca thêm phần định danh vào trong vị trí bắt đầu
của list , nó phải dùng tên mà nó được biết đến trong IPCE nơi nó sẽ chia ca mail tới
đó , đúng hơn là IPCE có mail tới từ đó.
Lệnh này xoá reverse-path buffer, forward-path buffer và mail data buffer và

chèn thông tin reverse-path từ lệnh này vào trong reverse-path buffer.
??????????
 END OR MAIL (SOML) : Lệnh này dùng khởi tạo một giao dịch mail trong đó mail
data được phân phát đến một hay nhiều terminal hay mailbox. Cho từng recipient,
data mail được phân phát đến terminal của recipient nếu recipient đó đang hoạt động
trên host đó (và chấp nhận những terminal message ), mặt khác là đến mailbox của
những recipient đó. Field đối số chứa một reverse-path . Lệnh này thành công khi
message được phân phát đến một terminal hay mailbox.
Reverse-path bao gồm một danh sách các host tuỳ ý và mailbox của sender .
Khi danh sách các host đó hoàn tất, nó là một lộ trình nguồn “trở về” và chỉ định mail
đó đã được chia ca thông qua các host trên danh sách (host đầu tiên trong danh sách
là host chia ca gần nhất). Danh sách này được dùng như một lộ trình nguồn trả về cho
sender những thông báo về việc không thể phân phát. Khi mỗi host chia ca thêm phần
định danh nó vào chổ bắt đầu của danh sách đó, nó phải dùng tên được biết đến trong
IPCE nơi nó sẽ chia ca mail đến đó đúng hơn là IPCE có mail đến từ đó(nếu chúng
khác nhau).
Lệnh này xoá reverse-path buffer, forward-path buffer và mail data buffer và
chèn thông tin reverse-path từ lệnh này vào trong reverse-path buffer.
 SEND AND MAIL (SAML) : Lệnh này dùng khởi tạo một giao dịch mail trong đó
mail data được phân phát đến một hay nhiều terminal và các mailbox. Cho từng
recipient data mail được phân phát đến terminal của recipient nếu recipient đó đang
hoạt động trên host đó (và chấp nhận những terminal message ) và cho tất cả recipient
thì đến mailbox của các recipient đo. Field đối số chứa một reverse-path . lệnh này
thành công khi message được phân phát đến mailbox.
Reverse-path bao gồm một danh sách các host tuỳ ý và mailbox của sender.
Khi danh sách hoàn tất nó là một lộ trình nguồn “trở về” và chỉ định mail đã được
chia ca thông qua các host trong danh sách đó(host đầu tiên trong danh sách là host
chia ca gần nhất ) Danh sách này được dùng như một lộ trình nguồn trả về cho sender
những thông báo về việc không thể phân phát. Khi mỗi host chia ca thêm phần định
danh nó vào chổ bắt đầu của danh sách đó nó phải dùng tên mà nó được biết đến

trong IPCE mà nó sẽ chia ca mail đến đó đúng hơn là IPCE mà mail đến từ đó(nếu
chúng khác nhau).
Lệnh này xoá reverse-path buffer, forward-path buffer và mail data buffer
và chèn thông tin reverse-path từ lệnh này vào trong reverse-path buffer.
????????
 RESET (RSET) : Lệnh này định rõ giao dịch mail hiện hành bị huỷ bỏ. Các sender,
recipient, mail data đã lưu sẽ bị huỷ bỏ và tất cả các bảng trạng thái, các buffer bị xoá.
Receiver phải gửi một reply OK.
 VERIFY (VRFY) : Lệnh này yêu cầu receiver xác nhận đối số định danh một user.
Nếu nó là một user name, full name của user đó (nếu receiver biết) và mailbox đặc tả
đầy đủ được trả về.Lệnh này không ảnh hưởng đến reverse-path buffer, forward-path
buffer và data mail buffer.
 EXPAND (EXPN) : Lệnh này yêu cầu receiver xác nhận một mailing list ( danh sách
địa chỉ) và trả về một thành phần trong danh sách đó. Full name của các user (nếu
biết) và những mailbox được đặc tả đầy đủ được trả về trong một reply nhiều dòng.
Lệnh này không ảnh hưởng đến reverse-path buffer, forward-path buffer và
data mail buffer.
 HELP (HELP) : Lệnh này làm cho receiver thông tin giúp đỡ cho sender lệnh HELP.
Lệnh này có thể nhận một đối số (có thể là tên lệnh) và trả về thông tin chi tiết.
Lệnh này không ảnh hưởng đến reverse-path buffer, forward-path buffer và
data mail buffer.
 NOOP (NOOP) : Lệnh này không ảnh hưởng các tham số hay các lệnh được đưa vào
trước nó, nó đặc tả không có một hành động nào khác hơn là receiver gửi một reply
OK.
Lệnh này không ảnh hưởng đến reverse-path buffer, forward-path buffer và
data mail buffer.
 QUIT (QUIT) : Lệnh này định rõ receiver phải gửi một reply OK và sau đó đóng
kênh giao dịch . Receiver sẽ không đóng kênh giao dịch cho đến khi nó nhận và trả
lời cho lệnh QUIT (ngay cả nếu có một lỗi xãy ra). Sender sẽ không đóng kênh giao
dịch cho đến khi nó gửi một lệnh QUIT và nhận reply đó (ngay cả nếu có một lỗi trả

lời cho lệnh trước đó). Nếu kết nối bị đóng trước thời gian mong muốn receiver sẽ
làm việc như vừa nhận được một lệnh RSET (bỏ tất cả các giao dịch đang treo mà
chưa làm, nhưng không “undo” những giao dịch đã hoàn tất trước đó) sender sẽ hành
động như nếu lệnh hay giao dịch đó trong quá trình xử lý nhận được một lỗi tạm thời
(4xx).
 TURN (TURN) : Lệnh này định rõ receiver phải gửi một trong hai reply sau: (1)
reply OK và sau đó nhận vai trò của một sender-SMTP, hay (2) gửi một reply từ chối
và giữ lại vai trò một receiver-SMTP.
Nếu program-A hiện tại là một sender-SMTP gửi một lệnh TURN và nhận
một reply OK (250) thì program-A trở thành receiver-SMTP sau đó program-A sẽ
trong trạng thái khởi động chỉ nếu kênh giao chuyển đã được mở, sau đó nó chờ nhận
một chào hỏi dịch vụ đã sẵn sàng 220.
Để từ chối thay đổi vai trò receiver gửi một reply 502.
Có sự hạn chế trong trật tự khi dùng những lệnh này.
Đầu tiên trong một cuộc trao đổi phải là lệnh HELLO, lệnh này có thể được dùng
sau đó trong một cuộc trao đổi khác. Nếu đối số trong lệnh HELLO không được chấp
nhận một reply failure 501 phải được trả về và receiver-SMTP đó phải ở trong trạng
cũ.
Những lệnh NOOP, HELP, EXPAND và VRFY có thể được dùng nhiều lần
trong một cuộc giao dịch.
Các lệnh MAIL, SEND, SOML, và SAML bắt đầu một giao dịch mail. Khi bắt
đầu một giao dịch mail bao gồm một lệnh khởi tạo giao dịch , một hay nhiều lệnh
RCPT, và một lệnh DATA đó là một trật tự . một giao dịch mail có thể được bỏ qua
bởi một lệnh RSET có thể có hay không có nhiều giao dịch trong một cuộc trao đổi
(session).
Nếu đối số của lệnh khởi động giao dịch không thể chấp nhận một reply failure
501 phải được trả về và sercer-SMTP phải nằm trong trạng thái cũ. Nếu những lệnh
trong cuộc giao dịch không đúng trật tự một reply failure 503 được trả về và receiver-
SMTP đó phải nằm trong trạng thái cũ.
Lệnh cuối cùng trong cuộc trao đổi phải là lệnh QUIT và lệnh QUIT không thể

được dùng nhiều lần trong một cuộc trao đổi.
2- Cú pháp lệnh :
Những lệnh này bao gồm một mã lệnh theo sau là một field đối số . Mã lệnh là
bốn ký tự chữ . Những ký tự thường và hoa được xữ lý như nhau . Vậy những từ sau đây
có thể đại diện cho lệnh MAIL:
MAIL Mail mail MaIl mAIl
Ở đây cũng dùng một số ký hiệu trình bày cho những giá trị của tham số , chẳng
hạn như “TO” hay “to” cho forward-path. Mã lệnh và những field đối số được tách ra bởi
một hay nhiều khoảng trắng. Tuy nhiên bên trong những đối số reverse-path và forward-
path kiểu chữ rất quan trọng. Trong một số host user “vu” khác với user “Vu”.
Field đối số gồm có một biến chiều dài chuổi ký tự, kết thúc với chuổi <CLRF>.
Receiver không nhận hành động cho đến khi nhận được chuổi <CLRF> này.
Dấu ngoặc vuông biểu thị một field đối số tuỳ ý. Nếu không nhận chọn lựa này
một defaul phù hợp sẽ được áp dụng.


Sau đây là những lệnh SMTP:
HELO <SP> <domain> <CRLF>
MAIL <SP> FROM:<reverse-path> <CRLF>
RCPT <SP> TO:<forward-path> <CRLF>
DATA <CRLF>
RSET <CRLF>
SEND <SP> FROM:<reverse-path> <CRLF>
SOML <SP> FROM:<reverse-path> <CRLF>
SAML <SP> FROM:<reverse-path> <CRLF>
VRFY <SP> <string> <CRLF>
EXPN <SP> <string> <CRLF>
HELP [<SP> <string>] <CRLF>
NOOP <CRLF>
QUIT <CRLF>

TURN <CRLF>
Cú pháp của những field đối số trên( dùng ký hiệu BNF có thể áp dụng được ở
đây) được cho bên dưới. Ký hiệu “…” chỉ định mộ field có thể được lặp một hay nhiều
lần.
<reverse-path> ::= <path>
<forward-path> ::= <path>
<path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"
<a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>
<at-domain> ::= "@" <domain>
<domain> ::= <element> | <element> "." <domain>
<element> ::= <name> | "#" <number> | "[" <dotnum> "]"
<mailbox> ::= <local-part> "@" <domain>
<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 literal (thay cho sự thông dịch thông thường của nó) ví dụ như
"Van\,Sam" sẽ được dùng chỉ định một ký tự một field bảy ký tự đơn với dấu phẩy là ký
tự thứ tư của field.
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 domains 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 field 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

Receive
h bày trong Sequencing của phần V.3 và lược đồ trạng thái của phần V.4
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 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
211 Trạng thái hệ thống, hay trả lời giúp đỡ về hệ thống
214 Thông điệp 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 Thông điệp 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 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
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 và receiver được định là một cuộc hội thoại tuần tự
do sender điều khiển. Chẳng hạn như sender sinh ra một lệnh và receiver trả lời với một
reply. Sender 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 sẽ gửi một
reply 220 “service ready” khi kết nối hoàn thành. Sender phải chờ thông điệp 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 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 IV.C
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
C- 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 :
B
E
W S
F
2cmd
4,5
1,3
⇔ 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 đến receiver không cần sự
trả lời cho đến khi dòng cuối cùng được gửi.
D- Chi tiết
1. Sự thực thi tối thiểu :
Lợ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
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 mail text 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 mail text 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á.
1,2
B W
W F
S
E
DATA
data
3 4,5
1,3 2
4,5
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 recipient 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 record 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)
V- 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 protocol
internetwork .
* 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 sender 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 :
ĐỂ CÓ PHẠM VI LỚN NHẤT CÓ THỂ, THỰC THI KỸ
THUẬT ĐÁNH LỪA KHÔNG GIỚI HẠN CHIỀU DÀI
CỦA NHỮNG ĐỐI TƯỢNG SẼ ĐƯỢC DÙNG
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 sender 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 ssender-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 (the finest gradation of information. ) .
* 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. Sender 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 sender hay receiver (như một lệnh được lặp lại một cách giống nhau
và receiver 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 đó người sử dụng 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 receiver 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 đó sender 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
sender trong reply “text” sender 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 POP 3 (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 netwrork 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 keyword (từ khoá) 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ờinhiề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) treotermina_ tion
octe đó 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 POP3 session 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 AUTHORIZATION (xác nhận). 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 client’s maildrop, và hội nghị đi vào trạng thái TRANSACTION (giao dịch). 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 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 TRANSACTION và say goodbye. Sau đó kết
nối TCP đóng lại.
Một POP3 server có thể có một timer tự động logout không chủ động. Một timer
như vậy 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 timer tự động logout đó. Khi timer 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.

×