Tailieu.vncty.com webmail

Đồ án tốt nghiệp

Sinh viên thực hiện Nguyễn Xuân Thanh Trang 1

Đề tài:

“Xây dựng ứng dụng Webmail”



MỤC LỤC

PHẦN 1 : CƠ SỞ LÝ THUYẾT .................................................................................. 9

CHƯƠNG 1 : GIỚI THIỆU CHUNG VỀ INTERNET VÀ

MỘT SỐ GIAO THỨC TRUYỀN THÔNG TRÊN INTERNET .............................................................................................................................. 10

1.1. GIỚI THIỆU CHUNG VỀ INTERNET ..................................................... 10

1.2. HỌ GIAO THỨC TCP/IP ........................................................................... 11

1.3. GIAO THỨC LIÊN MẠNG IP ................................................................... 12

1.4. GIAO THỨC ĐIỀU KHIỂN TRUYỀN TCP ............................................. 19

CHƯƠNG 2 : CƠ SỞ VỀ LẬP TRÌNH MẠNG TRÊN MÔ

HÌNH CLIENT/SERVER ......................................................................... 21

2.1. LẬP TRÌNH GIAO TIẾP MẠNG VỚI WINDOWS SOCKETS ................. 21

2.2. MỘT SỐ KHÁI NIỆM CƠ BẢN ................................................................ 22

2.2.1.Địa chỉ Internet ................................................................................... 22

2.2.2. Khái niệm socket và port .................................................................. 22

2.3. CÁCH CÀI ĐẶT ỨNG DỤNG CLIENT/SERVER TCP ........................... 23

2.3.1. Cách cài đặt server TCP ................................................................... 24

2.3.2. Cách cài đặt client TCP ................................................................... 24

CHƯƠNG 3 : MỘT SỐ KHÁI NIỆM LIÊN QUAN ĐẾN THƯ

ĐIỆN TỬ .......................................................................................................... 26

1.1. MAILSERVER ........................................................................................... 26

1.2. GIAO THỨC GỬI MAIL (MAIL TRANSPORT PROTOCOL) ................. 26



1.3.GIỚI THIỆU KIẾN TRÚC DỊCH VỤ THƯ ĐIỆN TỬ................................ 27

1.3.1. Kiến trúc và các dịch vụ .................................................................... 27

1.3.2. Tác nhân người sử dụng (The User Agent) ...................................... 30

1.3.2.1.Gửi thư (Sending Email) ................................................................ 30

1.3.2.2. Đọc thư (Reading Email) ............................................................... 31

1.3.2.3.Định dạng thông điệp (Message Formats)....................................... 32

1.3.2.4.Chuẩn RFC 822 .............................................................................. 33

1.4.PHÂN TÍCH CẤU TRÚC THƯ ĐIỆN TỬ, CÁC GIAO THỨC SMTP VÀ

POP3 ................................................................................................................. 36

1.4.1.Phân tích cấu trúc thư điện tử (RFC 822) .......................................... 36

1.4.1.1. Giới thiệu ..................................................................................... 36

1.4.1.2. Mô tả về cấu trúc thư ..................................................................... 37

1.4.2. Định nghĩa về các trường Header ..................................................... 39

1.4.3. Các trường header điển hình ............................................................ 39

1.4.4. Ví dụ về cấu trúc thư ......................................................................... 41

1.5. PHÂN TÍCH GIAO THỨC SMTP (RFC 821) ............................................ 42

1.5.1. Giới thiệu chung ................................................................................ 42

1.5.2. Mô hình hoạt động phiên giao dịch .................................................. 43

1.5.3. Thủ tục Mail ...................................................................................... 45

1.5.4. Thủ tục Forwarding ........................................................................... 48

1.5.5. Các thủ tục Mailing và Sending......................................................... 49

1.5.6. Các thủ tục Opening và Closing ........................................................ 51

1.5.7. Mã trả lời của các câu lệnh SMTP .................................................... 52

1.6. PHÂN TÍCH GIAO THỨC POP3 (RFC 1081,1082) .................................. 53

1.6.1. Giới thiệu ........................................................................................... 54

1.6.2. Mô hình hoạt động phiên giao dịch .................................................. 54



1.6.3. Trạng thái AUTHORIZATION ....................................................... 56

1.6.4. Trạng thái TRANSACTION ............................................................ 59

1.6.5. Trạng thái UPDATE ......................................................................... 64

1.6.6. Ví dụ về một phiên giao dịch POP3 .................................................. 65

1.7. MIME (MULTIPURPOSE INTERNET MAIL EXTENSIONS) ................. 67

1.8.POP BEFORE SMTP(CHỨNG THỰC QUYỀN TRUY CẬP THEO GIAO

THỨC POP TRƯỚC KHI SỬ DỤNG SMTP) ................................................... 69

1.9.MAIL CLIENT, WEB MAIL ...................................................................... 70

CHƯƠNG 4 : GIỚI THIỆU VỀ CÁC CÔNG NGHỆ LIÊN

QUAN ............................................................................................................... 70

2.1.GIỚI THIỆU VỀ JRUN WEBSERVER 3.1 ................................................. 70

2.2.GIỚI THIỆU VỀ SQL SERVER 7.0 ............................................................ 71

2.2.1. Lý thuyết hệ quản trị cơ sở dữ liệu sql server 7.0 và Cấu trúc cơ sở

dữ liệu của sql server 7.0 ............................................................................. 71

2.2.2. Cấu trúc cơ sở dữ liệu vật lý: ............................................................. 72

2.2.2.1. Trang (page): ................................................................................. 72

2.2.2.2 .Extent: ........................................................................................... 73

2.2.2.3 Những loại file trong CSDL:SQL Server có 3 loại file: .................. 73

2.3. LÝ THUYẾT MÔ HÌNH QUAN HỆ .......................................................... 74

2. 3.1. Các khái niệm cơ bản ........................................................................ 74

2.3.2. Khái Niệm phụ thuộc dữ liệu và các dạng chuẩn ............................. 74

2.3.3 Khái niệm chỉ dẫn và khóa chỉ dẫn .................................................... 75

2.4.GIỚI THIỆU VỀ JAVA SERVLET ............................................................ 75

2.4.1.Khái niệm về JAVA SERVLET ......................................................... 75

2.4.2.Những ứng dụng thực tế của JAVA SERVLET và kiến trúc của

JAVA SERVLET ......................................................................................... 76



2.5.GIỚI THIỆU VỀ JAVA SERVER PAGES(JSP) ......................................... 76

2.5.1.Khái niệm về JSP ................................................................................ 76

2.5.2.Quan hệ giữa Servlet và JSP .............................................................. 77

2.5.2.1.Cách trình chủ biên dịch trang JSP thành servlet ............................ 77

2.5.2.2. So sánh giữa Servlet và JSP ........................................................... 77

2.6. GIỚI THIỆU VỀ JAVABEANS ................................................................. 78

2.6.1.Khái niệm về JAVABEANS................................................................ 78

2.6.2.Các thẻ chuẩn của JAVABEANS trong trang JSP ........................... 79

2.6.2.1.<jsp:useBean> ................................................................................ 79

2.6.2.2.<jsp:setProperty> ........................................................................... 80

2.6.2.3. <jsp:getProperty> .......................................................................... 81

2.6.3.Thêm JAVABEANS vào JSP .............................................................. 81

PHẦN 2 : XÂY DỰNG ỨNG DỤNG ....................................................................... 83

CHƯƠNG 1 PHÂN TÍCH BÀI TOÁN ............................................... 83

1.1.TÊN ĐỀ TÀI ............................................................................................... 83

1.2.DỀ CƯƠNG CHI TIẾT ............................................................................... 83

1.2.1.Khảo sát ............................................................................................... 83

1.2.2.Yêu cầu của bài toán ........................................................................... 83

1.2.3.Dữ liệu vào, dữ liệu ra và các chức năng xử lý của hệ thống ............ 84

1.2.4. Chức năng của hệ thống thông tin quản lý ....................................... 85

1.3. LÝ DO CHỌN ĐỀ TÀI .............................................................................. 85

CHƯƠNG 2 : THIẾT KẾ VÀ CÀI ĐẶT ỨNG DỤNG ............... 86

2.1.PHÂN TÍCH VÀ THẾT KẾ CƠ SỞ DỮ LIỆU ............................................ 86

2.1.1.Phân tích .............................................................................................. 86

2.1.2. Giải thích các chức năng của hệ thống .............................................. 88



2.1.3.biểu đồ luồng dữ liệu( DFD – Data flow Diagram) ............................ 89

2.1.4. THIẾT KẾ HỆ THỐNG .................................................................... 89

2.1.4.1. Các bảng dữ liệu chính .................................................................. 89

2.2. CÀI ĐẶT MAILSERVER .......................................................................... 91

2.2.1.Phương án tổ chức lưu trữ mail trên Server ...................................... 91

2.2.2.Các đơn thể của mailserver ................................................................ 92

2.2.2.1. Xây dựng SMTP Server ................................................................ 93

2.2.2.2. Xây dựng POP3 Server................................................................ 114

2.3.CÀI ĐẶT MAILCLIENT .......................................................................... 136

Một số giao diện chính ................................................................................. 142

LỜI CẢM ƠN

Trước hết tôi xin chân thành cảm ơn các thầy cô giáo khoa Đại học

Đại Cương của trường Đại học Thuỷ Sản Nha Trang và khoa Công Nghệ

Thông Tin trường Đại học Bách Khoa Hà Nội đã trang bị cho tôi những

kiến thức cơ bản cần thiết trong những năm học vừa qua để tôi có thể thực

hiện tốt cuốn đồ án này.



Em xin chân thành cảm ơn thầy Văn Thế Minh đã tận tình giúp đỡ và

hướng dẫn em hoàn tất cuốn đồ án này. Ngoài ra tôi cũng xin cảm ơn tất cả

bạn bè đã giúp đỡ tôi trong suốt quá trình thực hiện đồ án.

Mặc dù đã rất cố gắng, nhưng trong khoảng thời gian cho phép cũng

như những hạn chế về kiến thức nên cuốn đồ án này của tôi không thể

tránh khỏi những thiếu sót. Chính vì vậy, tôi rất mong nhận được sự góp ý

của các thầy cô giáo cũng như bạn bè gần xa và những cá nhân hay tổ chức

có quan tâm đến lĩnh vực được trình bày trong cuốn đồ án này.

Hà Nội, tháng 5 năm

2003

Nguyễn Xuân Thanh



LỜI NÓI ĐẦU

Ngày nay với sự phát triển mạnh mẽ của tin học và công nghệ

Internet, hầu như mọi người đều thấy rõ lợi ích mà các dịch vụ do mạng

Internet mang lại.

Dịch vụ thư điện tử gọi tắt là Email là một trong nhưng dịch vụ được

sử dụng nhiều nhất trên Internet hiện nay. Dịch vụ này cho phép các cá

nhân hay tổ chức trao đổi thư với nhau thông qua mạng Internet. Nhiều

người sử dụng Internet chỉ để dùng dịch vụ này.

Thông thường, khi sử dụng dịch vụ thư tín điện tử, người sử dụng

thường ít khi quan tâm xem hệ thống bên trong đã thực hiện như thế nào.

Vì vậy, họ ( người sử dụng) mới chỉ thấy được một nửa của ứng dụng dịch

vụ Email và phần ứng dụng đó được gọi là Mail Client, hay là sử dụng dịch

vụ thư tín máy trạm.



Nhằm mục đích hiểu rõ hơn về hoạt động bên trong của ứng dụng

Email ở phần cung cấp dịch vụ mà thường được gọi là Mail Server, trong

cuốn đồ án này tôi xin trình bày một cách cơ bản hệ thống phục vụ việc

truyền thư tín điện tử trên cơ sở tìm hiểu về các mô hình truyền thông thư

tín, các giao thức truyền thông chuẩn, các hoạt động của một hệ Mail

Server.

Vì thời gian có hạn và có rất nhiều các vấn đề có liên quan, do đó đồ

án này chỉ trình bày những vấn đề cơ bản nhất về dịch vụ thư tín điện tử và

cài đặt một chương trình mang tính thử nghiệm do dịch vụ thư tín điện tử

mà thôi.

PHẦN 1 : CƠ SỞ LÝ THUYẾT



CHƯƠNG 1 : GIỚI THIỆU CHUNG VỀ INTERNET VÀ

MỘT SỐ GIAO THỨC TRUYỀN THÔNG TRÊN

INTERNET

1.1. GIỚI THIỆU CHUNG VỀ INTERNET

Mạng Internet là một tập hợp gồm hàng vạn hệ mạng trên khắp thế giới, được

phát triển vào thập kỷ bảy mươi. Số lượng máy tính nối mạng và số lượng người truy

cập vào mạng Internet trên toàn thế giới đang ngày càng tăng lên nhanh chóng, đặc

biệt từ năm 1993 trở đi. Mạng Internet không chỉ cho phép chuyển tải thông tin nhanh

chóng mà còn giúp cung cấp thông tin, nó cũng là diễn đàn và là thư viện toàn cầu đầu

tiên.

Mạng Internet có xuất xứ năm 1969 từ mạng máy tính toàn cục ARPANET do

cơ quan quản lý các dự án nghiên cứu các công trình nghiên cứu khoa học tiên tiến

thuộc Bộ Quốc phòng Mỹ (US Defense’s Advance Research Projects Agency - gọi tắt

là DARPA) tài trợ. Từ giữa năm 1970, trung tâm DARPA hướng tới mạng Internet với

kỹ thuật chuyển mạch gói qua mạng vô tuyến và thông tin vệ tinh. Năm 1980, DARPA

thử nghiệm dùng giao thức TCP/IP và đã được các trường đại học ở Mỹ ghép nối với

hệ điều hành UNIX BSD (Berkely Software Distribution).

Hệ điều hành UNIX là hệ phát triển mạnh với rất nhiều công cụ hỗ trợ và đảm

bảo các phần mềm ứng dụng có thể chuyển qua lại trên các họ máy khác nhau (máy

mini, máy tính lớn và hiện nay là máy vi tính). Bên cạnh đó hệ điều hành UNIX BSD

còn cung cấp nhiều thủ tục Internet cơ bản, đưa ra khái niệm Socket và cho phép

chương trình ứng dụng thâm nhập vào Internet một cách dễ dàng.

Cấu trúc mạng Internet gồm có:



Tầng ứng dụng: TELNET, FTP, SMTP;

Tầng giao vận: TCP, UDP;

Tầng Internet: Internet Protocol;

Tầng mạng: X.25, Ethernet, FDDI. . .;

Tầng vật lý: là các môi trường truyền tin khác nhau.

1.2. HỌ GIAO THỨC TCP/IP

TCP/IP là họ của các giao thức được sử dụng cho việc truyền thông máy tính.

Các chữ cái được viết tắt bởi các từ (Transmission Control Protocol/Internet Protocol),

hai giao thức này có cách biểu diễn khác nhau, người ta ít khi sử dụng với cái tên đầy

đủ của hai giao thức này. Thường các giao thức được nhóm lại thành các họ (đôi khi

còn được gọi là các suites hay các stacks). Các giao thức nào được nhóm lại với nhau

thường được xác định bởi các bộ cài đặt của giao thức.

Họ giao thức TCP/IP bao gồm các giao thức như là IP (Internet Protocol) , ARP

(Address Resolution Protocol), ICMP (Internet Control Message Protocol), UDP (User

Datagram Protocol), TCP (Transport Control Protocol), RIP (Routing Information

Protocol), Telnet, SMTP (Simple Mail Transfer Protocol), DNS (Domain Name

System) và một số các giao thức khác. Hình bên dưới mô tả kiến trúc của mạng

TCP/IP có so sánh với mô hình tham chiếu OSI để chúng ta hình dung được sự tương

ứng về chức năng của các tầng.



TCP/IP thực chất là một họ giao thức cùng làm việc với nhau để cung cấp

phương tiện truyền thông liên mạng. Trong phần này chúng ta sẽ xem xét giao thức IP,

giao thức TCP và một số ứng dụng ở tầng trên như Telnet, FTP, DNS, SMTP. . .

1.3. GIAO THỨC LIÊN MẠNG IP

Mục đích chính của IP là cung cấp khả năng kết nối các mạng con thành liên

mạng để truyền dữ liệu. Vai trò của IP tương tự vai trò của giao thức tầng mạng trong

mô hình OSI.

IP là một giao thức kiểu ”không liên kết” (connectionless) có nghĩa là không

cần có giai đoạn thiết lập liên kết trước khi truyền dữ liệu. Đơn vị dữ liệu dùng trong

IP được gọi là datagram, có khuôn dạng chỉ ra trong hình bên dưới.

ý nghĩa của các tham số như sau:

VER (4 bits): chỉ version hiện hành của IP được cài đặt

TCP/IP Protocol Suite OSI Model

Layers Application

Layer

Presentation Layer

Session Layer

Transport Layer

Network Layer

Data Link Layer

Physical Layer

TCP/IP Protocol Architecture

Layers

Application Layer

Host-to-Host Transport

Layer

Internet Layer

Network Interface

Layer

Telnet FTP SMTP DNS RIP SNMP

TCP

UDP

IP ARP IGMP ICMP

Ethernet Token Ring

Frame Relay

ATM

So sánh các kiến trúc ISO và TCP/IP



0 1 2 3 4 5 6 7

IHL (4 bits): chỉ độ dài phần đầu (Internet Header Length) của datagram, tính

theo đơn vị từ (word = 32 bits). Độ dài tối thiểu là 5 từ (20 bytes).

