DO AN TRUYEN THU TIN DIEN TU MAILSERVER.DOC

87 896 3
DO AN TRUYEN THU TIN DIEN TU MAILSERVER.DOC

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

DO AN TRUYEN THU TIN DIEN TU MAILSERVER

Trang 1

MỤC LỤC

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

CHƯƠNG 1 : GIỚI THIỆU CHUNG VỀ INTERNET VÀ MỘT SỐ GIAO THỨC TRUYỀN THÔNG TRÊN INTERNET 6

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

1.2 HỌ GIAO THỨC TCP/IP 6

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

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

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

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

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

2.2.1.Địa chỉ Internet 14

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

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

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

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

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

1.1 MAILSERVER 17

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

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

1.3.1 KiÕn trĩc vµ c¸c dÞch vơ 17

1.3.2 T¸c nh©n ngêi sư dơng (The User Agent) 20

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

1.3.2.2 Đọc thư (Reading Email) 20

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

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

1.4.2 §Þnh nghÜa vỊ c¸c trêng Header 25

Trang 2

1.4.3 Các trờng header điển hình 25

1.4.4 Ví dụ về cấu trúc th 26

1.5 PHAÂN TÍCH GIAO THệÙC SMTP (RFC 821) 26

1.5.1 Giới thiệu chung 26

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

1.5.3 Thủ tục Mail 28

1.5.4 Thủ tục Forwarding 30

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

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

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

1.6 PHAÂN TÍCH GIAO THệÙC POP3 (RFC 1081,1082) 33

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

1.7 MIME (MULTIPURPOSE INTERNET MAIL EXTENSIONS) 40

1.8.POP BEFORE SMTP(CHệÙNG THệẽC QUYEÀN TRUY CAÄP THEO GIAO THệÙC POP TRệễÙC KHI SệÛ DUẽNG SMTP) 41

1.9.MAIL CLIENT, WEB MAIL 42

CHệễNG 4 : GIễÙI THIEÄU VEÀ CAÙC COÂNG NGHEÄ LIEÂN QUAN 42

2.1.GIễÙI THIEÄU VEÀ JRUN WEBSERVER 3.1 42

2.2.GIễÙI THIEÄU VEÀ SQL SERVER 7.0 42

2.2.1 Lyự thuyeỏt heọ quaỷn trũ cụ sụỷ dửừ lieọu sql server 7.0 vaứ Caỏu truực cụ sụỷ dửừ lieọu cuỷa sql server 7.0 42

2.2.2 Caỏu truực cụ sụỷ dửừ lieọu vaọt lyự: 44

2.2.2.1 Trang (page): 44

2.2.2.2 Extent: 44

2.2.2.3 Nhửừng loaùi file trong CSDL:SQL Server coự 3 loaùi file: 44

2.3 LYÙ THUYEÁT MOÂ HèNH QUAN HEÄ 45

2 3.1 Caực khaựi nieọm cụ baỷn 45

2.3.2 Khaựi Nieọm phuù thuoọc dửừ lieọu vaứ caực daùng chuaồn 45

2.3.3 Khaựi nieọm chổ daón vaứ khoựa chổ daón 46

2.4.GIễÙI THIEÄU VEÀ JAVA SERVLET 46

2.4.1.Khaựi nieọm veà JAVA SERVLET 46

2.4.2.Nhửừng ửựng duùng thửùc teỏ cuỷa JAVA SERVLET vaứ kieỏn truực cuỷa JAVA SERVLET 46

2.5.GIễÙI THIEÄU VEÀ JAVA SERVER PAGES(JSP) 46

Trang 3

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

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

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

2.6 GIỚI THIỆU VỀ JAVABEANS 48

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

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

2.6.2.3 <jsp:getProperty> 49

2.6.3.Thêm JAVABEANS vào JSP 50

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

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

1.1.TÊN ĐỀ TÀI 51

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

1.2.1.Khảo sát 51

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

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 52

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

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

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

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

2.1.1.Phân tích 53

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

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

2.1.4 THIẾT KẾ HỆ THỐNG 55

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

2.2 CÀI ĐẶT MAILSERVER 56

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

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

2.2.2.1 Xây dựng SMTP Server 57

2.2.2.2 Xây dựng POP3 Server 70

2.3.CÀI ĐẶT MAILCLIENT 83

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

Trang 4

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

Trang 5

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àychỉ 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ộtchương trình mang tính thử nghiệm do dịch vụ thư tín điện tử mà thôi.

Trang 6

PHAÀN 1 : Cễ SễÛ LYÙ THUYEÁT

CHệễNG 1 : GIễÙI THIEÄU CHUNG VEÀ INTERNET VAỉ MOÄT SOÁ GIAO THệÙC TRUYEÀN THOÂNG

TREÂN INTERNET

