SMTP đ−ợc thiết kế dựa trên mơ hình truyền thơng sau: khi ng−ời sử dụng (user) gửi một yêu cầu dịch vụ th− tín, tr−ớc tiên Sender-SMTP thành lập một kênh truyền thơng hai chiều tới Receiver-SMTP. Receiver-SMTP cĩ thể là đích cuối cùng hoặc là một trạm trung gian. Sau đĩ, các lệnh của SMTP đ−ợc sinh ra từ phía Sender- SMTP và gửi tới Receiver-SMTP. Receiver-SMTP sẽ thao tác trên các lệnh đĩ và gửi trả kết quả về phía Sender-SMTP.
SMTP cung cấp cơ chế chuyển th− trực tiếp từ máy chủ của ng−ời gửi đến máy chủ của ng−ời nhận khi hai máy chủ đ−ợc kết nối trên cùng một dịch vụ truyền thơng hoặc qua một hoặc nhiều Server-SMTP chuyển tiếp khi các máy chủ nguồn và máy chủ đích khơng cùng đ−ợc kết nối tới cùng một dịch vụ truyền thơng.
File System SMTP Commands / Replies Sender SMTP Sender - SMTP
Mơ hình tổng quát sử dụng giao thức SMTP Receiver SMTP Receiver - SMTP and Mail File System User
Để thực hiện đ−ợc khả năng chuyển tiếp th− tín trên mạng, cần phải cung cấp tên của máy chủ cũng nh− tên của hộp th− (mailbox) cuối cùng cần gửi tới cho SMTP Server.
SMTP cung cấp một tập các lệnh cho phép các máy tính trên mạng cĩ thể trao đổi thực tiếp các thơng tin theo một chuẩn qui định. Nhờ vào tập lệnh này, các hệ thống th− tín khác nhau cĩ thể trao đổi dữ liệu th− đ−ợc với nhau. Mỗi lệnh đều cĩ cùng chiều dài bốn kí tự, hầu hết đều cĩ tham số kèm theo.
Các lệnh sử dụng trong việc gửi/nhận th− tín tuân theo một cú pháp khắt khe. Đĩ là các thơng tin phản hồi luơn ở dạng mã số kèm theo là các mơ tả về kết quả thực hiện lệnh. Các lệnh và mã phản hồi khơng phân biệt chữ hoa và chữ th−ờng. Điều này cĩ nghĩa là một lệnh hoặc một thơng báo phản hồi cĩ thể ở dạng in hoa, in th−ờng hoặc trong bất kì một kiểu kết hợp nào giữa in hoa và in th−ờng.
L−u ý rằng điều này là khơng đúng với tên của ”user mailbox”. Với một số máy chủ, user name là phân biệt chữ hoa, th−ờng và việc thực hiện các lệnh SMTP cần phải quan tâm để đảm bảo sự thực hiện đúng đắn trong tr−ờng hợp này. Tên của máy chủ cũng khơng phân biệt chữ hoa, th−ờng.
Các lệnh và thơng tin phản hồi đ−ợc xây dựng bởi các kí tự từ bộ mã ASCII. Khi dịch vụ giao vận cung cấp kênh truyền thơng 8 bit, mỗi kí tự truyền đi sẽ chỉ sử dụng 7, bit cao nhất sẽ đ−ợc xố về 0.
Mỗi phiên giao dịch SMTP phải trải qua một số giai đoạn. Các giai đoạn đĩ đ−ợc thực hiện thơng qua các thủ tục SMTP, kèm theo đĩ là các thơng tin phản hồi:
• Thủ tục MAIL. • Thủ tục FORWARDING. • Các thủ tục MAILING và SENDING. • Các thủ tục OPENING và CLOSING. • Các mã trả lời của lệnh SMTP. 1.5.3. Thủ tục Mail
Để bắt đầu một phiên giao dịch th− tín thì cần phải thực hiện thủ tục MAIL. Nĩ bao gồm 3 b−ớc:
• Lệnh MAIL đ−ợc gửi đi kèm theo là tham số về địa chỉ ng−ời gửi th−.
• Lệnh RCPT đ−ợc gửi đi kèm theo là tham số về địa chỉ ng−ời nhận th−. Cĩ thể thực hiện nhiều lần lệnh này trong tr−ờng hợp muốn gửi th− cho nhiều ng−ời. • Lệnh DATA đ−ợc gửi đi để xác nhận bắt đầu gửi dữ liệu của th−.
D−ới đây là phần chi tiết về 3 lệnh trên. a. Lệnh MAIL FROM <reverse-path>
• Tham số: là một xâu ký tự định danh mailbox của ng−ời gửi th−. • Hạn chế: Chỉ cĩ thể thực hiện khi ch−a thực hiện chính lệnh này.
• Chi tiết: Lệnh này dùng để xác nhận ng−ời gửi th− đồng thời thiết lập một phiên giao dịch SMTP với Receiver-SMTP (Server). Nĩ đ−a ra đ−ờng dẫn <reverse-path> để sử dụng trong tr−ờng hợp phiên giao dịch khơng thực hiện thành cơng. Ng−ợc lại, thơng tin về ng−ời gửi sẽ đ−ợc l−u lại.
• Thơng tin phản hồi: 250 OK
Tr−ờng hợp cịn lại bị lỗi. Ví dụ:
S: MAIL FROM: <Smith@Alpha.edu> R: 250 OK
b. Lệnh RCPT TO <forward-path>
• Tham số: là một xâu ký tự định danh mailbox của ng−ời nhận th−.
• Hạn chế: Chỉ cĩ thể thực hiện khi đã định danh ng−ời gửi th− bằng lệnh MAIL. • Chi tiết: Lệnh này dùng để xác nhận ng−ời nhận th− đ−ợc chỉ định trong tham số <forward-path>. Nếu Receiver-SMTP chấp nhận thì thơng tin về ng−ời gửi sẽ đ−ợc l−u lại. Lệnh này cĩ thể thực hiện nhiều lần để xác nhận nhiều ng−ời nhận th−.
• Thơng tin phản hồi: 250 OK Tr−ờng hợp cịn lại bị lỗi. Ví dụ S: RCPT TO: <Jones@Beta.gov> R: 250 OK S: rcpt to: <Green@Beta.gov> R: 550 No such user here c. Lệnh DATA
• Tham số: khơng.
• Hạn chế: Chỉ cĩ thể thực hiện khi đã thực hiện thành cơng việc xác nhận ng−ời gửi và ng−ời nhận th−.
• Chi tiết: Lệnh này dùng để xác nhận bắt đầu việc gửi nội dung th−. Nếu SMTP Receiver chấp nhận, nĩ sẽ tiến hành nhận và l−u trữ tất cả các dịng văn bản đ−ợc gửi đến. Để kết thúc việc gửi dữ liệu, SMTP Sender cần gửi một dịng chỉ chứa một dấu chấm ”.”. L−u ý rằng phần dữ liệu sau lệnh DATA bao gồm tồn bộ phần header của th− (nh− các tr−ờng Date, Subject, CC, From, ...) cũng nh− nội dung th−.
• Thơng tin phản hồi: 250 OK
Ví dụ:
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF> S:. . . Sends body of mail message . . .
S: <CR><LF>.<CR><LF> R: 250 OK
S: QUIT
S: 221 Beta.gov Service Closing Transmission Channel
Sau đây là một ví dụ minh hoạ cho một phiên giao dịch th− tín SMTP. Phần thơng tin phía Server đ−ợc bắt đầu bằng R: và mã số, tiếp sau là thơng tin. Phần phía
Client là các lệnh thực thi của SMTP bắt đầu bằng S:. Ta sẽ sử dụng dịch vụ Telnet để kích hoạt dịch vụ th− tín trên cổng 25 (SMTP).
d. Ví dụ về một phiên giao dịch SMTP
R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready S: HELO USC-ISIF.ARPA
R: 250 BERKELEY.ARPA
S: MAIL FROM: <Postel@USC-ISIF.ARPA> R: 250 OK
S: RCPT TO: <fabry@BERKELEY.ARPA> R: 250 OK
S: RCPT TO: <eric@BERKELEY.ARPA>
R: 552 Recipient storage full, try again in another transaction S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF> S: Blah blah blah...
S: ...etc. etc. etc. S: .
R: 250 OK
S: MAIL FROM: <Postel@USC-ISIF.ARPA> R: 250 OK
S: RCPT TO: <eric@BERKELEY.ARPA> R: 250 OK
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF> S: Blah blah blah...
S: ...etc. etc. etc. S: .
R: 250 OK S: QUIT
R: 221 BERKELEY.ARPA Service closing transmission channel 1.5.4. Thủ tục Forwarding
Trong một số tr−ờng hợp địa chỉ trong tham số <forward-path> bị sai, nh−ng SMTP Receiver lại biết chính xác địa chỉ đích thì các thơng tin phản hồi cĩ thể đ−ợc sử dụng để cho phép ng−ời gửi xác nhận lại địa chỉ đúng.
251 User not local; will forward to <forward-path>
Thơng tin phản hồi này chỉ ra rằng mailbox của ng−ời nhận thuộc một máy chủ (host) khác. Nh− vậy, SMTP Receiver sẽ chỉ ra <forward-path> chính xác để sử dụng và nĩ sẽ chịu trách nhiệm gửi th− này.
551 User not local; please try <forward-path>
Thơng tin phản hồi này chỉ ra rằng, SMTP Receiver biết đ−ợc mailbox của ng−ời nhận thuộc một máy chủ khác. Nĩ sẽ đ−a ra địa chỉ chính xác để sử dụng nh−ng trong tr−ờng hợp này nĩ khơng thực hiện việc gửi th− đi. Chính vì vậy, ng−ời gửi cần phải xác nhận lại các thơng tin cho chính xác theo thơng tin phản hồi của SMTP Receiver hoặc trả lại thơng báo lỗi cho ng−ời gửi ban đầu.
S: RCPT TO:<Postel@USC-ISI.ARPA> R: 251 User not local;
will forward to <Postel@USC-ISIF.ARPA> or
S: RCPT TO:<Paul@USC-ISIB.ARPA> R: 551 User not local;
please try <Mockapetris@USC-ISIF.ARPA> 1.5.5. Các thủ tục Mailing và Sending
SMTP chủ yếu cung cấp các chức năng phát th− đến mailbox của ng−ời sử dụng. Tuy nhiên, nĩ cũng cĩ một số các chức năng thực hiện việc chuyển th− đến terminal của ng−ời sử dụng.
Việc phát th− đến mailbox của ng−ời sử dụng đ−ợc gọi là ”mailing”, cịn việc phát th− đến terminal đ−ợc gọi là ”sending”. Dịch vụ sending là phần mở rộng của một hệ thống th− tín điện tử.
Cĩ ba dạng câu lệnh đ−ợc định nghĩa để hỗ trợ cho các tùy chọn sending. Các câu lệnh này đ−ợc dùng trong các phiên giao dịch SMTP thay thế cho câu lệnh MAIL và báo cho Receiver-SMTP biết ý nghĩa đặc biệt của phiên giao dịch này.
a. Lệnh SEND FROM <reverse-path> • Tham số: địa chỉ terminal của ng−ời nhận.
• Chi tiết: Lệnh này yêu cầu dữ liệu của th− đ−ợc phân phát tới terminal của ng−ời sử dụng. Nếu ng−ời sử dụng ch−a kích hoạt (hoặc khơng chấp nhận kiểu giao dịch này) thì Receiver-SMTP sẽ gửi trả mã 450. Phiên giao dịch là thành cơng nếu th− đ−ợc chuyển đến terminal của ng−ời sử dụng.
• Thơng tin phản hồi: 450 OK
b. Lệnh SOML FROM <reverse-path> • Tham số: địa chỉ terminal của ng−ời nhận.
• Chi tiết: Lệnh này (viết tắt của chữ Send Or MaiL) yêu cầu dữ liệu của th− đ−ợc phân phát tới terminal của ng−ời sử dụng trong tr−ờng hợp ng−ời sử dụng kích hoạt (và chấp nhận kiểu giao dịch này). Trong tr−ờng hợp ng−ợc lại, nghĩa là ng−ời sử dụng ch−a kích hoạt thì dữ liệu của th− sẽ đ−ợc chuyển đến mailbox của ng−ời nhận. Phiên giao dịch thành cơng nếu th− đ−ợc chuyển đến terminal của ng−ời sử dụng.
c. Lệnh SAML FROM <reverse-path> • Tham số: địa chỉ terminal của ng−ời nhận.
• Chi tiết: Lệnh này (viết tắt của chữ Send And MaiL) yêu cầu dữ liệu của th− đ−ợc phân phát tới terminal của ng−ời sử dụng trong tr−ờng hợp ng−ời sử dụng kích hoạt (và chấp nhận kiểu giao dịch này). Trong bất cứ tr−ờng hợp nào thì dữ liệu của th− cũng sẽ đ−ợc chuyển đến mailbox của ng−ời nhận. Phiên giao dịch thành cơng nếu th− đ−ợc chuyển đến mailbox của ng−ời sử dụng.
Khi một phiên giao dịch th− tín đ−ợc mở, cần phải cĩ sự trao đổi thơng tin giữa các máy chủ (host) để đảm bảo sự chính xác trong giao dịch. Cĩ hai lệnh để thực hiện việc đĩng/mở một phiên giao dịch.
a. HELO <domain>
• Tham số: tên domain của máy chủ thực hiện việc gửi th− (cĩ thể khơng cĩ). • Chi tiết: Lệnh này dùng để xác nhận domain máy chủ SMTP Sender. • Thơng tin phản hồi:
250 <domain>
Ví dụ:
R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready S: HELO USC-ISIF.ARPA
R: 250 BBN-UNIX.ARPA b. QUIT
• Tham số: khơng.
• Chi tiết: Lệnh này dùng để kết thúc phiên giao dịch SMTP. • Thơng tin phản hồi:
250 CRLF Ví dụ:
S: QUIT
R: 221 BBN-UNIX.ARPA Service closing transmission channel 1.5.7. Mã trả lời của các câu lệnh SMTP
Trong một phiên giao dịch SMTP, phía SMTP Sender gửi các lệnh yêu cầu cịn phía SMTP Receiver sẽ gửi trả các thơng tin phản hồi và các mã phản hồi.
Để đảm bảo tính thống nhất truyền thơng trong quá trình truyền th−, đồng thời để đảm bảo phía SMTP Sender luơn biết đ−ợc chính xác trạng thái của SMTP Receiver, mọi câu lệnh yêu cầu đều phải đ−ợc trả lời bằng các mã thơng tin phản hồi chính xác.
Bảng Mã thơng tin phản hồi của SMTP
Mã thơng tin phản hồi Thơng tin kèm theo
500 Syntax error or Command unregconized 501 Syntax error in parameters or arguments
503 Bad sequence of command
504 Command parameter not implement
211 System status or System help reply
214 Help message
220 Simple Mail Transfer Service ready 221 Service closing transmission channel
421 Service not available, closing transmission channel
250 OK
251 User not local; will forward to <forward-path> 450 Mailbox unavailable (not found or no access)
551 User not local; please try <forward-path> 452 Insufficent system storage
552 Request mail action aborted
553 Mailbox name not allow (mailbox syntax incorrect) 354 Start mail input, end with <CRLF>.<CRLF>
554 Transaction failed
Một mã thơng tin phản hồi là một số cĩ 3 chữ số và tiếp theo là một chuỗi văn bản mơ tả về mã đĩ. Bảng trên đây sẽ trình bày chi tiết các thơng tin phản hồi:
Truyền thơng giữa Sender-SMTP và Receiver-SMTP đ−ợc coi nh− một cuộc hội thoại, đ−ợc điều khiển bởi Sender-SMTP. Nh− vậy, Sender-SMTP đ−a ra một lệnh yêu cầu và Receiver- SMTP sẽ trả lại một mã thơng tin phản hồi. Sau khi Sender-SMTP đ−a ra lệnh yêu cầu, nĩ phải đợi thơng tin phản hồi từ Receiver-SMTP rồi mới đ−a ra lệnh tiếp theo.
Trong các mã thơng tin phản hồi, mã phản hồi quan trọng nhất là 220. Nĩ đặc tr−ng cho việc thực hiện thành cơng yêu cầu.
1.6. PHÂN TÍCH GIAO THệÙC POP3 (RFC 1081,1082)
1.6.1. Giới thiệu
Giao thức POP3 cho phép một máy trạm cĩ thể truy nhập để lấy th− trên máy chủ. Nĩ định nghĩa cách thức giao tiếp với POP3 Server bởi các lệnh chuẩn đ−ợc quy định trong RFC 1081 để lấy th− về.
1.6.2. Mơ hình hoạt động phiên giao dịch
Vào thời điểm bắt đầu, tiến trình phía Server bắt đầu dịch vụ POP3 bằng cách ”lắng nghe” trên cổng TCP 110. Thuật ngữ ”lắng nghe” ở đây đ−ợc hiểu theo nghĩa là tiến trình phía Server luơn luơn tiếp nhận các thơng tin đến ở cổng dịch vụ mà nĩ cung cấp - trong tr−ờng hợp này là cổng dịch vụ 110 - xử lý và gửi kết quả về cho tiến trình yêu cầu dịch vụ phía Client.
Khi một tiến trình phía Client muốn sử dụng dịch vụ, nĩ thiết lập một kết nối TCP tới máy chủ phía Server. Khi kết nối đ−ợc thiết lập, POP3 Server gửi một thơng báo chấp nhận và sau đĩ tiến trình phía Client và POP3 Server cĩ thể trao đổi các lệnh cũng nh− các thơng tin phản hồi cho đến khi kết nối bị hủy bỏ hoặc phiên giao dịch kết thúc. Các lệnh trong POP3 bao gồm từ khĩa, cĩ thể theo sau là một hoặc nhiều tham số. Tất cả các lệnh đều đ−ợc kết thúc bởi cặp ký tự CRLF. Từ khĩa và các tham số là các kí tự in đ−ợc trong bảng mãkí tự ASCII, giữa chúng đ−ợc phân cách bởi một kí tự dấu cách trống. Từ khĩa cĩ thể dài ba hoặc bốn kí tự, cịn các tham số cĩ thể dài tới bốn m−ơi kí tự.
Thơng tin phản hồi của POP3 bao gồm một thơng báo trạng thái và một từ khĩa cĩ thể theo sau một số thơng tin thêm. Tất cả các thơng tin phản hồi đều đ−ợc kết thúc bởi cặp ký tự CRLF.
Cĩ hai thơng báo trạng thái là: Xác định (”+OK”) để xác nhận thành cơng và phủ định (”-ERR”) để xác nhận trong tr−ờng hợp cĩ lỗi.
Các thơng tin phản hồi cho các lệnh thực tế là nhiều dịng. Trong những tr−ờng hợp này, sau khi gửi dịng đầu tiên của thơng tin phản hồi và một cặp CRLF, bất cứ một dịng thêm vào nào đ−ợc gửi thì đều phải kết thúc bằng cặp CRLF. Khi tất cả các thơng tin phản hồi đều đã đ−ợc gửi, một dịng cuối cùng đ−ợc gửi, bao gồm mã kết thúc (mã thập phân 046, ”.”) và một cặp CRLF.
Nếu cĩ một dịng nào trong thơng tin phản hồi đa dịng bắt đầu với một mã ký tự kết thúc (dấu chấm ”.”), thì dịng đĩ coi nh− ch−a đ−ợc xử lí xong đối với thơng tin phản hồi . Vì vậy, một thơng tin phản hồi đa dịng đ−ợc kết thúc bởi bộ năm octets là ”CRLF. CRLF”.
Một phiên giao dịch POP3 phải trải qua một số các trạng thái trong suốt thời gian tồn tại của phiên làm việc. Mỗi lần kết nối TCP đ−ợc mở và POP3 Server gửi thơng báo chấp nhận, phiên làm việc chuyển sang trang thái AUTHORIZATION. ở trạng thái này, Client phải tự định danh của mình cho POP3 Server.
Mỗi khi Client thực hiện xong việc định danh, Server nhận đ−ợc tài nguyên t−ơng ứng với hộp th− của Client, nĩ sẽ chuyển sang trạng thái TRANSACTION.
Trong trạng thái này, các yêu cầu của Client đ−ợc chuyển sang và đ−ợc thực hiện bên phía POP3 Server. Khi Client đ−a ra lệnh QUIT, phiên làm việc chuyển sang trạng thái UPDATE. Trong trạng thái này, POP3 Server giải phĩng mọi tài nguyên thu đ−ợc trong suốt trạng thái TRANSACTION và kết thúc. Đồng thời, kết nối TCP kết thúc.
Một POP3 Server cĩ thể cĩ một bộ xác định thời gian. Nếu sau một khoảng thời gian xác định tr−ớc mà phía Client khơng cĩ tác động gì thì POP3 Server cĩ thể tự động kết thúc phiên làm việc. Khoảng thời gian này ít nhất là khoảng 10 phút.