VE

R

IH

L

Type of Service Total Length

Indentification Fla

gs

Fragment

offset

Time to live Protocol Header Checksum

Source Address

Destination Address

Options + Padding

Data

(max: 65.535 bytes)

Type of service (8 bits): đặc tả các tham số về dịch vụ, có dạng cụ thể như sau:

Precedenc

e

D T R Reser

ved

trong đó:

Precedence (3 bits): chỉ thị về quyền ưu tiên gửi datagram, cụ thể là:

111 - Network Control (cao nhất) 011 - Flash

110 - Internetwork Control 010 - Immediate

101 - CRITIC/ECP 001 - Priority

100 - Flas Override 000 - Routine (thấp nhất)

D (Delay) (1 bit): chỉ độ trễ yêu cầu

D = 0 độ trễ bình thường

Header

0 3 4 7 8 15 16 31

Khuôn dạng của IP datagram



D = 1 độ trễ thấp

T (Throughput) (1 bit): chỉ thông lượng yêu cầu

T = 0 thông lượng bình thường

T = 1 thông lượng cao

R (Reliability) (1 bit): chỉ độ tin cậy yêu cầu

R = 0 độ tin cậy bình thường

R = 1 độ tin cậy cao

Total Length (16 bits): chỉ độ dài toàn bộ datagram, kể cả phần header (tính

theo đơn vị bytes).

Indentification (16 bits): cùng với các tham số khác (như Source Address và

Destination Address) tham số này dùng để định danh duy nhất cho một

datagram trong khoảng thời gian nó vẫn còn trên liên mạng.

Flags (3 bits): liên quan đến sự phân đoạn (fragment) các datagram, cụ thể là:

0 D

F

M

F

Bit 0: reserved - chưa sử dụng , luôn lấy giá trị 0

Bit 1 (DF) = 0 (May Fragment)

= 1 (Don’t Fragment)

Bit 2 (MF) = 0 (Last Fragment)

= 1 (More Fragment)

Fragment Offset (13 bits): chỉ vị trí của đoạn (fragment) ở trong datagram, tính

theo đơn vị 64 bits, có nghĩa là mỗi đoạn (trừ đoạn cuối cùng) phải chứa một

vùng dữ liệu có độ dài là bội số của 64 bits.

Time to live (8 bits): qui định thời gian tồn tại (tính bằng giây) của datagram

trong liên mạng để tránh tình trạng một datagram bị quẩn trên liên mạng. Thời

0 1 2



gian này được cho bởi trạm gửi và được giảm đi (thường qui ước là 1 đơn vị)

khi datagram đi qua mỗi router của liên mạng.

Protocol (8 bits): chỉ giao thức tầng trên kế tiếp sẽ nhận vùng dữ liệu ở trạm

đích (hiện tại thường là TCP hoặc UDP được cài đặt trên IP).

Header Checksum (16 bits): mã kiểm soát lỗi 16 bits theo phương pháp CRC,

chỉ cho vùng header.

Source Address (32 bits): địa chỉ của trạm nguồn.

Destination Address (32 bits): địa chỉ của trạm đích.

Options (độ dài thay đổi): khai báo các options do người gửi yêu cầu.

Padding (độ dài thay đổi): vùng đệm, được dùng để đảm bảo cho phần header

luôn kết thúc ở một mốc 32 bits.

Data (độ dài thay đổi): vùng dữ liệu, có độ dài là bội số của 8 bits, và tối đa là

65535 bytes.

Sơ đồ địa chỉ hoá để định danh các trạm (host) trong liên mạng được gọi là địa

chỉ IP 32 bits (32- bit- IP address). Mỗi địa chỉ IP có độ dài 32 bits được tách thành 4

vùng (mỗi vùng 1 byte), có thể được biểu thị dưới dạng thập phân, bát phân, thập lục

phân hoặc nhị phân. Cách viết phổ biến nhất là dùng ký pháp thập phân có dấu chấm

(dotted decimal notation) để tách các vùng. Mục đích của địa chỉ IP là để định danh

duy nhất cho một host bất kỳ trên liên mạng. Do tổ chức và độ lớn của các mạng con

(subnet) của liên mạng có thể khác nhau, người ta chia các địa chỉ IP thành 5 lớp, ký

hiệu là A, B, C, D và E, với cấu trúc được chỉ ra trong hình bên dưới.

0 1 7 8 15 16 23 24 31

netid

netid Hostid

netid hostid

hostid Lớp A

Lớp B

Lớp C

Lớp D

Lớp E



Multicast address

Reserved for future use

Cấu trúc của các lớp địa chỉ IP

Lớp A cho phép định danh tới 126 mạng, với tối đa 16 triệu host trên mỗi

mạng. Lớp này được dùng cho các mạng có số trạm cực lớn.

Lớp B cho phép định danh tới 16384 mạng, với tối đa 65534 host trên mỗi

mạng.

Lớp C cho phép định danh tới 2 triệu mạng, với tối đa 254 host trên mỗi mạng.

Lớp này được dùng cho các mạng có ít trạm.

Lớp D dùng để gửi IP datagram tới một nhóm các host trên một mạng.

Lớp E dự phòng để dùng trong tương lai.

Ví dụ:

00001

010

00000

000

00000

000

00000

000

10000

000

00000

011

00000

010

00000

011

11000

000

00000

000

00000

001

11111

111

Một địa chỉ có hostid (host identifier) bằng 0 được dùng để hướng tới mạng

định danh bởi vùng netid (network identifier). Ngược lại, một địa chỉ có vùng hostid

= 10.0.0.0 (Líp A) netid = 10

= 128.3.2.3 (Líp B) netid = 128.3 hostid = 2.3

= 192.0.1.255 (Lớp C) netid = 192.0.1 hostid = 255 hướng đến tất cả các host



0

0

31

31

(Lớp A)

(Lớp B)

(Lớp C)

gồm toàn số 1 được dùng để hướng tới tất cả các host nối vào mạng netid, và nếu vùng

netid cũng gồm toàn số 1 thì nó hướng tới tất cả các host trong liên mạng.

Trong nhiều trường hợp, một mạng có thể được chia thành nhiều mạng con

(subnet), lúc đó có thể đưa thêm các vùng subnetid để định danh các mạng con. Vùng

subnet được lấy từ hostid, cụ thể đối với 3 lớp A, B, C như sau (hình bên dưới).

Netid Subnetid Hostid

7 8 15 16 23 24

Netid Subnetid Hostid

7 8 15 16 23 24

Netid Subn

etid

Host

id

Bổ sung vùng subnetid

Cần lưu ý rằng các địa chỉ IP được dùng để định danh các host và mạng ở tầng

mạng của Mô hình OSI, và chúng không phải là các địa chỉ vật lý (hay địa chỉ MAC -

Media Access Control) của các trạm đó trên một mạng cục bộ (Ethernet,Token

Ring...). Trên một mạng cục bộ như vậy, hai trạm chỉ có thể liên lạc với nhau nếu

chúng biết địa chỉ vật lý của nhau. Như vậy, vấn đề đặt ra là phải thực hiện ánh xạ giữa

địa chỉ IP (32 bits) và địa chỉ vật lý (48 bits) của một trạm. Giao thức ARP (Address

Resolution Protocol) đã được xây dựng để chuyển đổi từ địa chỉ IP sang địa chỉ vật lý

khi cần thiết. Ngược lại, giao thức RARP (Reverse Address Resolution Protocol) được

dùng để chuyển đổi từ địa chỉ vật lý sang địa chỉ IP. Chú ý rằng cả ARP và RARP đều

không phải là bộ phận của IP. IP sẽ dùng đến chúng khi cần.

Một giao thức khác cũng liên quan trực tiếp đến IP, đó là ICMP (Internet Control

Message Protocol). Giao thức này thực hiện truyền các thông báo điều khiển (báo cáo



về các tình trạng lỗi trên mạng,...) giữa các gateway hoặc trạm của liên mạng. Tình

trạng lỗi có thể là: một datagram không thể tới được đích của nó, hoặc một router

không đủ bộ nhớ đệm để lưu và chuyển một datagram,... Một thông báo ICMP được

tạo và chuyển cho IP. IP sẽ ”bọc” (encapsulate) thông báo đó với một IP header và

truyền đến cho router hoặc trạm đích.

Chúng ta có thể tóm tắt các bước thực hiện bởi một thực thể IP như sau:

Đối với thực thể IP ở trạm nguồn, khi nhận được một primitive SEND từ

tầng trên , nó thực hiện các bước sau đây:

1. Tạo một IP datagram dựa trên các tham số của primitive SEND

2. Tính checksum và ghép vào header của datagram.

3. Ra quyết định chọn đường: hoặc là trạm đích nằm trên cùng mạng hoặc một

gateway sẽ được chọn cho chặng tiếp theo.

4. Chuyển datagram xuống tầng dưới để truyền qua mạng.

Đối với gateway, khi nhận được một datagram quá cảnh, nó thực hiện các

động tác sau:

1. Tính checksum, nếu bất cập thì loại bỏ datagram.

2. Giảm giá trị của tham số Time-to-Live. Nếu thời gian đã hết thì loại bỏ

datagram.

3. Ra quyết định chọn đường.

4. Phân đoạn datagram, nếu cần.

5. Kiến tạo lại IP header, bao gồm giá trị mới của các vùng Time-to-Live,

Fragmentation và Checksum.

6. Chuyển datagram xuống tầng dưới để truyền qua mạng.

Cuối cùng, khi một datagram được nhận bởi thực thể IP ở trạm đích, nó sẽ

thực hiện các công việc sau:

1. Tính checksum. Nếu bất cập thì loại bỏ datagram.

2. Tập hợp các đoạn của datagram (nếu có phân đoạn).



3. Chuyển dữ liệu và các tham số điều khiển lên tầng trên bằng cách dùng

primitive DELIVER.

1.4. GIAO THỨC ĐIỀU KHIỂN TRUYỀN TCP

Source Port Destination Port

Sequence Number

Acknowledgment Number

D

a

t

a

o

f

f

s

e

t

Reser

ved Window

Checksum Urgent Pointer

Options Padding

TCP data

Khuôn dạng của TCP segment.

TCP là một giao thức kiểu ”có liên kết” (connection - oriented), nghĩa là cần phải

thiết lập liên kết (logic) giữa một cặp thực thể TCP trước khi chúng trao đổi dữ liệu

với nhau.

Đơn vị dữ liệu sử dụng trong TCP được gọi là segment (đoạn dữ liệu), có khuôn

dạng mô tả trong hình bên dưới.

Các tham số trong khuôn dạng trên có ý nghĩa như sau:

bit 0 15 16 31



Source Port (16 bits): số hiệu cổng của trạm nguồn.

Destination Port (16 bits): số hiệu cổng của trạm đích.

Sequence Number (32 bits): số hiệu của byte đầu tiên của segment trừ khi bit

SYN được thiết lập. Nếu bit SYN được thiết lập thì Sequence Number là số

hiệu tuần tự khởi đầu (ISN) và byte dữ liệu đầu tiên là ISN+1. Tham số này

có vai trò như tham số N(S) trong HDLC.

Acknowledgment Number (32 bits): số hiệu của segment tiếp theo mà trạm

nguồn đang chờ để nhận. Ngầm ý báo nhận tốt (các) segment mà trạm đích đã

gửi cho trạm nguồn - Tham số này có vai trò như tham số N(R) trong HDLC.

Data offset (4 bits): số lượng từ - 32 bit (32 bit words) trong TCP header

(tham số này chỉ ra vị trí bắt đầu của vùng dữ liệu).

Reserved (6 bits): dành để dùng trong tương lai.

Control bits (các bit điều khiển):

Tư trái sang phải:

URG: vùng con trỏ khẩn (Urgent Pointer) có hiệu lực

ACK: vùng báo nhận (ACK number) có hiệu lực

PSH: chức năng PUSH

RST: khởi động lại (reset) liên kết

SYN: đồng bộ hoá các số hiệu tuần tự (sequence number)

FIN: không còn dữ liệu từ trạm nguồn

Window (16 bits): cấp phát credit để kiểm soát luồng dữ liệu (cơ chế cửa sổ).

Đây chính là số lượng các byte dữ liệu, bắt đầu từ byte được chỉ ra trong vùng

ACK number, mà trạm nguồn đã sẵn sàng để nhận.

Checksum (16 bits): mã kiểm soát lỗi (theo phương pháp CRC) cho toàn bộ

segment (header + data).



Urgent Pointer (16 bits): con trỏ này trỏ tới số hiệu tuần tự của byte đi theo sau

dữ liệu khẩn, cho phép bên nhận biết được độ dài của dữ liệu khẩn. Vùng này

chỉ có hiệu lực khi bit URG được thiết lập.

Options (độ dài thay đổi): khai báo các Options của TCP, trong đó có độ dài tối

đa của vùng TCP data trong một segment.

Padding (độ dài thay đổi): Phần chèn thêm vào header để bảo đảm phần header

luôn kết thúc ở một mốc 32 bits. Phần thêm này gồm toàn số 0.

TCP data (độ dài thay đổi): chứa dữ liệu của tầng trên, có độ dài tối đa ngầm

định là 536 bytes. Giá trị này có thể điều chỉnh bằng cách khai báo trong vùng

options.

Một tiến trình ứng dụng trong một host truy nhập vào các dịch vụ của TCP

cung cấp thông qua một cổng (port). Một cổng kết hợp với một địa chỉ IP tạo thành

một socket duy nhất trong liên mạng. Dịch vụ TCP được cung cấp nhờ một liên kết

logic giữa một cặp socket. Một socket có thể tham gia nhiều liên kết với các socket ở

xa khác nhau. Trước khi truyền dữ liệu giữa hai trạm cần phải thiết lập một liên kết

TCP giữa chúng và khi không còn nhu cầu truyền dữ liệu thì liên kết đó sẽ được giải

phóng. Cũng giống như ở các giao thức khác, các thực thể ở tầng trên sử dụng TCP

thông qua các hàm dịch vụ nguyên thuỷ (service primitives), hay còn gọi là các lời gọi

hàm (function calls).

CHƯƠNG 2 : CƠ SỞ VỀ LẬP TRÌNH MẠNG TRÊN MÔ

HÌNH CLIENT/SERVER

2.1. LẬP TRÌNH GIAO TIẾP MẠNG VỚI WINDOWS SOCKETS

Windows NT là một hệ điều hành mạnh, cho phép tận dụng tối đa khả năng của

máy tính loại 32 bit, cung ứng hàng loạt các dịch vụ mạng trên môi trường Intranet và



Internet. Hiện nay Windows NT được sử dụng tương đối phổ biến ở các cơ quan;

doanh nghiệp Việt Nam.

Giao thức truyền thông TCP/IP đã được dùng bởi hệ điều hành UNIX và mạng

Internet, để các máy trên mạng NT có thể giao tiếp với các máy trên mạng khác,

Windows NT cũng cung cấp giao thức này. Ngoài một số lệnh dùng giao thức TCP/IP

đã được viết sẵn như: ftp, telnet, finger..., Windows NT cho phép người lập trình phát

triển các ứng dụng khai thác kỹ thuật TCP/IP thông qua một thư viện tên là Windows

Sockets.

Có ba lý do chính để người lập trình sử dụng kỹ thuật TCP/IP:

Có thể viết các ứng dụng trên Windows NT để nối vào mạng UNIX và khai thác các

dịch vụ có sẵn trên đó.

Tạo ra các dịch vụ trên máy Windows NT để các máy UNIX có thể khai thác những

dịch vụ này.

Viết các chương trình cho phép các máy Windows NT giao tiếp trên hệ thống mạng

Internet.

2.2. MỘT SỐ KHÁI NIỆM CƠ BẢN

2.2.1.Địa chỉ Internet

Trong hệ thống mạng Internet, mỗi máy đều có một tên và một địa chỉ IP (cũng

gọi là địa chỉ Internet). Ví dụ như, một máy NT có tên là ntsvr.csc.hcmu.vn và địa chỉ

là 192.48.94.200. Tên hay địa chỉ IP đều xác định duy nhất một máy trong hệ thống

mạng Internet. Khi lập trình, chúng ta có các hàm để chuyển đổi từ tên sang địa chỉ IP

và ngược lại.

2.2.2. Khái niệm socket và port



Một socket là một thiết bị truyền thông hai chiều tương tự như tập tin, chúng ta

có thể đọc hay ghi lên nó, tuy nhiên mỗi socket là một thành phần trong một mối nối

nào đó giữa các máy trên mạng máy tính và các thao tác đọc/ghi chính là sự trao đổi

dữ liệu giữa các ứng dụng trên nhiều máy khác nhau.

Trong giao thức truyền thông TCP, mỗi mối nối giữa hai máy tính được xác

định bởi một port, khái niệm port ở đây không phải là một cổng giao tiếp trên thiết bị

vật lý mà chỉ là một khái niệm logic trong cách nhìn của người lập trình, mỗi port

được tương ứng với một số nguyên dương.

Hình bên dưới minh họa cách giao tiếp giữa hai máy tính trong giao thức truyền

thông TCP. Máy A tạo ra một socket và kết buộc (bind) socket này với port X (tức là

một số nguyên dương có ý nghĩa cục bộ trong máy A), trong khi đó máy B tạo một

socket khác và móc vào (connect) port X trong máy A.

2.3. CÁCH CÀI ĐẶT ỨNG DỤNG CLIENT/SERVER TCP

socket socket

MÁY A

MÁY B

