Các luật ngữ nghĩa ở đây đ−ợc trình bày theo sự so sánh mức cao. Nĩ khơng dành riêng cho tr−ờng nào. Mục đích của nĩ là để trợ giúp việc so sánh và phân tích thơng tin ở các tr−ờng.
Cấu trúc chung cĩ dạng:
field = <field-name> ”:” [field-body] CRLF
field-name = 1*<any CHAR, excluding CTLs,SPACE,and ”:”> field-body = *text<CRLF LWSP-char field-body>
1.4.3. Các tr−ờng header điển hình a. Tr−ờng RETURN-PATH
<Return> = “Return-Path” “:” route-addr
Tr−ờng thơng tin này đ−ợc hệ thống truyền tải th− tín cuối cùng (là hệ thống cuối cùng phát th− cho ng−ời nhận của nĩ) thêm vào phần header của th−. Nĩ đ−ợc dùng để chứa đựng những thơng tin về địa chỉ trả về (return-address) của ng−ời gửi ban đầu. b. Tr−ờng RECEIVED
<Received> = “Received-From” “:” domain
Một bản sao của tr−ờng thơng tin này sẽ đ−ợc thêm vào bởi mỗi một hệ thống truyền tải thơng điệp mà th− đ−ợc chuyển qua. Thơng tin ở tr−ờng này rất hữu ích trong tr−ờng hợp xảy ra lỗi trong truyền thơng.
Tr−ờng thơng tin này dùng để xác định tên của máy chủ gửi (sending host), máy chủ nhận và thời gian nhận đ−ợc.
c. Tr−ờng FORWARD
<Forward> = “Forward-Path” “:” route-addr
Tr−ờng thơng tin này đ−ợc hệ thống truyền tải th− tín cuối cùng (là hệ thống cuối cùng phát th− cho ng−ời nhận của nĩ) thêm vào phần header của th−. Nĩ đ−ợc dùng để chứa đựng những thơng tin về địa chỉ của ng−ời nhận th−.
d. Tr−ờng FROM
<From> = “From” “:” mailbox
Tr−ờng thơng tin này chứa đựng thơng tin về ng−ời gửi th− (sender). Quá trình gửi th− cần ngầm định tr−ờng này là đơn. Nĩ xác minh địa chỉ máy tính, xác nhận bên gửi là một ng−ời, hệ thống hay một tiến trình. Nếu cơng việc này khơng đ−ợc thực hiện thì phải thay thế bằng tr−ờng Sender
e. Tr−ờng DATE
<Dates> = “Date” “:” date-time
Tr−ờng này chứa đựng thơng tin về ngày, giờ gửi th−. f. Tr−ờng TO
<To> = “To” “:” mailbox
Tr−ờng này chứa đựng thơng tin về ng−ời nhận th− (recipient) chính thức. g. Tr−ờng CC
<cc> = “cc” “:” address
Tr−ờng này chứa đựng thơng tin về ng−ời nhận th− thứ hai, cĩ nghĩa đồng gửi (carbon copy-cc).
h. Tr−ờng BCC
<bcc> = “bcc” “:” address
Tr−ờng này chứa đựng thơng tin thêm về ng−ời nhận th− (blind carbon copy-bcc). Nội dung của tr−ờng này khơng chứa đựng trong bản sao th− gửi cho ng−ời nhận thứ đầu tiên và ng−ời nhận th− hai.
i. Tr−ờng MESSAGE-ID
<Message-ID> = “Message-ID” “:” msg-id
Tr−ờng này chứa đựng thơng tin định danh duy nhất về bức th− đ−ợc gửi đi. Tính duy nhất của tr−ờng này đ−ợc bảo đảm bởi hệ thống sinh ra nĩ. Tr−ờng này đ−ợc dùng để dành riêng cho máy tính và khơng cần thiết đối với ng−ời sử dụng.
j. Tr−ờng SUBJECT
<Subject> = “Subject” “:” text
Tr−ờng này chứa đựng thơng tin về tiêu đề th− cần gửi. 1.4.4. Ví dụ về cấu trúc th−
Date: 26 Aug 76 1430 EDT
From: George Jones <Group@Host> Sender: Secy@SHOST
To: ”Al Neuman”@Mad-Host,
Sam.Irving@Other-Host Message-ID: <some.string@SHOST>
Subject: Test ...
1.5. PHÂN TÍCH GIAO THệÙC SMTP (RFC 821)
1.5.1. Giới thiệu chung
Mục đích của giao thức SMTP (Simple Mail Transfer Protocol) là để truyền th− đáng tin cậy và cĩ hiệu quả.
SMTP đọc lập về hệ thống con truyền thơng đặc biệt và các yêu cầu chỉ tin cậy theo kênh luồng dữ liệu tuần tự.
Đặc tính quan trọng của SMTP là khả năng chuyển tiếp th− tín qua các mơi tr−ờng dịch vụ truyền thơng (transport service). Dịch vụ truyền thơng cung cấp một mơi tr−ờng truyền thơng liên quá trình (interprocess communication environment - IPCE). IPCE cĩ thể là một mạng, nhiều mạng hay một tập hợp con của một mạng. Điều quan trọng để nhận thấy rằng các hệ thống truyền thơng (IPCEs) khơng phải là việc truyền thơng t−ơng ứng một tới một (one-to-one) với các mạng. Một tiến trình cĩ thể truyền thơng qua lại trực tiếp với một tiến trình khác thơng qua bất kỳ một IPCE đã đ−ợc biết. Th− tín là một ứng dụng hay là việc sử dụng truyền thơng liên tiến trình. Th− tín cĩ thể đ−ợc truyền qua giữa các tiến trình theo các IPCEs khác nhau bắng cách chuyển tiếp qua một tiến tiến trình đ−ợc kết nối tới hai hay nhiều IPCEs. Đặc biệt hơn nữa, th− tín cĩ thể đ−ợc chuyển tiếp giữa các máy chủ (hosts) trên các hệ thống truyền thơng khác nhau bởi một máy chủ trên cả hai hệ thống truyền thơng.
Giao thức SMTP định nghĩa cách để chuyển giao th− tín trực tiếp giữa các máy tính trên mạng. Nĩ cĩ hai vai trị là gửi (sender-SMTP) và nhận (receiver-SMTP) th−. Thơng th−ờng, bên gửi thiết lập một liên kết TCP với bên nhận, và bên nhận sử dụng cổng truyền thơng số 25 để cung cấp dịch vụ th− tín điện tử.
Trong một phiên giao dịch th− tín, bên gửi và bên nhận trao đổi tuần tự các lệnh và các thơng tin phản hồi.
1.5.2. Mơ hình hoạt động phiên giao dịch
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