1.1 GIễÙI THIEÄU CHUNG VEÀ 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.

1.2 HOẽ 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.

Trang 7

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 LIEÂN MAẽ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

 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).

Ethernet Token Ring Frame Relay ATM

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

0 3 4 7 8 15 16 31

Trang 8

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

100 - Flas Override 000 - Routine (thấp nhất) D (Delay) (1 bit): chỉ độ trễ yêu cầu

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à:

F MF

Bit 0: reserved - cha sử dụng , luôn lấy giá trị 0 Bit 1 (DF) = 0 (May Fragment)

= 1 (Don’t Fragment) 0 1 2

Trang 9

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

1 1 1 1 0Reserved 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

Trang 10

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

Cần lu ý 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 để lu 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:

Trang 11

Đố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 ẹIEÀU KHIEÅN TRUYEÀN TCP

Source PortDestination Port

Trang 12

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:  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.

Trang 13

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ễÛ VEÀ LAÄP TRèNH MAẽNG TREÂN MOÂ HèNH CLIENT/SERVER

2.1 LAÄP TRèNH GIAO TIEÁP MAẽ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

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 Khaựi nieọm socket vaứ 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à

Trang 14

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 CAÙCH CAỉI ẹAậT ệÙNG DUẽNG CLIENT/SERVER TCP 2.3.1 Caựch caứi ủaở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 Caựch caứi ủaở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

Trang 15

øng dông Serverøng dông Client

Nèi vµo port cña

Trang 16

CHệễNG 3 : MOÄT SOÁ KHAÙI NIEÄM LIEÂN QUAN ẹEÁN THệ ẹIEÄN TệÛ

1.1 MAILSERVER

Theo moõ hỡnh hoaùt ủoọng khaựch chuỷ, trỡnh chuỷ laứ moọt dũch vuù ủoựng vai troứ ngửụứi chuỷ phuùc vuù trỡnh khaựch Mail Server thaọt ra laứ moọt trỡnh mụỷ socket laộng nghe caực yeõu caàu (hay leọnh gửỷi mail) tửứ trỡnh khaựch ủửa ủeỏn Nhử ủaừ noựi, mail server seừ tieỏp nhaọn noọi dung mail, phaõn phoỏi mail ủeỏn caực trỡnh chuỷ khaực, cho pheựp trỡnh khaựch truy caọp vaứo maựy chuỷ ủeồ nhaọn mail veà, baỷo veọ mail…Chớnh vỡ vaọy, trửụực khi nhaọn hay gửỷi mail caàn phaỷi bieỏt ủửụùc ủũa chổ IP cuỷa maựy chuỷ mail server ẹũa chổ naứy thửụứng ủửụùc goùi laứ mail host Veà khaựi nieọm socket vaứ ủũa chổ IP seừ ủửụùc trỡnh baứy ụỷ phaàn sau.

1.2 GIAO THệÙC GệÛI MAIL (MAIL TRANSPORT PROTOCOL)

ẹeồ gửỷi mail ủeỏn maựy chuỷ, trỡnh khaựch phaỷi sửỷ duùng moọt giao thửực troứ chuyeọn vụựi mail server Tửụng tửù trỡnh duyeọt duứng giao thửực HTTP ủeồ troứ chuyeọn vụựi trỡnh chuỷ Web server Caực trỡnh khaựch muoỏn baột tay vụựi trỡnh chuỷ mail server vaứ gửỷi mail leõn maựy chuỷ seừ sửỷ duùng giao thửực SMTP (Simple Mail Transport Protocol) SMTP ủửụùc haàu heỏt caực mail server treõn theỏ gụựi sửỷ duùng ẹũa chổ IP cuỷa maựy chuỷ nhaọn

mail gửỷi ủi thửụứng ủửụùc goùi laứ outgoing mail address Trỡnh chuỷ thửùc hieọn chửực

naờng tieỏp nhaọn mail theo giao thửực SMTP goùi laứ SMTP Server, trỡnh khaựch duứng giao thửực SMTP ủeồ gửỷi mail ủeỏn trỡnh chuỷ mail server goùi laứ SMTP Client.

1.3.GIễÙI THIEÄU KIEÁN TRUÙC DềCH VUẽ THệ ẹIEÄ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ácnhâ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

Trang 17

(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 cha? 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, lu nó, v v Nó cũng sẽ có thể thu nhận để đọc lại với các thông điệp đã đợc lu 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) để lu 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.

Trang 19

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ớckhi 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 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 bu đ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

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 trulyUnited Gizmo

Name: Mr Daniel DumkopfStreet: 18 Willow Lane

Our computer records show that you still have not paid the above invoice of $0.00 Please send us a check

Trang 20

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 ẹoù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 lu lại trong hộp th; kí tự A có nghĩa là th này đã đđ-ợc hồi âmrồ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.