Port Hệ thống mạng

Các socket và port trong mối nối TCP

Mối nối



2.3.1. Cách cài đặt server TCP

ứng dụng server làm việc theo qui trình sau đây:

1. Gọi hàm socket để tạo một socket.

2. Gọi hàm bind để kết buộc socket với một port, đối với mỗi giao thức ứng chuẩn thì

sẽ có một hằng số được định nghĩa sẵn trong Winsock cho port của giao thức đó.

3. Gọi hàm listen để chờ đến khi có một client nối vào port.

4. Khi có một client nối vào thì hàm listen trả điều khiển về, ứng dụng server gọi

hàm accept để xác nhận mối nối của client.

5. Gọi các hàm gửi hay nhận dữ liệu để trao đổi thông tin với client, ví dụ như hàm

send, recv.

Sau khi đã hoàn tất quá trình trao đổi dữ liệu, ứng dụng server gọi hàm closesocket để

đóng socket đã tạo.

2.3.2. Cách cài đặt client TCP

ứng dụng client thực hiện các bước sau:

1. Gọi hàm socket để tạo một socket.

2. Gọi hàm connect để nối vào server.

3. Gọi các hàm gửi hay nhận dữ liệu để trao đổi thông tin với server, ví dụ như

các hàm send, recv.

4. Sau khi đã hoàn tất quá trình trao đổi dữ liệu, ứng dụng client gọi hàm

closesocket để đóng socket đã tạo.

Hình minh họa các bước cần thiết để các ứng dụng client và server giao tiếp

với nhau như sau:



ứng dụng Server ứng dụng Client

Nối vào port của

server

Tạo một socket

Kết buộc socket

với một port (bind)

Đặt socket ở trạng thái chờ client nối

vào

Chấp nhận kết nối của client

Chuyển đổi dữ liệu giữa client và server

Tạo một socket

Các bước giao tiếp giữa client và server trong giao thức TCP



CHƯƠNG 3 : MỘT SỐ KHÁI NIỆM LIÊN QUAN ĐẾN

THƯ ĐIỆN TỬ

1.1. MAILSERVER

Theo mô hình hoạt động khách chủ, trình chủ là một dịch vụ đóng vai trò người

chủ phục vụ trình khách. Mail Server thật ra là một trình mở socket lắng nghe các yêu

cầu (hay lệnh gửi mail) từ trình khách đưa đến. Như đã nói, mail server sẽ tiếp nhận

nội dung mail, phân phối mail đến các trình chủ khác, cho phép trình khách truy cập

vào máy chủ để nhận mail về, bảo vệ mail…Chính vì vậy, trước khi nhận hay gửi mail

cần phải biết được địa chỉ IP của máy chủ mail server. Địa chỉ này thường được gọi là

mail host. Về khái niệm socket và địa chỉ IP sẽ được trình bày ở phần sau.

1.2. GIAO THỨC GỬI MAIL (MAIL TRANSPORT PROTOCOL)



Để gửi mail đến máy chủ, trình khách phải sử dụng một giao thức trò chuyện

với mail server. Tương tự trình duyệt dùng giao thức HTTP để trò chuyện với trình

chủ Web server. Các trình khách muốn bắt tay với trình chủ mail server và gửi mail

lên máy chủ sẽ sử dụng giao thức SMTP (Simple Mail Transport Protocol). SMTP

được hầu hết các mail server trên thế gới sử dụng. Địa chỉ IP của máy chủ nhận mail

gửi đi thường được gọi là outgoing mail address. Trình chủ thực hiện chức năng tiếp

nhận mail theo giao thức SMTP gọi là SMTP Server, trình khách dùng giao thức

SMTP để gửi mail đến trình chủ mail server gọi là SMTP Client.

1.3.GIỚI THIỆU KIẾN TRÚC DỊCH VỤ THƯ ĐIỆN TỬ

1.3.1. Kiến trúc và các dịch vụ

Các hệ thống thư điện tử thường bao gồm hai hệ thống con: các tác nhân người

sử dụng (the user agents - gọi tắt là UA), nó cho phép chúng ta đọc và gửi thư, và các

tác nhân truyền thông điệp (the message transfer agents - gọi tắt là MTA), nó làm

nhiệm vụ chuyển các thông điệp từ nguồn đến đích. Các UAs là các chương trình cục

bộ hỗ trợ dựa trên điều khiển bằng lệnh, trình đơn menu hay dùng phương pháp đồ hoạ

để tương tác với hệ thống thư điện tử. Các MTAs là các trình tiện ích hoạt động ở chế

độ nền (background) thực hiện các nhiệm vụ cần thiết như tiếp nhận thư điện tử và

chuyĨn thư qua các hệ thống.

Đặc biệt, các hệ thống thư điện tử hỗ trợ năm chức năng cơ bản, được mô tả dưới

đây:

1. Composition: Xử lý việc tạo các thông điệp và trả lời. Cho phép bất cứ

trình soạn thảo nào có thể được sử dụng cho phần thân của thông điệp, các

hệ thống có thể tự nó đảm trách việc đánh địa chỉ và chỉ số các trường tiêu

đề (header fields) được kèm theo cùng với mỗi thông điệp. Ví dụ như, khi

trả lời một thông điệp , hệ thống thư điện tử có thể tách địa chỉ của người

gửi từ các thư được gửi đến và tự động chèn nó vào các trường thích hợp

trong phần hồi âm (reply).



2. Transfer: Làm nhiệm vụ chuyển các thông điệp từ người gửi đến nơi người

nhận. Trong phần này, việc chuyển các thông điệp yêu cầu phải thiết lập

một kết nối đến đích (người nhận) hay một số thao tác của thiết bị như xuất

thông điệp và kết thúc việc kết nối. Hệ thống thư điện tử làm việc này một

cách tự động mà không cần có một sự can thiệp nào của người sử dụng.

3. Reporting: Buộc phải thực hiện để báo cho người gửi những gì xảy ra đối

với thông điệp vừa gửi là ở tình huấn đã gửi đến đích chưa? hoặc việc gửi đã

bị huỷ bỏ? hoặc thư đã bị lạc?.

4. Displaying: Những thông điệp gửi đến được yêu cầu làm sao để mọi người

có thể đọc được thư của họ. Đôi khi người ta yêu cầu quá trình chuyển đổi

hay một trình hiển thị đặc biệt để hỗ trợ, ví dụ như, nếu thông điệp có dạng

một tệp PostScript hay tiếng nói được số hóa kèm theo trong thông điệp gửi

đến.

5. Disposition: Là bước cuối cùng liên quan đến những gì người nhận thực

hiện đối với thông điệp sau khi đã nhận nó. Những khả năng có thể là ném

nó đi trước khi đọc, ném nó đi sau khi đọc, lưu nó, v ..v. Nó cũng sẽ có thể

thu nhận để đọc lại với các thông điệp đã được lưu lại, chuyển tiếp chúng

hoặc xử lý chúng bằng những phương pháp khác nhau khi được yêu cầu của

người sử dụng.

Thêm vào đó các dịch vụ này, hầu hết các hệ thống thư điện tử cung cấp nhiều

đặc tính nâng cao khác nhau. Một số đặc tính tiêu biểu như, khi người ta muốn chuyển

thư hay khi họ nghĩ xa hơn về các chi tiết về thời gian , có lẽ họ muốn thư của họ được

chuyển tiếp, chính vì thế mà hệ thống thực hiện điều này một cách tự động.

Hầu hết các hệ thống cho phép người sử dụng tạo các hộp thư (mailboxes) để

lưu trữ các thư chuyển đến (incoming email). Các lệnh được người ta yêu cầu tạo và

hủy bỏ các hộp thư, kiểm tra các nội dung hộp thư, chèn và xóa các thông điệp khỏi

hộp thư, v..v.

Những người giám đốc công ty thường cần gửi một thông điệp đến mỗi người

trong số những người cấp dưới, những khách hàng, hay đến các nhà cung cấp. Thì điều

này đưa ra một ý tưởng về danh sách thư (mailing list), nó là một danh sách các địa



chỉ thư điện tử. Khi một thông điệp được gửi đến mailing list, các bản sao giống hệt

được phát đến mọi người có địa chỉ trên danh sách.

Một ý tưởng quan trọng khác là thư điện tử được đăng ký, để cho phép người

gửi (sender or originator) biết thư của họ đã đến. Việc thông báo tự động của các thư

không được phát đi một cách luân phiên để người ta có thể biết. Trong bất kỳ trường

hợp nào, người gửi nên có một số điều khiển thông qua thông báo những gì xảy ra.

Các đặc tính nâng cao khác là đồng gửi (carbon copies), thư có mức ưu tiên cao

(high-priority email), bảo mật thư (secret email) có nghĩa là thông điệp được mã hóa

trước khi gửi đi, thay đổi người nhận thư (alternative recipients) nếu người đầu tiên

không có khả năng nhận được, và các khả năng cho các cô thư ký vận dụng thư của

các ông chủ của mình.

Hiện nay thư điện tử được sử dụng rộng rãi trong việc kinh doanh cho việc truyền

thông tin trong công ty. Nó cho phép các công nhân ở xa hợp tác về các dự án phức

(a) (b)

Envelope

Message

Bod

y

Mr. Daniel Dumkopf 18 Willow Lane White Plains, NY 10604

United Gizmo 180 Main St Boston, MA 02120 April, 5, 2001 Subject: Invoice 1081 Dear Mr. Dumkopf, Our computer records show that you still have not paid the above invoice of $0.00. Please send us a check for $0.00 promptly. Yous truly

United Gizmo

Name: Mr. Daniel Dumkopf Street: 18 Willow Lane State: NY Zip code: 10604 Priority: Urgent Encryption: None

From: United Gizmo Address: 180 Main St Location: Boston, MA 02120 Date: April, 5, 2001 Subject: Invoice 1081

Dear Mr. Dumkopf, Our computer records show that you still have not paid the above invoice of $0.00. Please send us a check for $0.00 promptly. Yous truly

United Gizmo

En

velo

pe

Hea

der

Phong thư và thông điệp (a) Thư bưu điện. (b) Thư điện tử



tạp, ngay cả những nơi phải mất nhiều thời gian mới đến được. Một số công ty đã đánh

giá rằng thư điện tử đã làm tăng năng suất sản xuất của họ lên 30 phần trăm (Perry and

Adam 1992).

Một khái niệm quan trọng trong tất cả các hệ thống thư điện tử hiện đại là sự

phân biệt giữa phong bì (envelope) và các nội dung bên trong của nó. Phong bì bao

bọc (encapsulate) cả thông điệp. Nó chứa tất cả các thông tin cần thiết cho việc truyền

tải thông điệp, như là địa chỉ đích, độ ưu tiên, và mức độ bảo mật , tất cả những cái đó

đều khác biệt với thông điệp bên trong nó. Các MTAs sử dụng phong bì cho việc định

tuyến đường truyền, điều này cũng giống như công việc của bưu điện làm.

Thông điệp ở bên trong phong bì chứa hai phần: phần đầu thư (header) và phần

thân thư (body). Phần header chứa các thông tin điều khiển cho các UAs. Phần thân là

phần hoàn toàn dành cho người nhận thư. Các phong bì và các thông điệp được mô tả

trong hình bên dưới.

1.3.2. Tác nhân người sử dụng (The User Agent)

Các hệ thống thư điện tử có hai phần cơ bản, như chúng ta đã thấy gồm: phần UA

và phần MTA. Trong phần này chúng ta sẽ xét đến phần UA. Một UA thường là một

chương trình (đôi khi được gọi là bộ phận đọc thư) nó nhận một trong những lệnh khác

nhau như là cho mục đích soạn thư, nhận thư, và hồi đáp các thông điệp, cũng như

việc thao tác trên các hộp thư (mailboxes). Một số UA (User Agent) có giao diện trình

đơn (menu) hay biểu tượng (icon) khá hấp dẫn mà nó yêu cầu sử dụng chuột hoặc chấp

nhận các lệnh 1 ký tự từ bàn phím có cùng chức năng với menu và các icon.

1.3.2.1.Gửi thư (Sending Email)

Để gửi đi một thông điệp, người sử dụng phải cung cấp thông điệp, địa chỉ đích

và một số tham số khác nếu có (ví dụ như là mức ưu tiên hay bảo mật). Người sử dụng



có thể tạo thông điệp với một trình soạn thảo văn bản khác nhau, một chương trình sử

lý từ hay với bộ soạn thảo được xây dựng trên UA. Địa chỉ đích phải có một định dạng

mà làm sao cho UA có thể hiểu được. Nhiều UA tiếp nhận các địa chỉ DNS (Domain

Name System) có dạng mailbox@location.

1.3.2.2. Đọc thư (Reading Email)

Khi UA được khởi động nó kiểm tra xem trong hộp thư của người sử dụng có thư

gửi đến không trước khi hiển thị các thứ khác lên màn hình. Khi đó có lẽ nó sẽ thông

báo một số các thông điệp trong hộp thư hay hiển thị một dòng vắn tắt của mỗi thông

điệp và chờ nhận lệnh để xử lý. Một ví dụ ở hình bên dưới cho thấy một viễn cảnh sau

khi UA khởi động hiển thị những yêu cầu vắn tắt của các thông điệp. Trong ví dụ này

hộp thư (mailbox) gồm có tám thông điệp.

Mỗi dòng hiển thị chứa một số trường được trích ra từ phong thư hay phần đầu

(header) của từng thông điệp được định vị trong hộp thư. Trong một hệ thống thư điện

tử đơn giản, sự lựa chọn của các trường hiển thị được người ta xây dựng thành một

chương trình. Trong các hệ thống phức tạp hơn, người sử dụng có thể xác định cho các

trường nào được hiển thị bằng cách cung cấp một hiện trạng người sử dụng (User

Profile), hay một tệp mô tả định dạng hiển thị. Trong ví dụ này, trường đầu tiên là số

thông điệp có trong hộp thư. Trường thứ hai, là các cờ có thể chứa một kí tự K, có

nghĩa là thông điệp cũ đã được đọc kỳ trước rồi và được lưu lại trong hộp thư; kí tự A

có nghĩa là thư này đã được hồi âm rồi; ký tự F (có thể có), có nghĩa là thư này được

chuyển tiếp đến người khác. Các cờ khác nữa cũng có thể được đưa vào ngoài những

cờ này.

# Flags Bytes Sender Subject

1 K 1030 Asw Changes to MINIX

2 KA 6348 Radia Comments on material you sent me



3 KF 4519 Amy N. Wong Request for information

4 1236 Bal Deadline for grant proposal

5 103610 Kaashoek Text of DCS paper

6 1223 Emily E. Pointer to WWW page

7 3110 Saniya Referee reports for the page

8 1204 Dmr Re: My student’s visit

Hiển thị các nội dung của hộp thư.

Trường thứ ba cho biết chiều dài của thông điệp và trường thứ tư cho biết ai là

người gửi thông điệp. Vì trường này được trích ra từ các thông điệp rất đơn giản nên

trường này có thể chứa các tên, họ tên đầy đủ, các tên viết tắt, các tên đăng nhập, hay

bất cứ thứ gì mà người gửi có thể đặt vào trong trường này. Cuối cùng là trường chủ

đề thư (Subject) cho biết một câu vắn tắt về những gì trong nội dung thông điệp.

Những người nào quên điền vào trường này thì thường được cho là những câu trả lời

cho thư của họ là không chú ý đến mức ưu tiên cao nhất.

Sau khi các phần đầu đã được hiển thị, người sử dụng có thể thực hiện bất cứ

lệnh nào có thể. Một chọn lựa tiêu biểu được liệt kê ở bảng bên dưới (hình bên dưới) là

một ví dụ khi một người sử dụng bằng hệ thống Mmdf của hệ điều hành UNIX. Có

một số lệnh yêu cầu có tham số. Ký hiệu # có nghĩa là chỉ số của một thông điệp (hay

có thể có nhiều thông điệp) được chấp nhận. Tương tự, mẫu tự a có thể được sử dụng

có nghĩa cho tất cả các thông điệp.

1.3.2.3.Định dạng thông điệp (Message Formats)



Chúng ta bây giờ hãy quay đến từ giao diện người sử dụng đến định dạng của

các thông điệp thư điện tử. Trước tiên chúng ta xét thư điện tử dựa trên bản mã ASCII

sử dụng chuẩn RFC 822 (Request for Comments). Sau đó xét đến các mở rộng đa

phương tiện cho chuẩn RFC 822.

1.3.2.4.Chuẩn RFC 822

Các thông điệp bao gồm một phong bì gốc (được mô tả trong chuẩn RFC 821),

một số các trường cho phần đầu (header), một dòng để trống và sau đó là phần thân

(body). Mỗi trường header bao gồm các dòng văn bản ASCII chứa tên trường, dấu hai

chấm, và cho hầu hết các trường đều có một giá trị. RFC 822 là một chuẩn cũ và giữa

các trường header của phong bì (envelope) không phân biệt rõ ràng như một chuẩn

mới khác. Khi sử dụng, thông thường UA xây dựng một thông điệp và đưa nó qua bộ

phận tác nhân truyền thông điệp (message transfer agents - MTA), ở đây nó dùng một

số các trường header để xây dựng một envelope thực sự, thông điệp được thay đổi bởi

cái cũ đi một chút cùng với envelope.

Command Parameter Description

H # Display header(s) on the screen

C Display current header only

T # Type message(s) on the screen

S Address Send a message

F # Forward message(s)

A # Answer message(s)

D # Delete message(s)

U # Undelete previously deleted message(s)



M # Move message(s) to another mailbox

K # Keep message(s) after exiting

R Mailbox Read a new mailbox

N Go to the next message and display it

B Backup to the previous message and display it

G # Go to a specific message but do not display it

E Exit the mail system and update the mailbox

Các lệnh điều khiển thư đặc biệt

Các trường header chủ yếu liên quan đến việc chuyển giao thông điệp được liệt

kê dưới bảng sau. Trường To: trường này cho biết địa chỉ DNS của người nhận đầu

tiên. Trường hợp nhiều người nhận cũng có thể cho phép. Trường Cc: cho biết địa chỉ

của những người nhận kế tiếp (còn gọi là địa chỉ đồng gửi). Trong các thuật ngữ của

việc phát thư, không có sự phân biệt giữa những người nhận thứ nhất và người nhận

thứ hai. Thuật ngữ Cc (Carbon copy) là một mẫu đã được xác định, vì máy tính không

sử dụng các trang giấy bản sao. Trường Bcc: (Blind carbon copy) giống như trường

Cc: chỉ trừ là dòng này được xóa khỏi tất cả các bản sao được gửi đến những người

nhận đầu tiên và người nhận thứ hai. Đặc tính này cho phép người ta gửi các bản sao

đến những người trong nhóm thứ ba mà trong đó không có người thứ nhất và người

thứ hai biết.

Header Meaning

To: Email address(es) of primary recipient(s)

Cc: Email address(es) of secondary recipient(s)



Bcc: Email address(es) for blind carbon copies

From: Person or people who created the message

Sender: Email address of the actual sender

Received: Line added by each transfer agent along the route

Return-Path: Can be used to identify a path back to the sender

Các trường header RFC 822 liên quan trong việc truyền thông điệp

Hai trường kế tiếp, From: và Sender: cho biết để phân biệt người viết và người

gửi thông điệp. Hai trường này hoàn toàn không giống nhau. Ví dụ một nhà quản trị

doanh nghiệp có thể viết một thông điệp nhưng cô thư ký là người thật sự truyền nó đi.

Trong trường hợp này, người quản trị phải được liệt kê vào trong trường From: và cô

thư ký trong trường Sender:.

Header Meaning

Date: The date and time the message was sent

Reply-To: Email address to which replies should be sent

Message-Id: Unique number for referencing this message latter

In-Reply-To: Message-Id of the message to which this is a reply

References: Other relevant Message-Ids

Keywords: User chosen keywords

Subject: Short summary of the message for the one-line display



Một số trường được sử dụng trong header thông điệp RFC 822.

Trường From: yêu cầu phải có còn trường Sender: có thể được bỏ qua nếu việc

viết và gửi cùng một người. Các trường này cần thiết khi trong trường hợp thông điệp

không được phát đi và phải được trả lại cho người gửi.

Dòng chứa trường Received: được đưa vào bởi các MTAs dọc theo đường

truyền. Dòng này chứa định danh của agent, ngày tháng và thời gian thông điệp được

nhận, và các thông tin khác có thể được sử dụng cho việc tìm kiếm các lỗi trong hệ

thống định tuyến.

Trường Return-Path: được đưa vào bởi MTAs cuối cùng và được dùng cho việc

gửi trở lại người gửi. Theo lý thuyết, thông tin này có thể được tập hợp lại từ các

header Received: (loại trừ tên của hộp thư người gửi), nhưng nó ít khi được điền đầy

đủ như thế và chỉ đặc biệt chứa địa chỉ của người gửi.

Thêm vào các trường của hình bên dưới các thông điệp RFC 822 cũng có thể

chứa một trong số các trường khác được sử dụng bởi các UA hay những người nhận

thư. Những trường thông thường nhất được liệt kê trong hình bên dưới. Hầu hết những

trường này có tính cách giải thích, vì thế chúng ta không đi sâu vào từng chi tiết.

1.4.PHÂN TÍCH CẤU TRÚC THƯ ĐIỆN TỬ, CÁC GIAO THỨC SMTP

VÀ POP3

1.4.1.Phân tích cấu trúc thư điện tử (RFC 822)

1.4.1.1. Giới thiệu



Để có thể chuyển giao thư giữa các máy tính trên mạng, thư cần phải được cấu

trúc theo một chuẩn nào đó. Thông thường, một bức thư được cấu tạo bởi hai phần là

phong bì (envelope) và nội dung (body). Khái niệm này hoàn toàn giống như trong hệ

thống bưu chính thông thường.

Trong khi phần phong bì chứa đựng những thông tin cần thiết để có thể thiết lập

các liên kết truyền thông và phân phát thư đi, thì phần nội dung lại chứa đựng những

thông tin về người gửi, ngày gửi,...

Thư thường bao gồm nhiều dòng văn bản. Nó không cung cấp những tính năng

riêng biệt như: mã hoá các hình vẽ, các bản sao, tiếng nói hoặc những văn bản có cấu

trúc. Hơn nữa, nó cũng không có sự quan tâm đặc biệt đối với việc nén dữ liệu, việc

truyền thông hoặc việc lưu trữ có hiệu quả.

Cấu trúc thư bao gồm một số trường thông tin tuân theo các cú pháp nghiêm

ngặt. Ví dụ như giữa phần tiêu đề thư (header) và phần nội dung thư (content) phải có

một dòng trống ngăn cách,...

1.4.1.2. Mô tả về cấu trúc thư

Một bức thư bao gồm các trường header và phần body. Phần body là các dòng

văn bản kí tự theo bảng mã ASCII. Nó được phân cách với phần header bởi một dòng

trống.

1.4.1.2.1. Các trường header dài

Mỗi trường header có thể được xem như một dòng văn bản các kí tự theo bảng

mã ASCII, cấu thành bởi tên trường (field-name) và nội dung của trường (field-body).

Để thuận tiện cho việc so sánh, phần field-body có thể được chia ra làm nhiều

dòng. Quá trình chia này được gọi là ”folding”. Ví dụ:

To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBN



có thể được thay thế bằng:

To: "Joe & J. Harvey" <ddd @ Org>,

JJV@BBN

và:

To: "Joe & J. Harvey"

<ddd@ Org>, JJV

@BBN

hay:

To: "Joe &

J. Harvey" <ddd @ Org>, JJV @ BBN

Quá trình thực hiện ngược lại để kết hợp nhiều dòng header đã được folding như

trên được gọi là: ”unfolding”. Unfolding được thực hiện bằng cách bỏ cặp kí tự CRLF

và thay bằng một dấu cách trống.

1.4.1.2.2. Các trường header có cấu trúc

Mỗi trường có cấu trúc bao gồm một field-name, tiếp theo là dấu hai chấm (”:”),

sau đó field-body và cuối cùng là cặp kí tự CRLF.

<field-name> : <field-body> <CRLF>

Phần field-name là các kí tự in được trong bảng mã ASCII (có mã từ 33 đến 126,

các kí tự số, ngoại trừ dấu hai chấm).

Phần field-body có thể chứa bất kì kí tự ASCII nào, ngoại trừ cặp kí tự CRLF.

Các trường thông tin header thực tế có thể được so sánh bởi các một vài hệ thống

thư tín. Các trường này được gọi là trường có cấu trúc. Ví dụ như các trường chứa

đựng thông tin về Date, Address,.v.v. Một số trường khác như ”Subject” và

“Comments” chỉ được coi như một dòng văn bản bình thường.



Chú ý, bất kỳ trường nào mà phần field-body được định nghĩa khác đi không

phải là một dòng văn bản đơn thuần thì được gọi là trường có cấu trúc.

1.4.1.2.3. Các trường header không có cấu trúc

Một số trường như “Subject” và “Comments” không được coi là các trường có

cấu trúc và chúng được xem như một dòng văn bản đơn thuần cũng như nội dung thư

trong phần body.

1.4.2. Định nghĩa về các trường Header

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 xoá 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: <[email protected]>

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ư.


250 OK

Trường hợp còn lại bị lỗi.

Ví dụ

S: RCPT TO: <[email protected]>

R: 250 OK

S: rcpt to: <[email protected]>

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

toàn bộ phần header của thư (như các trường Date, Subject, CC, From, ...)

cũng như nội dung thư.


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


R: 250 OK




R: 250 OK


R: 552 Recipient storage full, try again in another transaction

S: DATA


S: Blah blah blah...

S: ...etc. etc. etc.

S: .

R: 250 OK


R: 250 OK


R: 250 OK

S: DATA


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.

Sau đây là ví dụ về cách sử dụng thủ tục này:

S: RCPT TO:<[email protected]>

R: 251 User not local;

will forward to <[email protected]>

or

S: RCPT TO:<[email protected]>

R: 551 User not local;

please try <[email protected]>

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.


450 OK

b. Lệnh SOML FROM <reverse-path>


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>




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.

1.5.6. Các thủ tục Opening và Closing

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.


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.




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.

Nếu trong khoảng thời gian này có bất kì một lệnh nào từ phía Client, bộ xác

định thời gian sẽ được khởi tạo lại. Khi hết thời gian hiệu lực, phiên làm việc không

chuyển sang trạng thái UPDATE. Server sẽ đóng kết nối TCP mà không chuyển bất kì

một thư nào cũng như các thông tin phản hồi nào về phía Client.

Như vậy, ta thấy một phiên làm việc của POP3 phải trải qua ba trạng thái: trạng

thái AUTHORIZATION, trạng thái TRANSACTION và trạng thái UPDATE.



Phần tiếp theo sẽ trình bày chi tiết về sự hoạt động của POP3 Server trong từng

trạng thái của phiên giao dịch và các lệnh có thể thực hiện trong mỗi trạng thái đó.

1.6.3. Trạng thái AUTHORIZATION

Khi một phiên giao dịch POP3 được kích hoạt bởi một POP3 Client, POP3

Server sẽ gửi một thông báo cho phía Client. Tương tự như phần trình bày về giao

thức SMTP, ta cũng sử dụng Telnet để kích hoạt dịch vụ này. Một ví dụ có thể là:

S: +OK dewey POP3 server ready

Chú ý rằng, đây là thông tin phản hồi từ phía POP3 Server. Dấu ”+” có nghĩa là

thành công, ngược lại, dấu ”-” là không thành công bị lỗi. Phiên làm việc POP3 hiện

tại đang ở trạng thái AUTHORIZATION. Phía Client bây giờ cần phải đưa vào các

lệnh để xác định người nhận thư cho POP3 Server. Để thực hiện việc này, phía Client

sử dụng hai lệnh là USER và PASS. Đầu tiên, Client sử dụng lệnh USER với tham số

là account của người nhận.

Nếu thông tin phản hồi từ phía POP3 Server bắt đầu bằng dấu ”+” (+OK) thì

phía Client có thể gửi tiếp lệnh PASS với tham số là mật khẩu của người nhận để kết

thúc việc định danh hoặc cũng có thể gửi lệnh QUIT để kết thúc phiên giao dịch.

Trong trường hợp ngược lại, nếu thông tin phản hồi bắt đầu bằng dấu ”-” (-ERR)

cho lệnh USER thì phía Client có thể thực hiện lại việc định danh hoặc kết thúc phiên

giao dịch bằng lệnh QUIT.

Khi phía Client đưa vào lệnh PASS, POP3 Server sẽ sử dụng kết hợp hai đối số

đưa vào bởi hai lệnh USER và PASS để xác định xem người sử dụng này có tồn tại

hay không, có được quyền truy nhập vào mailbox hay không,.v.v

Sau khi đã xác định phía Client được quyền truy nhập, POP3 Server sẽ thực hiện

việc khoá mailbox để chống lại việc sửa đổi hoặc xoá thư trong mailbox từ các phiên

POP3 khác, trước khi chuyển sang trạng thái UPDATE.



Nếu như việc khoá mailbox thành công, phiên giao dịch POP3 sẽ chuyển sang

trạng thái TRANSACTION. Vào thời điểm này, chưa có một thư nào bị đánh dấu xoá.

Trong trường hợp ngược lại, nếu như vì một lý do nào đó không thể khoá được

mailbox (ví dụ như không được quyền truy nhập hoặc mailbox đã bị khoá,.v.v) thì

POP3 Server sẽ gửi một thông tin phản hồi ”-ERR” và kết thúc luôn phiên giao dịch.

Sau khi POP3 Server đã mở được mailbox, nó sẽ gắn chỉ số cho mỗi một bức thư

và tính luôn kích thước từng bức thư. Chỉ số được bắt đầu từ 1. Trong các lệnh của

POP3 và các thông tin phản hồi, tất cả các chỉ số và kích thước thư đều ở dạng cơ số

10.

Sau đây là một số lệnh có thể thực hiện trong trạng thái AUTHORIZATION:

a. Lệnh USER [name]

Tham số: là một xâu ký tự định danh của mailbox, duy nhất đối với Server.

Hạn chế: Chỉ có thể thực hiện trong trạng thái AUTHORIZATION vào thời

điểm ban đầu hoặc sau khi việc định danh USER và PASS không thành công.

Chi tiết: Lệnh này dùng để định danh người sử dụng.


+OK name is welcome here

-ERR Never heard of name

Ví dụ:

C: USER mrose

S: +OK mrose is a real hoopy frood

...

C: USER frated

S: -ERR sorry, frated doesn't get his mail here



b. Lệnh PASS [string]

Tham số: là một xâu ký tự định danh của mật khẩu tương ứng với mailbox.

Hạn chế: Chỉ có thể thực hiện trong trạng thái AUTHORIZATION vào thời

điểm ban đầu hoặc sau khi việc định danh USER thành công.

Chi tiết: Lệnh này dùng để xác định mật khẩu tương ứng với người sử dụng đã

định danh bằng lệnh USER.


+OK maildrop locked and ready

-ERR invalid password

-ERR unable to lock maildrop

Ví dụ:

C: USER mrose


C: PASS secret

S: +OK mrose’s maildrop has 2 messages

(320 octets)

...

C: USER mrose


C: PASS secret

S: -ERR unable to lock mrose’s maildrop, file

already locked

c. Lệnh QUIT

Tham số: không.



Hạn chế: không

Chi tiết: Lệnh này dùng để kết thúc phiên giao dịch.


+OK

Ví dụ:

C: QUIT

S: +OK dewey POP3 server signing off

1.6.4. Trạng thái TRANSACTION

Mỗi lần phía Client thực hiện thành công việc định danh với POP3 Server,

mailbox tương ứng sẽ được khoá và phiên làm việc bây giờ sẽ ở trạng thái

TRANSACTION.

Phía Client có thể sử dụng bất cứ một lệnh POP3 nào để thực hiện giao dịch với

POP3 Server. Các lệnh này có thể lặp lại mà không bị hạn chế gì cả. Sau mỗi lệnh,

phía POP3 Server sẽ gửi trả một thông tin phản hồi và kết quả thực hiện.

Cuối cùng, phía Client thực hiện lệnh QUIT để chuyển phiên giao dịch sang

trạng thái UPDATE.

Sau đây là một số lệnh có thể thực hiện trong trạng thái TRANSACTION:

a. Lệnh STAT

Tham số: không.

Hạn chế: Chỉ có thể thực hiện trong trạng thái TRANSACTION.

Chi tiết: Lệnh này dùng để lấy thông tin về số thư trong mailbox và kích thước

của mailbox tương ứng với người sử dụng. Cấu trúc của dòng thông tin phản

hồi này là: “+OK”, tiếp theo là một dấu cách trống, số lượng thư trong

mailbox và kích thước của mailbox tương ứng với người dùng đã xác định.




+OK nn mm

Ví dụ:

C: STAT

S: +OK 2 320

b. Lệnh LIST [msg]

Tham số: (có thể có hoặc không) là một số hiệu của thư trong số những thư

hiện có trong mailbox của người dùng. Lưu ý, những thư bị đánh dấu xoá sẽ bị

bỏ qua.


Chi tiết: Lệnh này dùng để liệt kê danh sách các thư có trong mailbox và kích

thước tương ứng hoặc lấy thông tin về một thư cụ thể nào đó. Trong trường

hợp không đưa vào tham số thì POP3 Server sẽ trả lại “+OK” và một danh

sách các thư và số hiệu tương ứng trong mailbox của người dùng. Trong

trường hợp ngược lại, có tham số, nếu tham số nằm trong khoảng cho phép từ

1 đến số thư thì POP3 Server sẽ trả lại “+OK” và số hiệu của thư và kích

thước tương ứng. Ngược lại, POP3 Server sẽ trả lại “-ERR”.


+OK scan listing follows

-ERR no such message

Ví dụ:

C: LIST

S: +OK 2 messages (320 octets)

S: 1 120

S: 2 200



S: .

...

C: LIST 2

S: +OK 2 200

...

C: LIST 3

S: -ERR no such message, only 2 messages in maildrop

c. Lệnh RETR [msg]

Tham số: Số hiệu của thư cần lấy.


Chi tiết: Lệnh này dùng để hiện thị nội dung thư tương ứng với số hiệu đưa

vào. Nếu thực hiện được POP3 Server sẽ gửi trả một thông tin phản hồi đa

dòng, bắt đầu bằng ”+OK”, tiếp theo là các dòng chứa đựng thông tin về nội

dung thư cũng như tiêu đề của thư được chọn. Trong trường hợp có lỗi, POP3

Server sẽ gửi trả ”-ERR”


+OK message follows


Ví dụ:

C: RETR 1

S: +OK 120 octets

S: <the POP3 server sends the entire message here>

S: .

d. Lệnh DELE [msg]