3 KF 4519 Amy N Wong Request for information

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ì

Trang 21

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 daùng thoõng ủieọ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.Chuaồ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 ParameterDescription

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

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

Trang 22

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.

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 nhng cô th ký là ngời thật sự truyền nó đi Trong

ờ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:.

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), nhng nó ít khi đợc điền đầy đủ nh thế và

chỉ đặc biệt chứa địa chỉ của ngời gửi.

Trang 23

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.PHAÂN TÍCH CAÁU TRUÙC THệ ẹIEÄN TệÛ, CAÙC GIAO THệÙC SMTPVAỉ POP3

1.4.1.Phaõn tớch caỏu truực thử ủieọ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 bu 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 lu 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 Moõ taỷ veà caỏu truự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

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.

Trang 24

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

Trang 25

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.

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

Trang 26

để 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.

Để thực

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

Trang 27

Lu ý 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 cha 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êngiao 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 lu lại.

 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 lu 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.

Trang 28

 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à lu 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 ”.” Lu ý 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

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

R: 354 Start mail input; end with <CRLF>.<CRLF> S: Blah blah blah

S: etc etc etc.

R: 354 Start mail input; end with <CRLF>.<CRLF> S: Blah blah blah

S: etc etc etc.

Trong một số trờng hợp địa chỉ trong tham số <forward-path> bị sai, nhng 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

Trang 29

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 nhng 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:<Postel@USC-ISI.ARPA>

R: 251 User not local;

will forward to <Postel@USC-ISIF.ARPA> or

S: RCPT TO:<Paul@USC-ISIB.ARPA> R: 551 User not local;

please try <Mockapetris@USC-ISIF.ARPA>

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

SMTP chủ yếu cung cấp các chức năng phát th đến mailbox của ngời sử dụng Tuy nhiên, nó cũng có một số các chức năng thực hiện việc chuyển th đến terminal của ngời sử dụng

Việc phát th đến mailbox của ngời sử dụng đợc gọi là ”mailing”, còn việc phát th đến terminal đợc gọi là ”sending” Dịch vụ sending là phần mở rộng của một hệ thống th tín điện tử

Có ba dạng câu lệnh đợc định nghĩa để hỗ trợ cho các tùy chọn sending Các câu lệnh này đợc dùng trong các phiên giao dịch SMTP thay thế cho câu lệnh MAIL và báo cho Receiver-SMTP biết ý nghĩa đặc biệt của phiên giao dịch này.

a Lệnh SEND FROM <reverse-path>

 Tham số: địa chỉ terminal của ngời nhận.

 Chi tiết: Lệnh này yêu cầu dữ liệu của th đợc phân phát tới terminal của ngời sửdụng Nếu ngời sử dụng cha kích hoạt (hoặc không chấp nhận kiểu giao dịch

này) thì Receiver-SMTP sẽ gửi trả mã 450 Phiên giao dịch là thành công nếu

th đợc chuyển đến terminal của ngời sử dụng.

 Thông tin phản hồi:

450 OK

b Lệnh SOML FROM <reverse-path>

 Tham số: địa chỉ terminal của ngời nhận.

 Chi tiết: Lệnh này (viết tắt của chữ Send Or MaiL) yêu cầu dữ liệu của th đợc

phân phát tới terminal của ngời sử dụng trong trờng hợp ngời sử dụng kích

hoạt (và chấp nhận kiểu giao dịch này) Trong trờng hợp ngợc lại, nghĩa là

ng-ời sử dụng cha kích hoạt thì dữ liệu của th sẽ đợc chuyển đến mailbox của ngng-ời nhận Phiên giao dịch thành công nếu th đợc chuyển đến terminal của ngời sử dụng.

c Lệnh SAML FROM <reverse-path>

 Tham số: địa chỉ terminal của ngời nhận.

 Chi tiết: Lệnh này (viết tắt của chữ Send And MaiL) yêu cầu dữ liệu của th đợc

phân phát tới terminal của ngời sử dụng trong trờng hợp ngời sử dụng kích

hoạt (và chấp nhận kiểu giao dịch này) Trong bất cứ trờng hợp nào thì dữ liệu

của th cũng sẽ đợc chuyển đến mailbox của ngời nhận Phiên giao dịch thành công nếu th đợc chuyển đến mailbox của ngời sử dụng.

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ó).

Trang 30

 Chi tiết: Lệnh này dùng để xác nhận domain máy chủ SMTP Sender.

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ồiThông tin kèm theo

501 Syntax error in parameters or arguments

221 Service closing transmission channel

421 Service not available, closing transmission channel

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>

553 Mailbox name not allow (mailbox syntax incorrect) 354 Start mail input, end with <CRLF>.<CRLF>

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ôtr-ng yêu cầu.

Trang 31

1.6 PHAÂ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 cha đợ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