Tham số: số hiệu của thư cần xoá.



Hạn chế: chỉ có thể thực hiện trong trạng thái TRANSACTION.

Chi tiết: lệnh này dùng để xoá một thư tương ứng với số hiệu đưa vào. Nếu

thực hiện được, POP3 Server sẽ gửi trả một thông tin phản hồi bắt đầu bằng

”+OK”, tiếp theo là thông tin về thư đã bị xóa. Trong trường hợp có lỗi, POP3

Server sẽ gửi trả ”-ERR”. Lưu ý, POP3 Server chỉ thực hiện việc đánh dấu xoá

trên bức thư đó. Nó chỉ bị xoá thực sự sau khi phiên giao dịch chuyển sang

trạng thái UPDATE.


+OK message deleted


Ví dụ:

C: DELE 1

S: +OK message 1 deleted

...

C: DELE 2

S: -ERR message 2 already deleted

e. Lệnh NOOP

Tham số: không.


Chi tiết: lệnh này dùng để xác nhận kết nối với POP3 Server. POP3 Server

không làm gì cả mà chỉ gửi trả lại ”+OK” cho Client.


+OK

Ví dụ:

C: NOOP

S: +OK



f. Lệnh LAST

Tham số: không.

Hạn chế: chỉ được thực hiện trong trạng thái TRANSACTION.

Chi tiết: POP3 server đặt một trả lời xác định với dòng chứa số thông điệp cao

nhất hiện tại mà nó được truy cập trong maildrop. Trong trường hợp còn đang

ở trong trạng thái TRANSACTION mà các thư đã bị đánh dấu xóa chưa có

lệnh RSET thì số thư hiện có trong maildrop vẫn không thay đổi tính luôn cả

các thư đã được đánh dấu xoá.


+OK nn

VÝ dơ:

C: STAT

S: +OK 4 320

C: LAST

S: +OK 1

C: RETR 3

S: +OK 120 octets

S: <the POP3 server sends the entire message here>

S: .

C: LAST

S: +OK 3

C: DELE 2




C: LAST

S: +OK 3

C: RSET

S: +OK

C: LAST

S: +OK 1

g. Lệnh RSET

Tham số: không.


Chi tiết: lệnh này dùng để khôi phục lại những thư đã bị đánh dấu xóa. Nếu

thực hiện được POP3 Server sẽ gửi trả thông tin phản hồi ”+OK” để xác nhận

đã bỏ đánh dấu đối với những thư đã bị đánh dấu xóa. Trong trường hợp có

lỗi, POP3 Server sẽ gửi trả lời ”-ERR”


+OK

Ví dụ:

C: RSET

S: +OK maildrop has 2 messages (320 octets)

1.6.5. Trạng thái UPDATE

Khi phía Client thực hiện lệnh QUIT đang ở trong trạng thái TRANSACTION.

phiên giao dịch POP3 sẽ chuyển sang trạng thái UPDATE.

Lưu ý rằng nếu lệnh QUIT được thực hiện trong trạng thái AUTHORIZATION

thì phiên giao dịch POP3 không chuyển sang trạng thái UPDATE.



Nếu một phiên giao dịch bị kết thúc vì một lý do nào đó mà không phải do phía

Client thực hiện lệnh QUIT thì phiên giao dịch POP3 cũng không chuyển sang trạng

thái UPDATE và cũng không thực hiện việc xóa bất kỳ một thư nào từ mailbox.

Lệnh QUIT

Tham số: không.

Hạn chế: không.

Chi tiết: Lệnh này dùng để kết thúc phiên giao dịch một cách hợp lệ. POP3

Server sẽ xóa vật lý tất cả thư đã bị đánh dấu xóa trong mailbox. Sau đó, nó sẽ

gỡ bỏ khóa đối với mailbox đó và có một thông tin phản hồi để xác nhận thao

tác này. Kết nối TCP sẽ kết thúc.


+OK

VÝ dơ:

C: QUIT

S: +OK dewey POP3 server signing off (maildrop empty)

...

C: QUIT

S: +OK dewey POP3 server signing off (2 messages left)

...

1.6.6. Ví dụ về một phiên giao dịch POP3

S: <wait for connection on TCP port 110>

...

C: <open connection>

S: +OK dewey POP3 server ready(Comments to:



[email protected])

C: USER mrose


C: PASS secret

S: +OK mrose's maildrop has 2 messages (320 octets)

C: STAT

S: +OK 2 320

C: LIST

S: +OK 2 messages (320 octets)

S: 1 120

S: 2 200

S: .

C: RETR 1

S: +OK 120 octets

S: <the POP3 server sends message 1>

S: .

C: DELE 1


C: RETR 2

S: +OK 200 octets

S: <the POP3 server sends message 2>

S: .

C: DELE 2


C: QUIT

S: +OK dewey POP3 server signing off (maildrop empty)

C: <close connection>



S: <wait for next connection>

1.7. MIME (MULTIPURPOSE INTERNET MAIL EXTENSIONS)

Là các quy định về định kiểu và cấu trúc dữ liệu do nội dung mail để nó có thể

chứa được các loại tài liệu phức hợp khác nhau như: hình ảnh, âm thanh, file nhị

phân…MIME còn được biết đến như một giao thức Internet mới mẻ được phát triển để

cho phép trao đổi các thông điệp thư điện tử có nội dung phong phú thông qua mạng

không đồng nhất (heterogeneous network), máy móc, và các môi trường thư điện tử.

Trong thực tế, MIME cũng đã được sử dụng và mở rộng bởi các ứng dụng không phải

thư điện tử. Hiện nay, trên mạng diện rộng Internet, đối với RFC 822 chỉ làm những

công việc định nghĩa các header nhưng còn nội dung bên trong thì vẫn còn lỗi thời,

chính vì thế mà vấn đề này không còn thích hợp nữa. Các vấn đề bao gồm việc gửi và

nhận thư như sau:

1. Những thông điệp sử dụng các ngôn ngữ có dấu.

ví dụ: Tiếng Pháp và tiếng Đức.

2. Những thông điệp sử dụng các ngôn ngữ không phải chữ cái Latin.

ví dụ: Tiếng Do thái, tiếng Nga. . .

3. Những thông điệp sử dụng các ngôn ngữ không có trong các bảng chữ cái.

ví dụ: Tiếng Trung Quốc, tiếng Nhật. . .

4. Những thông điệp sử không chứa văn bản.

ví dụ: Có âm thanh và hình ảnh.

Một giải pháp đã được đưa ra trong RFC 1341 và được cập nhật mới nhất trong

RFC 1521. Giải pháp này được gọi là MIME, hiện nay được sử dụng rộng rãi.

Khái niệm cơ bản của MIME là tiếp tục sử dụng định dạng RFC 822, nhưng

thêm cấu trúc vào phần thân của thông điệp và định nghĩa các nguyên tắc mã hóa các

thông điệp không phải các bảng mã ASCII. Để khỏi bị lệch hướng của RFC 822, các

thông điệp MIME có thể được gửi đi được sử dụng các giao thức và chương trình thư



hiện có. Tất cả các chương trình này phải được thay đổi thành các chương trình gửi và

nhận sao cho người dùng có thể dùng được.

MIME định nghĩa năm header thông điệp mới được trình bày trong hình bên

dưới. Các header này trước tiên báo cho UA nhận thông điệp mà nó đang dùng bằng

thông điệp MIME và phiên bản của MIME đang dùng. Bất cứ thông điệp nào không

chứa header MIME-Version: được giả định là một thông điệp hình thức được mã hóa

bằng tiếng Anh và nó được xử lý như thế.

Header Meaning

MIME-Version: Indentifies the MIME version

Content-Description: Human-readable string telling what is in the message

Content-Id: Unique identifier

Content-Transfer-Encoding: How the body is wrapped for transmission

Content-Type: Nature of the message

Các header RFC 822 được MIME thêm vào.

Bảy kiểu chính mô tả MIME được định nghĩa trong RFC 1521, mỗi kiểu của nó

lại có một hay nhiều kiểu phụ. Kiểu chính và kiểu phụ (xem hình bên dưới) được phân

biệt bởi một dấu vạch chéo, như có dạng sau: Content-Type: video/mpeg

Type Subtype Description

Text Plain Unformatted text

Richtext Text including simple formatting commands

Image Gif Still picture in GIF format



Jpeg Still picture in JPEG format

Audio Basic Audible sound

Video Mpeg Movie in MPEG format

Applicatio

n

Octel-stream An uninterpreted byte sequence

Postscript A printable document in Postscript

Message

Rfc 822 A MIME RFC 822 message

Partial Message has been split for transmission

External-body Message itself must be fetched over the net

Multipart

Mixed Independent parts in the specified order

Alternative Same message in different formats

Parallel Parts must be viewed simultaneously

Digest Each part is a complete RFC 822 message

Các kiểu chính và kiểu phụ được định nghĩa trong RFC 1521

1.8.POP BEFORE SMTP(CHỨNG THỰC QUYỀN TRUY CẬP THEO

GIAO THỨC POP TRƯỚC KHI SỬ DỤNG SMTP)

Để tránh tình trạng các máy chủ mail server bị lạm dụng gửi mail ồ ạt hay còn

gọi là “bom thư”, cơ chế POP before SMTP yêu cầu máy khách muốn sử dụng dịch vụ

mai của máy chủ trước hết phải đăng nhập vào tài khoản(account) theo giao thức POP.

Nếu quá trình đăng nhập thành công, cơ chế gởi mail bằng SMTP mới có thể diễn ra

tiếp theo.



1.9.MAIL CLIENT, WEB MAIL

Đây là các chương trình thường được dùng nhất trong quá trình gửi, nhận, đọc

mail. Những chương trình ứng dụng thuộc dạng mail client có rất nhiều ví dụ như

:Outlook Express, Netscap Communicator…nếu chương trình mail client được viết

dưới dạng giao diện Web sẽ được gọi là Web mail. Thật ra Web mail tương tác khó

khăn hơn các ứng dụng mail client thông thường vì phải dựa voà trình chủ Web

Server. Tuy nhiên ưu điểm của Web mail là bạn có thể truy cập mail được ở mọi lúc

mọi nơi, bất cứ khi nào kết nối được vào Internet.

CHƯƠNG 4 : GIỚI THIỆU VỀ CÁC CÔNG NGHỆ LIÊN

QUAN

2.1.GIỚI THIỆU VỀ JRUN WEBSERVER 3.1

JRun là ứng dụng trình chủ Java (Java Web Server) nhằm phực vụ

những công nghệ mới nhất của Java như Servlet/JSP và ẸB. Mặc dù hiện nay có rất

nhiều trình chủ Web dành cho Java như Java Web Server, Web Logic,

Apache,…Trong đề tài này tôi sẽ ứng dụng JRun Web Server chạy trên môi trường

Windows NT/2000, do JRun được viết bằng Java nên ta có thể sử dụng và cài đặt JRun

cả trên môi trường Linux lẫn Unix.

JRun không chỉ đơn thuần là một trình chủ Web mà còn có các tính năng

kết hợp với các trình chủ Web khác như IIS của Windows hay Apache



2.2.GIỚI THIỆU VỀ SQL SERVER 7.0

2.2.1. Lý thuyết hệ quản trị cơ sở dữ liệu sql server 7.0 và Cấu trúc cơ sở

dữ liệu của sql server 7.0

SQL Server tổ chức dữ liệu lưu trong Cơ sở dữ liệu(CSDL) thành những thành

phần logic. User làm việc trên những thành phần logic này như bảng (table), view,

procedure… Thành phần vật lý của những file thì trong suốt (transparent), chỉ có

người quản lý Cơ sở dữ liệu mới được làm việc trên đó.

SQL Server có 4 cơ sở dữ liệu hệ thống ( master, msdb, model, temdb database

) và các cơ sở dữ liệu của user. Hình minh họa

Master database: Ghi lại cấu hình hệ thống của SQL Server. Nó ghi lại tất cả tài

khoản đăng ký của user và cấu hình hệ thống, những file primary chứa thông tin

khởi động của Cơ sở dữ liệu của user, chứa thông tin khởi động của SQL Server.

Những thao tác sau gây ra những thay đổi trong master database:Tạo , thay đổi, xóa

cơ sở dữ liệu,thay đổi transaction log. Thêm hay xóa của những sever sử dụng thủ

tục hệ thống như sp-addserver (thêm server) and sp-dropserver (bỏ server).

Temdb database: chứa những bảng tạm và những stored procedure tạm. Những

bảng tạm và những stored procedure của user khi nối kết vào hệ thống được lưu



trong temdb database. Khi SQL khởi động thì tất cả các bảng tạm và các stored

procedure trong temdb database đều mất.

Stored procedure: là 1 tập hợp biên dịch trước của những câu lệnh của Transact-

SQL được lưu và xử lý như 1 đơn vị (unit). Stored procedure sẵn sàng cho việc

quản lý SQL Server và hiển thị thông tin của cơ sở dữ liệu, của những người sử

dụng. SQL Server cung cấp những stored procedure gọi là stored procedure hệ

thống.

Model database: được dùng như 1 khuôn mẫu của CSDL trong hệ thống. Khi tạo

ra 1 CSDL thì phần đầu của CSDL là bản sao của model database, phần còn lại là

những trang trống.

Msdb database: SQL Server Agent dùng msdb database để lập kế hoạch alert,

job. Alert là 1 định nghĩa của người sử dụng đáp ứng 1 sự kiện của SQL Server.

Alert có thể thực thi cả nhiệm vụ định nghĩa hoặc gởi e-mail đến 1 người chỉ định.

Job là sự thực hiện 1 hành động quản lý chứa 1 hoặc nhiều bước, thay thế cho

thuật ngữ task của SQL Server 6.5.

2.2.2. Cấu trúc cơ sở dữ liệu vật lý:

2.2.2.1. Trang (page):



Đơn vị cơ bản lưu trữ dữ liệu là trang (page). Trong SQL Server 7.0 , 1 trang có

kích thước 8MB, ta sẽ có 128 trang/1MB. 96 byte đầu của mỗi trang chứa header của

trang gồm thông tin hệ thống như loại trang, số vùng trống của trang.

Cấu trúc trang dữ liệu: Các hàng dữ liệu (data row) được đưa vào tuần tự ngay

sau page header, row offset được bắt đầu từ cuối trang, chỉ đến data row và cho biết

byte bắt đầu của data row, kích thước hàng tối đa là 8060 byte.

2.2.2.2 .Extent:

Extent là đơn vị cơ bản chỉ vùng lưu bảng và index. Mỗi extent gồm 8 trang

liên tục nhau. Có 2 loại extent:

Mixed extent có thể lưu những đối tượng khác nhau.

Uniform extent chỉ có thể lưu 1 đối tượng duy nhất.

2.2.2.3 Những loại file trong CSDL:SQL Server có 3 loại file:

Primary file: là file bắt đầu của cơ sở dữ liệu. Mỗi cơ sở dữ liệu chỉ có 1 file

primary, tên file có phần mở rộng là .mdf

Secondary file: là file lưu những gì còn lại của cơ sở dữ liệu mà không chứa trong

primary file, có thể có nhiều file secondary, tên file có phần mở rộng là .ndf.

Log file: chứa những thông tin transaction log, được dùng để khôi phục cơ sở dữ

liệu, mỗi cơ sở dữ liệu có ít nhất 1 log file, tên file có phần mở rộng là .ldf.

File của SQL Server có 2 tên:

Logical_file_name: là tên dùng trong những câu lệnh Transact_SQL.



Os_file _name: là tên file vật lý, chỉ rõ đường dẫn của file

MyDB_primary là tên logical_file_name, c:\Mssql7\Data\MyData1.mdf là tên

os_file_name.

Những trang trong file được đánh số bắt đầu từ 0. Mỗi file có 1 số ID. Mỗi

trang trong file gồm cả ID file và số thứ tự trang trong file.

Ví dụ: file primary có kích thước 4MB, và secondary có kích thứơc 1 MB.

Trang đầu tiên trong mỗi file là trang header file chứa thông tin về thuộc tính của file.

Trang thứ 9 trong primary file là trang khởi động cơ sở dữ liệu chứa thông tin về thuộc

tính của cơ sở dữ liệu.

2.3. LÝ THUYẾT MÔ HÌNH QUAN HỆ

2. 3.1. Các khái niệm cơ bản

Thực thể: là một đối tượng cụ thể nào đó

Thuộc tính thực thể: Tính chất xác định thực thể

Lớp thực thể : Các thực thể có cùng thuộc tính

Lược đồ quan hệ:

Thuộc tính: Tên thuộc tính, miền xác định của thuộc tính

Lược đồ quan hệ gồm các thuộc tính của thực thể (tên, miền xác định) cùng với

các mệnh đề ràng buộc

Lược đồ của một quan hệ: R=< x, v>= (A1: D1’ A2 : D2 ,……,An :Dn , M)

trong đó: AI :Tên thuộc tính, DI :Miền xác định của thuộc tính,M: Mệnh đề ràng buộc

2.3.2. Khái Niệm phụ thuộc dữ liệu và các dạng chuẩn



Một thuộc tính gọi là phụ thuộc vào các thuộc tính khác khi giá trị của thuộc tính

này phụ thuộc vào giá trị của thuộc tính kia. Sự phụ thuộc có thể là trực tiếp hay

gián tiếp.

Một quan hệ bao giờ cũng có một nhóm thuộc tính mà giá trị của chúng qui định

giá trị của các thuộc tính khác, nhóm thuộc tính đó gọi là khóa.

Với một quan hệ tùy vào các phụ thuộc của các thuộc tính vào khóa trong đó mà ta

phân chia các quan hệ đó thành các dạng chuẩn khác nhau. Các dạng chuẩn cơ bản:

Dạng chuẩn 1

Dạng chuẩn 2

Dạng chuẩn 3

Các dữ liệu lưu giữ dưới dạng chuẩn 3 tránh được hiện tượng dư thừa dữ liệu,

tạo cho dữ liệu có tính độc lập cao. Các quan hệ nếu chưa ở dạng chuẩn 3 sẽ được

phân rã thành các quan hệ nhỏ hơn ở dạng chuẩn 3.

2.3.3 Khái niệm chỉ dẫn và khóa chỉ dẫn

Để có thể tìm kiếm thông tin nhanh theo một tiêu chuẩn nào đó chúng ta tạo ra

các thông tin chỉ dẫn theo tiêu chuẩn đó. Các thông tin chỉ dẫn là các thông tin giúp ta

tìm kiếm dữ liệu nhanh. Các thông tin này gọi là khóa chỉ dẫn . Khóa chỉ dẫn có thể là

một trường, hoặc nhiều trường ï.

Với cách tạo ra khóa chỉ dẫn theo tiêu chuẩn nào đó ta có thể tìm kiếm nhanh dữ

liệu theo tiêu chuấn đó.

2.4.GIỚI THIỆU VỀ JAVA SERVLET

2.4.1.Khái niệm về JAVA SERVLET



Mã nguồn của Servlet dược biên dịch ra mã byte – code của Java. Servlet dễ sử

dụng và phát triển những ứng dụng Web nhanh hơn CGI. Servlet chạy tự động khi

chúng được gọi từ trình chủ (Web server) .

Servlet chạy toàn bộ trên máy ảo Java, xử lý và sinh mã HTML trả về trình

khách. Bằng cách này Servlet có thể chạy trên rất nhiều trình chủ hiểu Java và chúng

không phụ thuộc và trình duyệt (browser).

2.4.2.Những ứng dụng thực tế của JAVA SERVLET và kiến trúc của

JAVA SERVLET

Servlet có thể được sử dụng trong bất kỳ một ứng dụng nào liên quan đến Web.

Hai gói tạo nên kiến trúc của Java Servlet là : javax.servlet và javax.servlet.http. Gói

javax.servlet chứa đựng phần giao diện tổng quát phục vụ cho Servlet.

javax.servlet.http chứa đựng các lớp phục vụ cho giao thức triệu gọi HTTP. Bộ khung

hình thành nên Servlet bao gồm các phương thức sau:

init() Phương thức khởi tạo servlet.

service() Phương thức nhận và trả lời từ phía người sử dụng.

destroy() Phương thức thực hiện việc huỷ servlet.

Các tập tin Servlet đều được đặt trong giao diện bao gồm các phương

thức trên. Chúng rất rõ ràng trong giải pháp lập trình đối tượng và dễ dàng mở rộng.

2.5.GIỚI THIỆU VỀ JAVA SERVER PAGES(JSP)

2.5.1.Khái niệm về JSP

JSP là công nghệ rất mạnh để tạo trang HTML động về phía trình chủ.

JSP là phần mở rộng trực tiếp của Java Servlet, bộ diễn dịch JSP sẽ ánh xạ trực tiếp mã



JSP thành Servlet. Viết trang JSP ta không cần phải thông qua quá trình biên dịch tập

tin thực thi .class như trong Servlet. JSP cung cấp mô hình lập trình Web dễ dàng và

tiện dụng hơn Servlet. Công việc biên dịch trang JSP được thực hiện tự động bởi trình

chủ.

2.5.2.Quan hệ giữa Servlet và JSP

2.5.2.1.Cách trình chủ biên dịch trang JSP thành servlet

Thật sự các trang JSP được trình chủ dịch ra thành servlet trước

khi cho thực thi. Khi trình khách triệu gọi trình chủ Web server sẽ thực hiện các bước

sau:

Bước 1: Kiểm tra trang JSP đã được dịch ra thàn mã nguồn tương

đương của servlet chưa.

Bước 2 : Nếu chưa biên dịch trang JSP thành file nguồn thành file

nguồn .java theo cấu trúc của servlet. Gọi trình biên dịch javac biên dịch file nguồn

.java thành file thực thi của servlet .class.

Bước 3 : Nạp servlet đã biên dịch ở bước 2, thực thi kết quả trả về

cho trình khách.

Bước 4 :Nếu file JSP đã được biên dịch trước đó : thực hiện việc

kiểm tra xem nội dung file JSP có thay đổi hay không. Nếu có, quay lại bước 2 biên

dịch lại trang. Nếu không thực hiện lại bước 3.

2.5.2.2. So sánh giữa Servlet và JSP

Do mã trang JSP thi thực thi đều được biên dịch ra servlet

cho nên tất cả những gì servlet làm được cũng đồng nghĩa với trang JSP làm được.

Viết trang JSP đôi khi đơn giản hơn trang servlet vì không cần phải qua bước đăng ký

và biên dịch thủ công.

JSP có thể trộn lẫn mã java với các thẻ HTML nên việc

thiết kế trang JSP thường đơn giản và dễ bổ sung hơn so với servlet. Tuy nhiên đây

cũng là yếu tố không nên lạm dụng đối với JSP. Nếu tập trung tất cả mã Java vào cùng

với mã HTML thì một khi dự án mở rộng và trở nên phức tạp tất nhiên việc bảo trì và



nâng cấp ứng dụng Web với hàng trăm trang JSP sẽ rất khó khăn. Trong quá trình phát

triển ứng dụng Web theo nhóm, việc trộn lẫn mã Java và HTML trong trang JSP cho

thấy không hiệu quả. Khó có thể tách rời giữa công việc viết mã cho ứng dụng (thường

là vai trò của lập trình viên – programmer) và nhóm xây dựng giao diện (nhóm thiết kế

Web – Web designer). Mã trang JSP ở dạng thuần văn bản nên thường không che

được mã nguồn của logic chương trình.

Với servlet tuy phải biên dịch và đăng ký thủ công với

trình chủ nhưng bù lại tính bảo mật cao hơn. Ta chỉ cần cung cấp cho trình chủ Web

Server bản servlet nhị phân ( file .class ) đã qua bước biên dịch mà không cần đến mã

nguồn của servlet ban đầu. Mặt khác, các servlet có thể tương tác liên hoàn với nhau

để tạo nên những kết xuất tuỳ biến và đa dạng trước khi trả kết quả về cho trình khách.

Servlet có thể phân rã các đơn thể của dự án và phát triển độc lập nhau như các thành

phần riêng biệt để ráp lại trong một tổng thể chung. Mặc dù vậy, việc kết xuất trong

servlet thường dựa vào phương thức print() hoặc println() nên việc kết xuất phụ thuộc

vào lập trình viên với hàng loạt các lệnh print() và println() rất khó quản lý.

Việc quyết định sử dụng trang JSP, Servlet hay kết hợp cả

hai là tùy vào từng dự án và mục đích của chương trình cần phát triển. Thông thường

đối với những dự án nhỏ, yêu cầu thời gian nhanh, JSP là lựa chọn thích hợp nhất. Đối

với những dự án cần sự độc lập và chỉ thiên về xử lý ta nên sử dụng servlet. Trường

hợp dự án lớn ta nên kết hợp cả servlet và JSP. Mô hình kết hợp tốt nhất giữa servlet

và JSP thường được gọi là MCV (Model – View – Controler) trong đó servlet đóng vai

trò trung tâm điều khiển (controler) đưa ra quyết định xử lý, JSP đóng vai trò thể hiện

giao diện hay hiển thị dữ liệu đã xử lý (View). Quy trình tính toán logic của ứng dụng

được giao lại cho các thành phần JavaBean hay EJB.

2.6. GIỚI THIỆU VỀ JAVABEANS

2.6.1.Khái niệm về JAVABEANS



JavaBeans là một thành phần đối tượng được xây dựng từ ngôn ngữ

Java. JavaBeans có thể là việc và chạy trên mọi máy ảo Java. Yêu cầu tối thiểu nhất để

tạo nên thành phần JavaBeans là : công cụ và trình biên dịch JDK 1.1 trở lên.

JavaBeans có thể sử dụng các phương thức get/set để láy về và đặt thuộc tính cho đối

tượng Bean mà nó thể hiện.

2.6.2.Các thẻ chuẩn của JAVABEANS trong trang JSP

2.6.2.1.<jsp:useBean>

Thẻ <jsp:useBean> dùng để khai báo phạm vi và định danh

id(identify) nhận dạng Bean. Nó tương tự như khai báo biến đối tượng trong mã java.

Thẻ <jsp:useBean> có cú pháp như sau:

<jsp:useBean id=”name”

scope=”page | request | session | application”

class=”packagename.classname”>

Thuộc tính Diễn giải

Id Thuộc tính này là định danh nhận dạng của đối tượng Bean trong một

phạm vi cho trước. “name” là tên của Bean có phân biệt chữ hoa,

thường.

Scope Thuộc tính phạm vi cho biết môi trường sống của đối tượng. Phạm vi

của khai báo mà thành phần Bean có hiệu lực bao gồm page (Bean

chỉ có hiệu lực và phạm vi truy xuất trong khai báo nó). Request

(Bean có hiệu lực trong một lần yêu cầu từ máy khách). Session (hiệu

lực của bean tương tự hiệu lực của các biến session). Application

(hiệu lực của bean tương tự hiệu lực của các biến application)



Class Tên đầy đủ của lớp Bean. Đây là tên tập tin .class sua khi đã biên

dịch từ mã nguồn .java. tên này cũng phân biệt chữ hoa và chữ

thường

BeanName Này để tham chiếu đến tên của Bean

Type Thuộc tính chỉ ra loại biến kịch bản. Nếu biến này không chỉ rõ giá trị

của nó sẽ là giá trị của thuộc tính lớp

2.6.2.2.<jsp:setProperty>

Thẻ <jsp:setProperty> dùng để gán giá trị vào thuộc tính Bean.

Thuộc tính tên của Bean chỉ định cho đối tượng phải được định nghĩa và nằm trong

phạm vi cho phép.

Cú pháp của <jsp:setProperty>

<jsp:setProperty name = “beanName” prop_expr/>

Trong cú pháp trên, name cho biết tên Bean mà thuộc tính của nó

đã được cài đặt. prop_expr có thể có các khai báo sau:

property =”*” |

property = “propertyName” |

property = “propertyName” param=”parameterName”|

property = “propertyName” value=” propertyValue”


Name Thuộc tính trình bày tên của Bean, tên

này đã được định nghĩa bởi thẻ

<jsp:useProperty>

Property Thuộc tính của Bean cần lấy giá trị



Param Tham số cần dùng cho thuộc tính của

Bean

Value Giá trị được gán vào cho thuộc tính của

Bean

2.6.2.3. <jsp:getProperty>

Thẻ <jsp:getProperty> dùng để lấy giá trị thuộc tính Bean và

chuyển giá trị thành kiểu chuỗi. Cú pháp cho thẻ <jsp:getProperty> như sau:

<jsp:getProperty name=”name” property=”propertyName”/>


Name Thuộc tính trình bày tên của Bean, tên này đã được khai

báo và định nghĩa bởi thẻ <jsp:useProperty>

Property Thuộc tính của Bean cần lấy giá trị

2.6.3.Thêm JAVABEANS vào JSP

Để sử dụng JavaBeans trong trang JSP, bạn cần khai báo Bean với thẻ:

< jsp:useBean >

< jsp : useBean id = “jb” scope = “page” class = “searchbean. searchbean”/>

< jsp : setProperty name = “jb” property = “job” param = “name”/>





PHẦN 2 : XÂY DỰNG ỨNG DỤNG

CHƯƠNG 1 PHÂN TÍCH BÀI TOÁN

1.1.TÊN ĐỀ TÀI

Tìm hiểu xây dựng ứng dụng thư điện tử

1.2.DỀ CƯƠNG CHI TIẾT

1.2.1.Khảo sát

Trong thời gian thực tập tốt nghiệp tôi đã khảo sát, tìm hiểu hệ thống thư tín

điện tử. Quá trình xây dựng một ứng dụng thư điện tử (Email) rất đa dạng nhưng chủ

yếu tập trung vào hai phần:

- Xây dựng mail server : là chương trình hoạt động phía máy chủ nhận,

lưu trữ mail, phân phối, gởi mail đến các trình chủ khác. Các chương trình như Mail

Deamon, SendMail, Mail Exchange… là những mail server.

- Xây dựng mail client : là chương trình hoạt động phía máy khách thực

hiện chức năng cho phép người dùng nhập vào nội dung mail, gởi mail đến máy chủ

mail server xác định. Nhận mail từ máy chủ về và hiển thị cho người dùng xem nội

dung mail. Ví dụ như Outlook Express của Windows hay Web mail trên Internet là

những trình đóng vai trò mail client.

1.2.2.Yêu cầu của bài toán



Yêu cầu chính của bài toán

- Phần mail client: thực hiện được cơ bản nhất những chức năng của một

mail client như việc gởi, nhận, hiển thị nội dung mail thông qua trình duyệt Web với

giao thức HTTP của Internet.

- Phần mail server : thực hiện được chức năng tiếp nhận mail do trình

khách (mail client) gửi lên (SMTP Server), lưu trữ mail trong thư mục nhất định cho

phép người dùng sử dụng giao thức POP3 đọc mail (POP3 Server), chuyển mail đến

máy chủ khác (Forward Server) hoặc phân giải địa chỉ mail gửi thẳng đến đích (Relay

Server).

1.2.3.Dữ liệu vào, dữ liệu ra và các chức năng xử lý của hệ thống

* Dữ liệu vào :

- Phần mail client :

+ Thông tin đăng ký của người dùng

- Phần mail server :

+ Mail do trình khách gửi lên

+ Thông tin về vị trí thư mục lưu trữ mail trên server

* Dữ liệu ra :

- Phần mail client :

+ Thông tin về tài khoản thư điện tử của người dùng.

+ Thư mục tương ứng với tên tài khoản, thông tin về user

name và password để dùng cho việc POP3 Server chứng thực quyền truy cập của

người dùng khi cần đọc mail



- Phần mail server :

+ Lưu trữ mail do trình khách gửi đến

+ Chuyển tiếp những mail không thuộc domain mail do

mail server quản lý.

1.2.4. Chức năng của hệ thống thông tin quản lý

* Quản lý toàn bộ thông tin liên quan đến user như: họ, tên, ngày tháng

năm sinh, nghề nghiệp, giới tính, quốc gia, thành phố…

* Quản lý sổ địa chỉ

1.3. LÝ DO CHỌN ĐỀ TÀI

Ngày nay đối với mỗi chúng ta thư điện tử không có gì xa lạ tuy nhiên đó là

đứng về phương diện người dùng. Xuất phát từ mong muốn tìm hiểu một cách tường

tận hơn hệ thống thư điện tử nhìn từ khía cạnh nhà thiết kế nên tôi đã quyết định chọn

đề tài xây dựng ứng dụng thư điện tử theo mô hình Client Server.



CHƯƠNG 2 : THIẾT KẾ VÀ CÀI ĐẶT ỨNG DỤNG

2.1.PHÂN TÍCH VÀ THẾT KẾ CƠ SỞ DỮ LIỆU

2.1.1.Phân tích

Cơ sở dữ liệu được thiết kế đơn giản và dùng vào mục đích quản lý danh sách

thành viên đăng ký sử dụng dịch vụ thư điện tử của vietmail.

Với mục đích đó CSDL chỉ bao gồm hai thực thể chính là được thể hiện trong bảng

sau :

STT Tên thực thể Thuộc tính

1 members

(thành viên)

userid (mã thành viên ), user_name (tên đăng nhập),

password (mật khẩu), question (câu hỏi), answer (câu trả

lời), ho (họ), ten (tên), ngay (ngày sinh), thang (tháng sinh),

nam (năm sinh), gioi_tinh (giới tính)

nuoc (quốc gia), thanh_pho (thành phố), thanh_pho_khac

(thành phố không thuộc Việt Nam), job (nghề nghiệp),

thong_tin_khac (thông tin phụ khác),

date(ngày đăng ký)

2 addressbook

(Sổ địa chhỉ)

addressid (mã sổ địa chỉ), userid (mã thành viên),

quickname (tên gợi nhớ), ho (họ), ten (tên), email (địa chỉ

email), phone (số điện thoại), diachi (địa chỉ)



CÁC LƯỢC ĐỒ QUAN HỆ

Từ những thực thể và thực thể trung gian trên, bằng các nguyên tắc biến đổi, ta

xây dựng thành các lược đồ quan hệ như sau:

Member (userid, user_name, password, question, answer, ho, ten, ngay, thang,

nam, gioi_tinh, nuoc, thanh_pho, thanh_pho_khac, job, thong_tin_khac, date)

Addressbook (addressid, userid, quickname,ho,ten,email,phone,diachi)

Lược đồ quan hệ dữ liệu

member userid user_name password question answer ho ten ngay thang nam gioi_tinh nuoc thanh_pho thanh_pho_khac job thong_tin_khac date

addressbook addressid userid quickname ho ten email phone diachi



Phân tích chức năng

Sơ đồ biểu diễn chức năng của hệ thống

2.1.2. Giải thích các chức năng của hệ thống

- chức năng : Đăng ký thành viên

ý nghĩa : thu thập các thông tin của thành viên nhằm mục đích quản lý