Trang 32

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, cha 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. Thông tin phản hồi:

+OK name is welcome here -ERR Never heard of name

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

Trang 33

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

 Thông tin phản hồi:

+OK maildrop locked and ready -ERR invalid password

-ERR unable to lock maildrop

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.

 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 Lu ý, những th bị đánh dấu xoá sẽ bị bỏ qua.

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

Trang 34

 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”.

 Thông tin phản hồi:

+OK scan listing follows -ERR no such message

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

 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 để 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”

 Thông tin phản hồi:

+OK message follows -ERR no such message

 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” Lu ý, 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.

 Thông tin phản hồi:

+OK message deleted -ERR no such message

Ví dụ:

Trang 35

 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 để 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.

 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 cha 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

 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 để 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ỏ

Trang 36

đá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”

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

Lu ý 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

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

S: <wait for connection on TCP port 110>

Trang 37

S: <wait for next connection>

1.7 MIME (MULTIPURPOSE INTERNET MAIL EXTENSIONS)

Laứ caực quy ủũnh veà ủũnh kieồu vaứ caỏu truực dửừ lieọu do noọi dung mail ủeồ noự coự theồ chửựa ủửụùc caực loaùi taứi lieọu phửực hụùp khaực nhau nhử: hỡnh aỷnh, aõm thanh, file nhũ phaõn…MIME coứn ủửụùc bieỏt ủeỏ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 nhng 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ế.

MIME-Version: Indentifies the MIME version

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

Trang 38

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

Text PlainRichtext Unformatted textText including simple formatting commands Image GifJpeg Still picture in GIF formatStill picture in JPEG format

n Octel-streamPostscript An uninterpreted byte sequenceA printable document in Postscript Message Rfc 822Partial A MIME RFC 822 messageMessage 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 QUYEÀN TRUY CAÄP THEO GIAO THệÙC POP TRệễÙC KHI SệÛ DUẽNG SMTP)

ẹeồ traựnh tỡnh traùng caực maựy chuỷ mail server bũ laùm duùng gửỷi mail oà aùt hay coứn goùi laứ “bom thử”, cụ cheỏ POP before SMTP yeõu caàu maựy khaựch muoỏn sửỷ duùng dũch vuù mai cuỷa maựy chuỷ trửụực heỏt phaỷi ủaờng nhaọp vaứo taứi khoaỷn(account) theo giao thửực POP Neỏu quaự trỡnh ủaờng nhaọp thaứnh coõng, cụ cheỏ gụỷi mail baống SMTP mụựi coự theồ dieón ra tieỏp theo.

1.9.MAIL CLIENT, WEB MAIL

ẹaõy laứ caực chửụng trỡnh thửụứng ủửụùc duứng nhaỏt trong quaự trỡnh gửỷi, nhaọn, ủoùc mail Nhửừng chửụng trỡnh ửựng duùng thuoọc daùng mail client coự raỏt nhieàu vớ duù nhử :Outlook Express, Netscap Communicator…neỏu chửụng trỡnh mail client ủửụùc vieỏt dửụựi daùng giao dieọn Web seừ ủửụùc goùi laứ Web mail Thaọt ra Web mail tửụng taực khoự khaờn hụn caực ửựng duùng mail client thoõng thửụứng vỡ phaỷi dửùa voaứ trỡnh chuỷ Web

Trang 39

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

Trang 40

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

Ngày đăng: 24/08/2012, 15:44

Hình ảnh liên quan

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: - DO AN TRUYEN THU TIN DIEN TU MAILSERVER.DOC

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: Xem tại trang 16 của tài liệu.
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 - DO AN TRUYEN THU TIN DIEN TU MAILSERVER.DOC

h.

ê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 Xem tại trang 23 của tài liệu.
Mô hình tổng quát sử dụng giao thức SMTP - DO AN TRUYEN THU TIN DIEN TU MAILSERVER.DOC

h.

ình tổng quát sử dụng giao thức SMTP Xem tại trang 29 của tài liệu.
Bảng Mã thông tin phản hồi của SMTP - DO AN TRUYEN THU TIN DIEN TU MAILSERVER.DOC

ng.

Mã thông tin phản hồi của SMTP Xem tại trang 33 của tài liệu.
1.6.2. Mô hình hoạt động phiên giao dịch - DO AN TRUYEN THU TIN DIEN TU MAILSERVER.DOC

1.6.2..

Mô hình hoạt động phiên giao dịch Xem tại trang 34 của tài liệu.
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.  - DO AN TRUYEN THU TIN DIEN TU MAILSERVER.DOC

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. Xem tại trang 42 của tài liệu.
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 - DO AN TRUYEN THU TIN DIEN TU MAILSERVER.DOC

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 Xem tại trang 42 của tài liệu.

Từ khóa liên quan

Tài liệu cùng người dùng

Tài liệu liên quan