cũng như thiết lập các thông số phục vụ cho việc gởi và nhận thư điện tử của thành

viên

- chức năng : Quản lý sổ địa chỉ

ý nghĩa : tạo một danh sách boa gồm các địa chỉ do thành viên tự tạo

rong quá trình sử dụng hệ thống.

Hệ thống quản lý thành viên của vietmail

Đăng ký thành viên Quản lý sổ địa chỉ



2.1.3.biểu đồ luồng dữ liệu( DFD – Data flow Diagram)

.Biểu đồ luồng dữ liêïu mức khung cảnh (BFD)

2.1.4. THIẾT KẾ HỆ THỐNG

2.1.4.1. Các bảng dữ liệu chính

Ký hiệu:

PK: Khoá chính (Primary Key)

FK: Khoá ngoại (Foreign Key)

Bảng dữ liệu: Member ( Thành viên)

Tên trường Kiểu DL Độ lớn Ràng buộc Khoá Ghi chú

userid int 4 Not Null PK

Yêu cầu Thành viên

Đăng ký

Thông báo

Hệ thống vietmail



user_name varchar 20 Not Null Tên đăng nhập

password char 10 Mật khẩu

question text 16

answer text 16

ho text 16 Not Null

ten text 16 Not Null

ngay smallint 2 Not Null

thang smallint 2 Not Null

nam int 4 Not Null

gioitinh char 5 Not Null

nuoc text Not Null

thanh_pho text 16 Not Null

thanh_pho_k

hac

text 16

job int 4

thong_tin_k

hac

text 16

date datetime 8 Not Null

Bảngdữ liệu : Addresbook (sổ địa chỉ)



Tên trường Kiểu DL Độ lớn Ràng buộc Khoá Ghi chú

addressid int 7 Not Null PK

userid int 8 Not Null Fk

quickname text 8

ho text 8

ten text 20

email text Not Null

phone text

diachi text

2.2. CÀI ĐẶT MAILSERVER

2.2.1.Phương án tổ chức lưu trữ mail trên Server

Để lưu trữ mail gửi đến trên server, mỗi trình mailserver sẽ có một phương án

riêng để lưu trữ. Chẳng hạn có thể lưu trữ thông điệp mail như là các record trong bảng

dữ liệu của database hoặc lưu trong cùng một file text phân cách mỗi thông điệp bằng

một dấu hiệu đặc trưng nào đó. Tuy nhiên việc lưu thông điệp mail dưới dạng các file

trong từng thư mục tương ứng của các User tỏ ra đơn giản hơn và cũng không kém

phần hiệu quả. Vì vậy trong đồ án này tôi quyết định chọn phương án lưu thông điệp

mail dưới dạng tập tin trên đĩa cục bộ. Trước khi cài đặt các đơn thể Mail server ta cần

tổ chức thư mục để SMTP server lưu trữ mail như sau:



Hình : Tổ chức thư mục lưu trữ mail

Mỗi mailserver có thể có nhiều tên domain cho địa chỉ mail, các tên domain này

được tổ chức trong 1 thư mục, ở đây ta chọn vietmail.com là tên domain mail. Lúc

này một địa chỉ e – mail hợp lệ gửi đến SMTP server của ta phải có dạng như sau

[email protected]. Hệ thống mail server còn cho phép mở rộng thêm vào các

domain mail khác. Danh sách các tên domain main nằm trong file domain.txt.

Trong thư mục email\data\vietmail.com chứa danh sách các thư mục con đại

diện cho từng tài khoản (như thanhboeing, xuanthu…). Thông tin đăng nhập của tài

khoản được đặt trong file User.txt.

2.2.2.Các đơn thể của mailserver

Trình MailServer có các đơn thể được cài đặt bằng ngôn ngữ java và bao gồm

các phần chính sau:

- Đơn thể xử lý tập lệnh SMTP

- Đơn thể xử lý tập lệnh POP3



2.2.2.1. Xây dựng SMTP Server

Nhiệm vụchính của SMTP Server là sử lý tập lệnh SMTP, trả lại

mã lỗi do trình khách gởi lên không hợp lệ. Tiếp nhận dữ liệu và lưu vào thư mục nhất

định để trình chủ POP3 Server có thể truy xuất sau này. SMTP server sẽ mở socket

lắng nghe trên cổng 25 (cổng mặc định của SMTP). Ta cũng có thể thay đổi số hiệu

cổng trong file cấu hình email.properties. khi nhận được kết nối từ trình khách, SMTP

server sẽ mở một tuyến (thread) là lớp SMTPConection chịu trách nhiệm phân tích các

lệnh SMTP và nhận mail do trình khách gởi lên. Lớp SMTP được cài đặt như sau:

SMTPServer.java

import java.io.*;

import java.net.*;

import java.util.*;

public class SMTPServer extends Thread {

protected ServerSocket listenSocket = null;

protected Vector connections;

public Boolean stopRequested;

public SMTPServer() throws Exception {

int port = 0;

String portString = null;

// Lấy số hiệu cổng S MTP từ file cấu hình

try {



portString = Server.properties.getProperty("smtp.port");

port = Integer.parseInt(portString);

} catch (NumberFormatException e) {

throw new Exception("Invalid 'smtp.port' - " + portString);

}

// Mở socket láng nghe kết nối từ trình khách

listenSocket = new ServerSocket(port);

// Mảng lưu các kết nối từ trình khách

connections = new Vector(10, 10);

}

public void removeConnection(SMTPConnection connection) {

connections.removeElement(connection);

}

public void run() {

// Lặp vô tận chờ nhận kết nối cho đến khi có tín hiệu dừng

stopRequested = new Boolean(false);

while (true) {

synchronized (stopRequested) {

if (stopRequested.booleanValue())

break;



}

// chấp nhận kết nối

try {

Socket s = listenSocket.accept();

System.out.println("Accept");

//Phân tích các lệnh SMTP của trình khách – thực hiện việc tiếp nhận mail

SMTPConnection connection = new SMTPConnection(s, this);

connections.addElement(connection);

connection.start();

} catch (IOException e) {

e.printStackTrace();

break;

}

}

// Đóng kết nối

try {

listenSocket.close();



}

}

}



Lớp SMTPConnection đóng vai trò chính trong SMTPServer.

SMTPConnection phân tích các lệnh SMTP, nhận mail và lưu và thư mục tương ứng

với địa chỉ mail của User. Chương trình mailserver cũng cho phép khả năng relayvà

chuyển tiếp mail. Các mail có địa chỉ không thuộc domain do mailserver quản lý sẽ

được lưu và thư mục queue (hay hàng đợi). Chương trình SMTPRelayServer và

SMTPRForrwardServer sẽ xử lý các mail này. Lớp SMTPConnection được cài đặt như

sau:

SMTPConnection.java

import java.io.*;

import java.net.*;

import java.util.*;

/**

* SMTPConnection : Xử lý các lệnh SMTP, lưu mail vào thư mục thích hợp

*/

public class SMTPConnection extends Thread {

protected SMTPServer server;

protected Socket socket;

protected Vector recipients;

public BufferedReader in;

public PrintStream out;

public String returnPath;

protected Vector users;

protected boolean stopRequested;

public SMTPConnection(Socket socket, SMTPServer server) {



this.socket = socket;

this.server = server;

}

/**

* Đóng kết nối – hoàn tất quá trình nhận mail từ trình khách

* */

public void close() {

try {

socket.close();

} catch (Exception e) {

System.err.println("Exception trying to close SMTPConnection socket!");

e.printStackTrace(System.err);

}

}

/**

* Xử lý lệnh SMTP DATA

*/

public void processDATA() throws IOException {

String line;

StringBuffer data = new StringBuffer();

line = in.readLine();

while (!line.equals(".")) {



if (line.startsWith(".."))

line = line.substring(1);

// Đặt chuỗi nhận được vào StringBuffer

System.out.println(line);

data.append(line + "\n");


}

// Lưu thông điệp

String messageId = Server.storage.saveMessage(users, data);

// Thông báo cho trình khách thông điệp đã được lưu

out.println("250 Message '" + messageId + "' accepted for delivery");

}

/**

* Xử lý lệnh SMTP EHELO – Lệnh này chỉ dành cho tập lệnh của SMTP mở rộng –

nó tương ứng với lệnh bắt tay HELO

**/

public void processEHLOCommand(StringTokenizer arguments) {

processHELOCommand(arguments);

}

/**

* Xử lý lệnh SMTP HELO



**/

public void processHELOCommand(StringTokenizer arguments) {

if (!arguments.hasMoreTokens()) {

out.println("501 HELO requires domain address");

return;

}

out.println("250 " + Server.getAddress() + " Hello");

}

/**

* Xử lý lệnh SMTP MAIL

**/

public boolean processMAIL() throws IOException {

String line = "";

while (true) {



if (line.length() < 4) {

out.println("500 Command Unknown '" + line + "'");

continue;

}

StringTokenizer tokenizer = new StringTokenizer(line);



String command = tokenizer.nextToken();

if (command.equalsIgnoreCase("HELO")) {

processHELOCommand(tokenizer);

continue;

}

if (command.equalsIgnoreCase("EHLO")) {

processEHLOCommand(tokenizer);

continue;

}

if (command.equalsIgnoreCase("VRFY")) {

processVRFYCommand(tokenizer);

continue;

}

if (command.equalsIgnoreCase("QUIT")) {

processQUITCommand(tokenizer);

return false;

}

if(command.equalsIgnoreCase("RCPT")||command.equalsIgnoreCase("DATA"

)) {

out.println("503 Bad sequence of commands - specify MAIL first");

continue;



}

if (command.equalsIgnoreCase("MAIL")) {

if (processMAILCommand(tokenizer)) {

out.println("250 OK");

return true;

}

}


}

}

public boolean processMAILCommand(StringTokenizer arguments) {


out.println("503 Syntax: MAIL FROM:<user>");

return false;

}

returnPath = arguments.nextToken();

System.out.println(returnPath+" "+returnPath.length());

if (returnPath.length() < 5) {




return false;

}

if (!returnPath.substring(0, 5).equalsIgnoreCase("FROM:")) {


return false;

}

return true;

}

protected void processQUITCommand(StringTokenizer arguments) {

out.println("221 " + Server.getAddress() + " closing connection");

stopRequested = true;

}

public boolean processRCPT() throws IOException {

users = new Vector(2, 2);

String line = "";

while (true) {





if (line.length() < 4) {


continue;

}


String command = tokenizer.nextToken();

if (command.equalsIgnoreCase("EHLO")) {

processEHLOCommand(tokenizer);

continue;

}

if (command.equalsIgnoreCase("VRFY")) {

processVRFYCommand(tokenizer);

continue;

}

if (command.equalsIgnoreCase("RSET")) {

out.println("250 Reset state");

return false;

}




processQUITCommand(tokenizer);

return false;

}

if (command.equalsIgnoreCase("MAIL")) {

out.println("503 Sender already specified");

continue;

}

if (command.equalsIgnoreCase("DATA")) {

if (users.size() == 0) {

out.println("503 Bad sequence of commands - specify RCPT first");

continue;

}

out.println("354 Enter mail, ending with '.' on a line by itself");

return true;

}

if (command.equalsIgnoreCase("RCPT")) {

processRCPTCommand(tokenizer);

continue;

}


}



}

public void processRCPTCommand(StringTokenizer arguments) {


out.println("501 Syntax: RCPT TO:<address>");

return;

}

String arg = arguments.nextToken();

if (!arg.substring(0, 3).equalsIgnoreCase("TO:")) {

out.println("501 Syntax: RCPT TO:<address>");

return;

}

// Địa chỉ nằm sau "TO:"

System.out.println(arg);

// Một vài trình khách gởi lệnh RCPT TO: không có khoảng trắng sau TO

String address;

try{

address=arguments.nextToken(); //có khoảng trắng

} catch(Exception e){



address = arg.substring(3);//không có khoảng trắng

}

System.out.println("Receipt address :"+address);

// Thông thường địa chỉ mail được gởi theo dạng <user@domainname>

if (address.substring(0, 1).equals("<") && address.substring(address.length() - 1,

address.length()).equals(">"))

address = address.substring(1, address.length() - 1);

// Lấy về thông tin của user từ địa chỉ mail

User user = Server.storage.getUser(address);

// Báo lỗi cho trình khách nếu user không tồn tại

if (user == null) {

out.println("550 User " + address + " is not known");

return;

}

// Đưa user vào danh sách phân phối mail

users.addElement(user);

// Trả về mã lỗi thành công

out.println("250 Recipient " + address + " ok");

}



public void processVRFYCommand(StringTokenizer arguments) {

out.println("252 VRFY command not implemented");

}

/**

* Phương thức run() lặp liên tục để lý lệnh cho đến khi hoàn tất

*/

public void run() {

try {

in=new BufferedReader(new InputStreamReader(socket.getInputStream()));

out = new PrintStream(socket.getOutputStream());



close();

return;

}

stopRequested = false;

out.println("220mail.goemaat.comJAVASMTPServer

(com.goemaat.email.SMTP) ready");

while (!stopRequested) {

try {

if (processMAIL()) {

if (processRCPT())

processDATA();

}






}

}

// Đóng socket đã mở trước đó

close();

// Loại bỏ kết nối trong danh sách SMTPServer

server.removeConnection(this);

}

}

Chương trình Server.java dưới đây được dùng để đọc file cấu hình

email.properties, khởi tạo SMTPServer. Server.java cũng làm nhiệm vụ khởi tạo trình

chủ POPServer. Trình Server.java được cài đặt như sau:

Server.java

import java.io.*;

import java.util.*;

public class Server {

public static Properties properties;



public static SMTPServer smtp;

public static EmailStorage storage;

public static POPServer pop;

public static String getAddress() {

String address = properties.getProperty("server.address");

if (address == null)

address = "UNKNOWN[server.address]";

return address;

}

protected static boolean getProperties() {

try {

String fileName = "email.properties";

// Kiểm tra sự tồn tại của file cấu hình email.properties

File file = new File(fileName);

if (!file.exists()) {

fileName = file.getAbsolutePath();

System.out.println("Specified properties file '" +

file.getAbsolutePath() + "' does not exist!");



return false;

}

// Đọc các thông tin cấu hình

properties = new Properties();

FileInputStream in = new FileInputStream(file);

properties.load(in);

in.close();


System.out.println(e);

return false;

}

System.getProperties().put("line.separator", "\r\n");

return true;

}

/**

* Chương trình chính

*/

public static void main(String[] args) {

if (!getProperties()) {

System.err.println("Could not get properties!");



return;

}

System.out.println(Server.properties.getProperty("smtp.port"));

// Thiết lập nơi lưu trữ mail

if (!setupStorage()) {

System.out.println("Could not setup storage!");

return;

}

// Khởi tạo SMTP server

if (!startSMTPServer()) {

System.err.println("Could not start SMTP server!");

return;

}

// Khởi tạo POP server

if (!startPOPServer()) {

System.err.println("Could not start POP server!");

return;

}

}

/**



*Phương thức khởi tạo nơi lưu trữ mail

*/

public static boolean setupStorage() {

String className = properties.getProperty("storage.class");

if (className == null || className.length() == 0) {

System.err.println("No storage class specified in property

'storage.class'!");

return false;

}

Class c = null;

try {

c = Class.forName(className);

} catch (ClassNotFoundException e) {

System.err.println("Class '" + className + "' not found! (check

CLASSPATH)");


return false;

}

// Tạo thể hiện của lớp

try {

storage = (EmailStorage)c.newInstance();



} catch (InstantiationException e) {


return false;

} catch (IllegalAccessException e) {


return false;

}

return storage.init();

}

/**

* Khởi tạo POP server.

*/

protected static boolean startPOPServer() {

try {

pop = new POPServer();

pop.setDaemon(false);

pop.start();



return false;

}

return true;

}



/**

* Khởi tạo SMTP server.

*/

protected static boolean startSMTPServer() {

try {

smtp = new SMTPServer();

smtp.setDaemon(false);

smtp.start();



return false;

}

return true;

}

}

2.2.2.2. Xây dựng POP3 Server

Trình POP3 Server gồm hai phần, phần POPServer chịu trách nhiệm mở socket

và lắng nghe kết nối từ trình khách gởi lên theo cổng 110 (cổng mặc định của giao

thức POP3). Khi nhận được kết nối, POPServer yêu cầu lớp PÔPCnnection phân tích

các lệnh của giao thức POP3 và gởi mail về cho trình khách. Lớp POP3 được cài đặt

như sau:

POPServer.java

import java.io.*;



import java.net.*;

import java.util.*;

public class POPServer extends Thread {

public Vector connections;

public Boolean stopRequested;

protected ServerSocket listenSocket;

public POPServer() throws Exception {

int port = 0;

String portString = null;

// Lấy só hiệu cổng từ file cấu hình

try {

portString = Server.properties.getProperty("pop.port");

port = Integer.parseInt(portString);


throw new Exception("Invalid 'pop.port' - " + portString);

}

// Lắng nghe trên socket sự kết nối từ trình khách

listenSocket = new ServerSocket(port);

// Tạo mảng chứa danh sách các kết nối

connections = new Vector(10, 10);



}

public void removeConnection(POPConnection connection) {

}

/**

* Xử lý kết nối

*/

public void run() {

// Lặp vô tận cho đến khi có yêu cầu dừng

stopRequested = new Boolean(false);

while (true) {

synchronized (stopRequested) {

if (stopRequested.booleanValue())

break;

}

// Chấp nhận kết nối do trình khách gởi lên

try {

Socket s = listenSocket.accept();

//Yêu cầu lớp POPConnection xử lý giao thức phục vụ trình khách

POPConnection connection = new POPConnection(s, this);

connections.addElement(connection);



connection.setDaemon(true);

connection.start();



break;

}

}


try {

listenSocket.close();



}

}

}

Lớp POPConnection.java chịu trách nhiệm chính trong việc xử lý các lệnh của

giao thức POP3. Lớp POPConnection được cài đặt như sau :

POPConnection.java

import java.io.*;

import java.net.*;

import java.util.*;



public class POPConnection extends Thread {

protected static final int ENTER_USER = 0;

protected static final int ENTER_PASSWORD = 1;

protected static final int TRANSACTION = 2;

protected static final int UPDATE = 3;

protected POPServer server;

protected Socket socket;

protected BufferedReader in;

protected PrintStream out;

protected boolean stopRequested;

protected int state;

protected String userName;

protected User user;

protected Vector messages = null;

public POPConnection(Socket socket, POPServer server) {

super();

this.socket = socket;

this.server = server;

}

protected void close() {

try {



socket.close();


System.err.println("Exception trying to close POPConnection socket!");


}

}

// Đếm số mail có trong hộp thư

protected int countMessages() {

if (messages == null)

return 0;

Enumeration enum = messages.elements();

int count = 0;

while (enum.hasMoreElements()) {

Message message = (Message)enum.nextElement();

if (!message.isDeleted())

count++;

}

return count;

}

/**

* Lấy nội dung mail dựa vào số thứ tự của mail lưu trong hộp thư

*/



protected Message getMessage(int number) {

if (number <= 0 || number > messages.size())

return null;

Message message = (Message)messages.elementAt(number - 1);

if (message.isDeleted())

return null;

return message;

}

protected Message getMessage(String messageNumber) {

int number;

try {

number = Integer.parseInt(messageNumber);


return null;

}

return getMessage(number);

}

protected long getMessagesSize() {

if (messages == null)

return 0;


long size = 0;





if (!message.isDeleted())

size += message.getSize();

}

return size;

}

protected void processDELE(StringTokenizer arguments) {


out.println("-ERR must supply message number");

} else {

Message message = getMessage(arguments.nextToken());

if (message == null) {

out.println("-ERR no such message");

}

message.setDeleted(true);

out.println("+OK");

}

}

/**

* Xử lý lệnh PASS kiểm tra password

*/



protected void processEnterPassword(String command, StringTokenizer

arguments) {



out.println("+OK Signing off");

} else if (command.equalsIgnoreCase("PASS")) {


out.println("-ERR must supply password");

return;

}

String password = arguments.nextToken();

if (arguments.hasMoreTokens()) {

out.println("-ERR only one argument to PASS, your password");

return;

}

// Kiểm tra quyền đăng nhập

user = Server.storage.login(userName, password);

if (user == null) {

out.println("-ERR invalid user or password");

state = ENTER_USER;

} else {

// user đã đăng nhập – trả về danh sách các mail có trong hộp thư

messages = Server.storage.getMessages(user);

out.println("+OK mailbox open, " + countMessages() + " messages");



state = TRANSACTION;

}

} else {

out.println("-ERR Only use PASS or QUIT commands");

}

}

/**

* Xử lý lệnh USER

*/

protected void processEnterUser(String command, StringTokenizer arguments)

{



out.println("+OK Signing off");

return;

}

if (command.equalsIgnoreCase("USER")) {


out.println("-ERR must supply user name");

return;

}

userName = arguments.nextToken();



if (arguments.hasMoreTokens()) {

out.println("-ERR only one argument to USER, the user name");

return;

}

state = ENTER_PASSWORD;

out.println("+OK use PASS command to send password");

return;

}

out.println("-ERR Only use USER or QUIT commands");

}

/**

* Xử lý lệnh LIST

*/

protected void processLIST(StringTokenizer arguments) {


out.println("+OK " + countMessages() + " " + getMessagesSize());

for (int i = 1; i <= messages.size(); i++) {

Message message = getMessage(i);

if (message != null) {

out.println(i + " " + message.getSize());

}

}

out.println(".");



} else {

String messageNumber = arguments.nextToken();

Message message = getMessage(messageNumber);



} else {

out.println("+OK " + messageNumber + " " + message.getSize());

}

}

}

/**

* Xử lý lệnh NOOP – Lệnh NOOP của POP3 không làm gì cả, mục đích chỉ

để trình khách xem kết nối còn hiệu lực hay không

*/

protected void processNOOP(StringTokenizer arguments) {

out.println("+OK");

}

/**

* Xử lý lệnh QUIT

*/

protected void processQUIT(StringTokenizer arguments) {






if (message.isDeleted()) {

Server.storage.deleteMessage(message);

}

}

out.println("+OK Goodbye, " + user.getName());


}

/**

* Xử lý lệnh RETR trả về nội dung mail

*/

protected void processRETR(StringTokenizer arguments) {


out.println("-ERR message number required, RETR 1");

} else {





return;

}



out.println("+OK " + message.getSize() + " octets");

// Đọc dữ liệu mail

StringBuffer buffer = Server.storage.getMessageData(message);

BufferedReader reader = new BufferedReader(new

StringReader(buffer.toString()));

// Đọc từng dòng

boolean done = false;

try {

while (reader.ready() && (!done)) {

String line = reader.readLine();

if (line == null)

break;

// Dấu chấm kết thúc

if (line.length() >= 1) {

if (line.substring(0, 1).equals("."))

line = "." + line;

}

// Gửi dữ liệu về trình khách

out.println(line);

}




System.err.println("POPConnection.processRETR()");


}

try {

reader.close();


System.err.println("POPConnection.processRETR() - reader.close()");


}

out.println(".");

}

}

/**

* Xử lý lệnh RSET

*/

protected void processRSET(StringTokenizer arguments) {




if (message.isDeleted())

message.setDeleted(false);

}

out.println("+OK");

}



/**

* Xử lý lệnh STAT

*/

protected void processSTAT(StringTokenizer arguments) {


}

/**

* Xử lý lệnh TOP – trả về trình khách các mail header

*/

protected void processTOP(StringTokenizer arguments) {


out.println("-ERR syntax: TOP <msg> <lines>");

return;

}



out.println("-ERR syntax: TOP <msg> <lines>");

return;

}

int lines = 0;

try {



lines = Integer.parseInt(arguments.nextToken());


out.println("-ERR bad number of lines");

return;

}




return;

}

out.println("+OK " + message.getSize() + " octets");

StringBuffer buffer = Server.storage.getMessageData(message);

BufferedReader reader = new BufferedReader(new

StringReader(buffer.toString()));

boolean done = false;

boolean inBody = false;

int count = 0;

try {

while (reader.ready() && (!done) && (count <= lines)) {



String line = reader.readLine();

if (line == null)

break;

if (line.length() >= 1) {

if (line.substring(0, 1).equals("."))

line = "." + line;

} else {

inBody = true;

}

if (inBody) {

count++;

}

out.println(line);

}


System.err.println("POPConnection.processTOP()");


}

try {

reader.close();




System.err.println("POPConnection.processTOP() -

reader.close()");


}

out.println(".");

}

/**

* Xử lý các lệnh của giao thức POP3

*/

protected void processTransaction(String command, StringTokenizer

arguments) {

if (command.equalsIgnoreCase("STAT")) {

processSTAT(arguments);

} else if (command.equalsIgnoreCase("LIST")) {

processLIST(arguments);

} else if (command.equalsIgnoreCase("RETR")) {

processRETR(arguments);

} else if (command.equalsIgnoreCase("DELE")) {

processDELE(arguments);

} else if (command.equalsIgnoreCase("NOOP")) {

processTOP(arguments);

} else if (command.equalsIgnoreCase("TOP")) {

processTOP(arguments);

} else if (command.equalsIgnoreCase("UIDL")) {



processUIDL(arguments);

} else if (command.equalsIgnoreCase("RSET")) {

processRSET(arguments);

} else if (command.equalsIgnoreCase("QUIT")) {

processQUIT(arguments);

} else {

out.println("-ERR Unknown command " + command);

}

}

protected void processUIDL(StringTokenizer arguments) {



for (int i = 1; i <= messages.size(); i++) {

Message message = getMessage(i);

if (message != null) {

out.println(i + " " + message.getMessageId());

}

}

out.println(".");

} else {





} else {



out.println("+OK " + messageNumber + " " + message.getMessageId());

}

}

}

/**

* Nhận kết nối và các lệnh POP3 gửi lên từ trình khách

*/

public void run() {

try {

in = new BufferedReader(new

InputStreamReader(socket.getInputStream()));

out = new PrintStream(socket.getOutputStream());



close();

return;

}

if (server == null) {

System.err.println("SERVER NOT SET!!!");

return;

}

stopRequested = false;



state = ENTER_USER;

out.println("+OK POP3 " + Server.getAddress());

while (!stopRequested) {

try {

String line = in.readLine();

if (line == null)

break;


String command = "";

if (tokenizer.hasMoreTokens())

command = tokenizer.nextToken();

// Xử lý lệnh tuỳ theo trạng thái đăng nhập của user

switch (state) {

case ENTER_USER:

processEnterUser(command, tokenizer);

break;

case ENTER_PASSWORD:

processEnterPassword(command, tokenizer);

break;

case TRANSACTION:

processTransaction(command, tokenizer);



break;

default:

out.println("-ERR invalid state! ");

System.err.println("Invalid State in POPConnection.run()");


break;

}




}

}


close();

server.removeConnection(this);

}

public void setServer(POPServer server) {}

}

2.3.CÀI ĐẶT MAILCLIENT

Cấu trúc của Website



Phần MailClient được thiết kế dưới dạng Web dùng Java Server Page nên được

gọi là một WebMail. Trang Web và quá trình sử dụng mailclient có thể được hình

dung qua sơ đồ và đặc tả đưới đây

HomePage

Đăng Ký Thành Viên

Login Help

Menumail

Inbox AddressBook Option

Add Edit Review Inf

Change Password

Hình cấu trúc Website



1.Đăng nhập hệ thống :

Lần đầu tiên sử dụng CT để gửi nhận mail, chúng ta phải đăng ký một account

mới cho riêng mình, nghĩa là chúng ta phải có một username và password riêng cho

mình nhằm phân biệt những người sử dụng email khác nhau và bảo mật thư của từng

người.

_ Đăng nhập username và password trước khi vào hệ thống .

Nếu là “member”: bạn có thể sử dụng CT gửi /nhận thư .

Nếu là “guest”: bạn phải Đăng ký thành viên

2.Đăng ký thành viên :

Cho lần đầu tiên bạn đăng nhập vào hệ thống , ghi các thông tin cá nhân,

username và password của bạn.

3.Các loại Address Book . Điều chỉnh thông tin trong Personal Address Book :

(User có quyền T, X, S addressbook của mình)

Các thông tin về địa chỉ mail của các Client được lưu trữ trong các sổ địa chỉ.

Mỗi người sử dụng mail thường có một sổ địa chỉ cá nhân (Personal Address Book -

PAB) của riêng mình và được lưu trữ trong ổ đĩa cục bộ .

Các thông tin cần thiết khi thêm một địa chỉ E-mail vào PAB:

_ RealName là họ tên đầy đủ của người có địa chỉ mail cần thêm vào PAB



_ E-mail Address địa chỉ E-mail chính xác của người cần thêm vào.

Ngoài ra, chúng ta có thể thêm vào những địa chỉ email khác, số phone, mobile

và địa chỉ nhà riêng

4.Review Account Information:

_ User xem lai thông tin cá nhân đã đăng nhập và AddressBook của mình.

_ Có thể thay đổi Password (changepassword.asp) khi bạn muốn đặt lại một

password mới cho mình.

5.Thay đổi Pass :

_ Old Password: nhập lại pass hiện tại.

_ New password: nhập pass mới. Bạn có thể sử dụng các ký tự chữ, số và cả hệ

thống chấm câu, nhưng không thể sử dụng khoảng trắng.

_ Nhập lại password một lần nữa. Nếu so trùng, việc thay đổi password xem như

thành công.



6.Kiểm tra thư:

Vùng nội dung các Folder sẽ xuất hiện tiêu đề các thư trong folder đó. Các thư

chưa được đọc thường được trình bày khác với thư đã được đọc. Thông thường phần

tiêu đềthư gồm các nội dung như sau:

_ From: Tên người gửi, nội dung xuất hiện ở đây không phải là địa chỉ e-mail

của người gửi mà là họ tên của người gửi.

_ Subject : Chủ đề của lá thư . Khi gửi thư, ngưòi gửi thường ghi một nội dung

ngắn vào vùng subject để người nhận biết được mục đích tổng quát của lá thư trước

khi quyết định có đọc thư hay không.

_ Date : Ngày giờ nhận thư

_ Size: Kích thước lá thư (thường tính bằng KB)

7.Đọc thư :

Tất cả thư của bạn được liệt kê trong một bảng trong Inbox với mỗi hàng là một

thư. Để xem nội dung thư cần click vào vùng tiêu đề của thư. Trong vùng nội dung

INBOX

CheckMail Upload File Compose

Read Reply Delete

DownLoad

Send Error

Ok



thư, các thông tin của ngưòi gửi sẽ được thể hiện cùng nội dung lá thư . Các thông tin

người gửi bao gồm: tên người gửi, thời điểm gửi, tên người nhận

Muốn đọc email nào, click vào cột From tương ứng. Sau khi đọc xong, để đọc thư

khác, click vào Inbox hay click vào nút Back của Internet Explorer.

_ Sau khi đọc xong thư ,Delete nếu muốn xóa thư.

_ Reply nếu muốn trả lời thư

_ Download attach file nếu thư có gửi file kèm theo .

8.Viết email trong WebMail:

Chúng ta có hai trường hợp:

Nếu bạn đang đọc một thư nào đó, bạn muốn trả lời thư đóthì click vào nút

Reply phía trên.

Nếu bạn muốn gửi thư trực tiếp, click vào nút Compose.

Khi muốn gửi thư cho một người đã có địa chỉ trong một AddressBook, đầu

tiên phải chuẩn bị nội dung thư để gửi. Phần tiêu đề của một thư cần gửi bao gồm các

thông tin sau:

_ To : Địa chỉ email mà bạn muốn gửi tới.

_ Subject: một đoạn text ngắn cho biết mục đích của nội dung thư cần gửi.

Đoạn text này giúp cho người đọc thư quyết định có nên xem nội dung của thư hay

không.

_ Attachments gởi kèm tập tin cho nguười nhận.

_ Nội dung soạn trong comment

_ Sau khi soạn thảo nội dung thư xong, nhấn nút Send để thư được cất vào

Outbox. Nghĩa là, thư không được truyền đi ngay, do đó chúng ta có thể soạn thảo

nhiều thư trước khi kết nối với Mail Server để gửi đi.



Khi thư đã đưa vào Outbox, mọi chỉnh sửa tiếp theo thường làm thư không gửi đi

được nữa. Trường hợp này cần phải soạn thảo một lá thư khác để gửi đi và xóa bỏ lá

thư cũ.

9.Gửi kèm file theo Mail (attach file)

Trong một số trường hợp cần đưa thêm toàn bộ nội dung một tập tin đang có

sẵn trên đĩa cục bộ vào thư để gửi đến ngưòi nhận. Công việc này được gọi là Attach

file vào thư.

Cần chú ý rằng việc attach một tập tin vào mail cần phải được thực hiện đồng bộ

giữa người gửi , người nhận và đường truyền thư.Nếu không có sự đồng bộ, nội dung

của tập tin được attach có người nhận không đọc được. Lý do của việc này là do nội

dung của tập tin được attach sẽ được mã hoá theo UUENCODE hay theo MIME

(Multipurpose Internet Mail Extensions).

Thông thường để giảm thời gian truyền thư, các tập tin cần attach vào thư sẽ được

nén trước khi thực hiện thao tác attach. Cách nén thông dụng là ZIP.

Các tập tin được gửi kèm có thể lưu thành một tập tin riêng trong điã cục bộ của

người sử dụng. Thông thường dung lượng tập tin gửi kèm không nên quá 1MB, nếu

lớn hơn ta cần tách ra gửi nó trong nhiều thư.

10. Download / Upload file

Một số giao diện

chính



Trang đăng nhập của vietmail



Menu chính

TÀI LIỆU THAM KHẢO

Phân tích, thiết kế và cài đặt hệ thống thông tin quản lý

- Hiệu đính: GS. Bạch Hưng Khang

Cơ sở dữ liệu quan hệ - Lê Tấn Vương

System Administrator for Microsoft SQL Serever 7.0 workbook

Microsoft SQL Server 7.0 Database Implementation Training Kit

Microsoft SQL Server hoạch định và xây dựng cơ sở dữ liệu cao cấp

Allaire JRUN Developer Documentation

Enterprise JavaBeans – Tom Valesky

Enterprise JavaBeans by Example – Henri Jubin, Jurgen Friendichs



HTML by Example – Todd Stauffer

Special Edition Using HTML 4 – Jerry Honeycutt

Special Edition Using JavaScript – Mark C. Reynolds

Java by Example – Clayton Walnum

Lập trình Java thế nào? – Hoàng Ngọc Giao

Java lập trình mạng – Nguyễn Phương Lan, Hoàng Đức Hải

Các tài liệu về JSP/EJB tại website: http://java.sun.com

Documents

Tailieu.vncty.com webmail