giáo trình an toàn thư điện tử

TRƯỜNG ĐẠI HOC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG
BỘ MÔN AN TOÀN HỆ THỐNG THÔNG TIN
TẬP BÀI GIẢNG
AN TOÀN THƯ ĐIỆN TỬ
THÁI NGUYÊN – 2014

MỤC LỤC
MỤC LỤC....................................................................................................................................... 2
CHƯƠNG 1 .................................................................................................................................... 5
HỆ THỐNG THƯ TÍN ĐIỆN TỬ VÀ CÁC VẤN ĐỀ AN TOÀN ............................................... 5
1.1. Hệ thống thư tín điện tử ....................................................................................................... 5
1.1.1. Lịch sử phát triển .......................................................................................................... 5
1.1.2. Hệ thống thư tín điện tử ................................................................................................ 5
1.2. Các hiểm hoạ đối với thư tín điện tử .................................................................................... 7
1.2.1. Hiểm hoạ bị đọc lén ...................................................................................................... 7
1.2.2. Vấn đề thu thập ............................................................................................................. 9
1.2.3. Phân tích đường truyền ............................................................................................... 10
1.2.4. Giả mạo ....................................................................................................................... 11
1.2.5. Bom thư....................................................................................................................... 12
CHƯƠNG 2 .................................................................................................................................. 15
CÁC GIAO THỨC SỬ DỤNG CHO THƯ TÍN .......................................................................... 15
2.1. Các chế độ hoạt động trạm - chủ trong thư tín................................................................... 15
2.2. Mở rộng thư tín Internet đa mục tiêu (MIME) .................................................................. 16
2.3. Các chuẩn truyền thư ......................................................................................................... 17
2.3.1. Giới thiệu .................................................................................................................... 17
2.3.2. Giao thức truyền thư đơn giản (SMTP) ...................................................................... 17
2.3.3. Các mở rộng của giao thức truyền thư đơn giản ......................................................... 27
2.4. Các chuẩn C lient nhận thư ................................................................................................. 29
2.4.1. Giới thiệu .................................................................................................................... 29
2.4.2. Giao thức nhận thư POP3 ........................................................................................... 30
2.4.3. Giao thức truy nhập thông báo Internet (IMAP) ......................................................... 37
2.4.4. So sánh IMAP và POP ................................................................................................ 45
CHƯƠNG 3 .................................................................................................................................. 47
AN TOÀN ỨNG DỤNG MÁY CHỦ TÍN VÀ NỘI DUNG THƯ .............................................. 47

3.1. An toàn ứ ng dụng máy chủ thư tín .................................................................................... 47
3.1.1. Cài đặt máy chủ thư tín an toàn .................................................................................. 47
3.1.2. Cấu hình an toàn ứ ng dụng máy chủ thư tín ............................................................... 48
3.2. Bảo vệ thư tín điện tử khỏi mã phá hoại ............................................................................ 50
3.2.1. Quét Virus ................................................................................................................... 51
3.2.2. Lọc nội dung ............................................................................................................... 58
3.2.3. Các vấn đề liên quan đến lọc nội dung ....................................................................... 59
3.3. Ngăn ngừa việc gử i thư hàng loạt ...................................................................................... 60
3.4. Chuyển tiếp thư có xác nhận .............................................................................................. 62
3.5. Truy nhập an toàn .............................................................................................................. 62
3.6. Truy nhập thư thông qua Web ........................................................................................... 63
3.7. Bảng liệt kê các danh mục ................................................................................................. 64
CHƯƠNG 4 .................................................................................................................................. 67
AN TOÀN THƯ TRÊN MÁY TRẠM ......................................................................................... 67
4.1. Cài đặt, thiết lập cấu hình, sử dụng các ứng dụng trạm an toàn ........................................ 67
4.1.1. Lấp lỗ hổng và cập nhật phần mềm trạm ................................................................... 67
4.1.2. Trạm thư an toàn ......................................................................................................... 68
4.1.3. Xác thực và truy nhập ................................................................................................. 69
4.1.4. An toàn đối với hệ thống xử lý của máy trạm............................................................. 70
4.2. An toàn cho các thành phần cấu thành nội dung thư ......................................................... 71
4.3. Truy nhập các hệ thống thư tín điện tử dựa trên Web ....................................................... 72
4.4. Bảng liệt kê danh mục........................................................................................................ 73
CHƯƠNG 5 .................................................................................................................................. 76
QUẢN TRỊ AN TOÀN MỘT MÁY CHỦ THƯ.......................................................................... 76
5.1. Hoạch định quản trị an toàn các máy chủ thư .................................................................... 76
5.1.1. Hoạch định việc cài đặt và triển khai máy chủ thư ..................................................... 76
5.1.2. Các đối tượng quản trị cơ chế an toàn ........................................................................ 78
5.1.3. Thực hành quản trị ...................................................................................................... 80
5.1.4. Hoạch định an toàn hệ thống ...................................................................................... 82
5.1.5. Vấn đề con người trong việc an toàn cho máy chủ thư .............................................. 83
5.1.6. Các nguyên tắc cơ bản cho an toàn hệ thống thông tin............................................... 84

5.2. Quản trị an toàn một máy chủ thư...................................................................................... 85
5.2.1. Nhật ký ........................................................................................................................ 85
5.2.2. Các thủ tục sao chép dự phòng máy chủ thư ............................................................. 88
5.2.3. Kiểm tra cơ chế an toàn của các máy chủ thư............................................................. 91
5.2.4. Quản trị từ xa một máy chủ thư .................................................................................. 94
5.2.5. Bảng liệt kê các danh mục quản trị an toàn máy chủ thư ........................................... 95
CHƯƠNG 6 .................................................................................................................................. 98
AN TOÀN THƯ TÍN SỬ DỤNG MẬT MÃ ............................................................................... 98
6.1. Giới thiệu các lư ợc đồ an toàn thư ..................................................................................... 98
6.2. Pretty Good Privacy ........................................................................................................... 99
6.3. S/MIME ........................................................................................................................... 102
6.4. Lựa chọn mã pháp tương ứ ng .......................................................................................... 104
6.5. Quản lý khóa .................................................................................................................... 105
6.6. Sự lựa chọn giữa PGP và S/MIME .................................................................................. 106
TÀI LIỆU THAM KHẢO........................................................................................................... 107

CHƯƠNG 1
3HỆ THỐNG THƯ TÍN ĐIỆN TỬ VÀ CÁC VẤN ĐỀ AN
TOÀN
1.1. Hệ thống thư tín điện tử
1.1.1. Lịch sử phát triển
Theo thống kê đến tháng một năm 2000, có khoảng 242 triệu người sử dụng
Internet. Trong đó hầu hết số người sử dụng Internet đều có tài khoản thư tín điện t ử trên
một hoặc nhiều hệ thống thư tín khác nhau. Khởi nguồn của bước phát triển nhảy vọt trên
xuất phát từ năm 1971 khi Ray Tomlinson thực hiện gửi thành công một thông báo thư
tín điện tử ARPANET đầu tiên.
ARPANET là một dự án của ARPA Hoa Kỳ nhằm phát triển các giao thức truyền
thông để liên kết các nguồn tài nguyên trên các vùng địa lý khác nhau. Các ứng dụng xử
lý thông báo cũng được thiết kế trong các hệ thống của ARPANET, tuy nhiên chúng chỉ
được sử dụng trong việc gửi các thông báo tới người dùng trong nội bộ của một hệ thống.
Tomlinson đã sửa đổi hệ thống xử lý thông báo để người sử dụng có thể gửi các thông
báo cho các đối tượng nhận không chỉ trong một hệ thống mà trên các hệ thống
ARPANET khác. Tiếp theo sự cải tiến Tomlinson, nhiều công trình nghiên cứu khác đã
được tiến hành và thư tín điện tử đã nhanh chóng trở thành một ứng dụng được sử dụng
nhiều nhất trên ARPANET trước đây và Internet ngày nay.
1.1.2. Hệ thống thư tín điện tử
Vậy trong các hệ thống thư tín, thư điện tử được soạn thảo, phân phối và lưu trữ như
thế nào để tiện lợi cho việc thiết lập cơ chế an toàn. Đối với hầu hết người sử dụng thư
điện tử đều nôm na hiểu rằng để gửi một thông điệp thư điện tử ban đầu là việc soạn thảo
nội dung sau đó nội dung thông điệp điện tử sẽ được gửi từ hệ thống của người dùng đến
hộp thư của đối tượng nhận. Nghe thì có vẻ đơn giản nhưng các thao tác chuyển một thư
điện tử cũng không kém phần phức tạp so với khi chuyển một thư thông thường, nó cũng
được xử lý qua rất nhiều công đoạn trung gian trước khi đ ến được với đối tượng nhận.

Qui trình xử lý bắt đầu với việc soạn thảo nội dung thư. Hầu hết các ứng dụng thư ở
máy người sử dụng đều yêu cầu người dùng nhập một số trường chính như: chủ đề, nội
dung, đối tượng nhận, ... Khi việc nhập các trường này hoàn tất, người sử dụng thực hiện
thao tác gửi thư, thư cần gửi sẽ được chuyển đổi sang một định dạng chuẩn xác định bởi
RFC 822 (Standard for the Format of ARP Internet Text Messages). Về căn bản thông
báo sau khi chuyển đổi gồm hai phần: phần tiêu đề (header) và phần thân (body). Phần
tiêu đề gồm một số thông tin như: thời gian gửi, đối tượng gửi, đối tượng nhận, chủ đề,
thông tin về định dạng, ...Phần thân chính là nội dung của thư.
Khi một thư điện tử được chuyển đổi sang định dạng RFC 822 thì nó có thể được
truyền đi. Sử dụng kết nối mạng, các trình thư điện tử trên các máy trạm (gọi là các MUA
- Mail User Agent) được kết nối đến MTA (Mail Transport Agent) hoạt động trên máy
chủ thư tín. Sau khi kết thúc quá trình kết nối, MUA cung cấp định danh của đối tượng
gửi cho máy chủ thư tín. Tiếp theo MUA thông báo cho máy chủ thư tín biết các đối
tượng nhận. Tất cả các thao tác trên được thực hiện thông qua việc sử dụng các lệnh. Sau
khi nhận xong định danh các đối tượng nhận thư, từ đây việc phân phối thư sẽ do máy
chủ quản lý và thực hiện.
Khi máy chủ xử lý thư, một loạt các thao tác được thực hiện: định danh đối tượng
nhận, thiết lập kết nối, truyền thư. Sử dụng DNS máy chủ thư tín thực hiện chức năng gửi
xác định đối tượng nhận. Quá trình một máy chủ thư tín thiế t lập một kết nối và truyền
thư tới một hoặc nhiều máy chủ khác được thực thi như đối với một máy trạm thư thông
thường. Tại thời điểm này có thể sảy ra một trong hai trường hợp. Nếu hộp thư của đối
tượng nhận và đối tượng gửi trên cùng một máy chủ thư tín, thư sẽ được phân phối sử
dụng dịch vụ phân phối cục bộ LDA. Nếu hộp thư của đối tượng nhận và đối tượng gửi
được đặt trên các máy chủ thư tín khác nhau, quá trình thực hiện gửi được lặp từ MTA
này đến MTA khác cho đến lúc đến được hộp thư của đối tượng nhận.
Khi một LDA quản lý thư thì một số tác vụ được thực hiện. Phụ thuộc vào quá trình
thiết lập cấu hình, LDA có thể phân phối hoặc xử lý thư dựa trên chế độ lọc thư được
định nghĩa trước khi phân phối hay không (chế độ lọc thư thường được thiết lập dựa trên
các thuộc tính của thư). Một khi thư đã được phân phối, nó sẽ được đưa vào hộp thư của
đối tượng nhận để lưu và chờ đối tượng nhận thực thi các tác vụ trên nó (như đọc, xoá,
...). Mô hình dưới đây mô tả đường đi của một thư điện tử qua các thành phần đã đề cập

đến ở trên. Đây là qui trình thực thi việc gửi thư chung nhất trong một hệ thống thư tín
điện tử.
Hình 1.1 Hệ thống thư tín điện tử
1.2. Các hiểm hoạ đối với thư tín điện tử
1.2.1. Hiểm hoạ bị đọc lén
Cũng như đối với các ứng dụng khác trên mạng (các phiên đăng nhập từ xa, tải
thông tin sử dụng ftp, hội thoại trực tuyến, ...), thư tín điện tử cũng có thể bị đọc lén.
Nhưng ai là đối tượng muốn đọc lén nội dung thư của bạn? Câu trả lời phụ thuộc vào bạn
là ai, bạn đang làm gì, và ai quan tâm đến việc bạn đang làm. Dưới đây là một vài đối
tượng có thể đọc lén thư của bạn.
1.2.1.1. Chính phủ nước ngoài
Các tổ chức tình báo quân sự nước ngoài là các đối tượng nghe trộm với những thiết
bị tinh vi hiện đại nhất. Đọc trộm nội dung thư cá nhân là nghề của họ. Khi bắt đầu thời
kỳ chiến tranh lạnh, mỗi năm họ đã đầu tư nhiều tỷ Đô la cho việc thu thập, biên dịch và
phân tích dữ liệu của đối phương gửi qua mạng. Hiện tại khi thời kỳ chiến tranh lạnh đã
kết thúc, nhưng không có gì có thể khẳng định họ không thực hiện những gì họ đã từng
làm.
Mối quan hệ giữa quân đội Mỹ và các tổ chức tình báo là một một quan hệ “mờ
ám”, có rất nhiều ứng dụng được xây dựng bởi quân đội Mỹ hiện đang được sử dụng
trong lĩnh vực thương mại. Ở một số nước, mục tiêu thu thập tin tức của họ là nhằm vào

các công ty nước ngoài, thông tin thu thập được sẽ được sử dụng làm công cụ cạnh tranh
cho các công ty thuộc nước bản địa. Nhật Bản và Pháp là hai nước nổi tiếng nhất trong
việc “phạm tội” theo kiểu này, tất nhiên các nước phát triển khác cũng hoàn toàn có thể
làm được điều đó. Ví dụ NSA đã từng bị buộc tội là có hành vi chặn các cuộc điện thoại
giữa hai nước Châu Âu để ăn cắp thông tin và bán cho các đối tượng cạnh tranh khác.
1.2.1.2. Chính phủ trong nước
Việc sử dụng gián điệp công nghệ đối với công dân nước mình nhiều nhất được biết
đến là các nước như Trung Quốc, Bắc Triều Tiên, Cuba. Đối với Pháp, chính phủ chỉ cho
phép mã hoá thông tin trao đổi giữa các công dân với nhau khi thuật toán mã và khoá
được cấp bởi cơ quan có thẩm quyền. Còn đối với Đài Loan và Hàn Quốc thì họ yêu cầu
các công ty loại bỏ việc sử dụng mã hoá thông tin trong các cuộc kết nối thoại, dữ liệu, và
FAX.
Trong bản thân nước Mỹ, nhiều tổ chức thuộc Chính phủ cũng quan tâm đến việc
đọc trộm các thông tin cá nhân được trao đổi qua thư điện tử. Chẳng hạn đối với FBI, các
tổ chức dính dáng đến chính trị, ...
1.2.1.3. Cạnh tranh thương mại
Việc kinh doanh có thể bị do thám bởi các công ty cạnh tranh. Các thông tin đối thủ
cần quan tâm ở đây có thể là danh sách khách hàng, nội dung dự án, kế hoạch triển khai,
tiềm lực tài chính, ... Ví dụ Coca-Cola có thể trả hậu hĩnh cho ai biết được kế hoạch
quảng cáo mới của Pepsi, hãng Ford cũng có thể làm như vậy trong việc biết được thông
tin về mẫu xe mới của một hãng sản xuất xe hơi khác.
1.2.1.4. Tội phạm
Các đối tượng phạm tội có thể thu thập những thông tin có giá trị từ thư điện tử, đặc
biệt là loại tội phạm kinh tế. Cảnh sát ở nhiều nước đã phát hiện ra việc bọ điện tử được
gắn bất hợp pháp trên các kênh điện thoại nhằm giám sát và nghe trộm thông tin về số thẻ
tín dụng được truyền qua đường điện thoại. Không có lý do nào để có thể nói rằng chúng
không làm tương tự đối với thư tín điện tử khi các thông điệp được truyền trên mạng.
Nhiều công ty đã mở giao dịch điện tử mua bán qua mạng Internet, và đã có nhiều
mặt hàng được mua bán qua mạng thông qua thẻ tín dụng. Sẽ là rất dễ dàng để xây dựng

và thiết lập một ứng dụng chạy tự động quét các thông điệp trên máy tính người sử dụng
nhằm tìm kiếm các thông tin về số thẻ tín dụng trong các phiên giao dịch điện tử nói trên.
1.2.1.5. Bạn bè người thân
Cuối cùng, chính bạn bè, người thân của bạn cũng có thể là "gián điệp". Sử dụng
thuật ngữ "gián điệp" trong trường hợp này có thể là chưa được chính xác, nhưng những
đối tượng trên cũng cần được quan tâm khi thư tín điện tử được sử dụng để trao đổi các
thông tin riêng tư. Một ví dụ đơn giản, trong môi trường làm việc ở một văn phòng, đồng
nghiệp hoàn toàn có thể quan tâm đến những thông tin cá nhân được trao đổi qua thư tí n
điện tử của chúng ta mà không chỉ dừng lại ở mục đích tò mò.
1.2.2. Vấn đề thu thập
Vấn đề lớn nhất khi muốn đọc một thông điệp được gửi qua đường thư tín điện tử
của một ai đó là việc tìm nó giữa một biển các thông điệp thư tín điện tử khác trên mạng.
Công việc này được người ta ví như việc "mò kim đáy biển". Tuy là một công việc khó
khăn nhưng hiện vẫn có các cơ quan hoặc tổ chức được sinh ra để làm công việc đó.
Chẳng hạn, một trong các công việc chính của NSA, NSA giám sát các luồng dữ liệu
máy tính vào, ra nước Mỹ và giữa các nước khác với nhau.
Nhiệm vụ thu thập thông tin từ các thông điệp thư tín điện tử được ví như nhiệm vụ
của một chàng Herculean. Năm 1994, theo thống kê dữ liệu máy tính vào ra nước Mỹ đã
đạt con số nhiều gigabytes, với hàng tỷ thông điệp được trao đổi trong một tháng. Trong
đó gồm thư tín điện tử, thông tin đăng nhập từ xa, dịch vụ truyền tệp, dữ liệu "chat" thời
gian thực, ... Để lưu trữ được lượng dữ liệu trên đã là một công việc lớn chứ chưa nói gì
đến việc đọc và phân tích chúng.
Tuy nhiên đối với các thông tin cần quan tâm, các máy tính có thể thực hiện việc
sàng lọc từ dòng dữ liệu trong thời gian thực. NSA hoàn toàn có thể thực hiện việc đưa
luồng dữ liệu vào ra nước Mỹ vào một hệ thống máy tính mạnh, hệ thống máy tính này s ẽ
thực hiện việc tìm kiếm dữ liệu mà NSA quan tâm. Hệ thống máy tính này có thể tìm
kiếm dữ liệu theo từ khoá, giả sử các thông điệp thư tín điện tử có chứa từ khoá "nuclear"
(nguyên tử), "cryptography" (mật mã), hay "assassination" (cuộc ám sát), sẽ được lưu giữ
lại phục vụ cho mục đích phân tích sau.
Ngoài ra còn rất nhiều công nghệ khác được hệ thống máy tính của NSA sử dụng.
Họ có thể tìm kiếm dữ liệu từ một cá nhân hoặc một tổ chức cụ thể. Họ cũng có thể tìm

kiếm dữ liệu theo một cấu trúc cho trước. Tóm lại NSA được đầu tư rất nhiều tiền cho
vấn đề này, họ đã và đang thực hiện công việc trên trong một thời gian dài.
Điều quan trọng nhất là họ thực hiện công việc trên trong thời gian thực, và không
nhiều lắm dữ liệu được lưu. Họ hy vọng rằng dữ liệu mà họ thu thập trong ngày nào sẽ
được phân tích luôn trong ngày đó. Việc thu thập dữ liệu sẽ trở thành vô giá trị nếu dữ
liệu đó không được phân tích, bởi vậy vấn đề khăn chính là việc phân tích dữ liệu. NSA
có thể kết hợp rất nhiều công nghệ nhằm phân tích dữ liệu mà họ quan tâm, như mối quan
hệ giữa từ khoá nói lên dữ liệu cần tìm, đối tượng gửi nhận thông tin, ...
1.2.3. Phân tích đường truyền
Trong trường hợp nội dung thư được mã hoá, đối tượng đọc trộm (NSA chẳng hạn)
không thể đọc nội dung thư điện tử, họ có thể thu thập được một lượng thông tin không
nhỏ thông qua việc phân tích đường truyền.
Việc phân tích đường truyền dựa vào một trong các yếu tố như: bạn gửi thư điện tử
cho ai, bạn nhận thư điện tử từ ai, độ dài của các thông điệp thư điện tử, hoặc khi nào thư
điện tử được gửi. Có rất nhiều thông tin ẩn chứa trong các yếu tố kiểu như vậy nếu họ
biết cách khai thác.
Trước hết chúng ta hãy thử tìm hiểu lĩnh vực cung cấp dịch vụ điện thoại. Hầu hết
các quốc gia châu Âu không ghi chiết khoản mục trong các hoá đơn điện thoại như đối
với các công ty của Mỹ. Các hoá đơn điện thoại ở châu Âu chỉ liệt kê số lượng cuộc đàm
thoại đã sử dụng qua một thuê bao cụ thể, nhưng không ghi lại thời điểm cũng như địa
điểm của các cuộc đàm thoại đó. Đối với các hoá đơn thanh toán điện thoại của Mỹ, trong
đó liệt kê chi tiết tất cả các cuộc đàm thoại đối với một số thuê bao: thời điểm thực hiện,
số được gọi đến, và thời lượng cuộc gọi. Từ những thông tin các cuộc đàm thoại, các cơ
quan có chức năng của Mỹ có thể phân loại các đối tượng cần theo dõi hoặc đưa vào
danh sách các đối tượng cần đề phòng.
Tương tự như vậy đối với các thông điệp thư tín điện tử. Thậm chí khi các thông
điệp thư tín điện tử đã được mã hoá, phần đầu của thông điệp thư tín điện tử bao giờ cũng
thể hiện rõ đối tượng gửi, đối tượng nhận, thời điểm gửi, và độ dài của thông điệp. Trên
thực tế đã có những dịch vụ thư tín điện tử “ẩn danh”, nhằm che dấu đi những thông tin

chúng ta vừa liệt kê ở trên. Tuy nhiên theo các nhà phân tích về lĩnh vực này trên thế giới
đã cho rằng điều đó chẳng có nghĩa lý gì đối với các đối tượng nghe trộm cỡ NSA.
Một ví dụ cụ thể hơn, giả sử Eve nghi ngờ Alice là người ủng hộ chủ nghĩa khủng
bố. Trong khi đó tất cả thư tín điện tử của Alice được cô ấy mã hoá, bởi vậy Eve không
thể đọc được nội dung của các thông điệp thư tín điện tử được gửi nhận bởi Alice. Tuy
nhiên, Eve có thể thu thập tất cả các thông tin trên đường truyền của Alice. Eve biết tất cả
các địa chỉ thư điện tử của những người mà Alice thường liên lạc. Alice thường gửi các
thông điệp thư tín điện tử dài cho một người có tên là Bob, người thường phúc đáp ngay
sau đó với một thông điệp rất ngắn. Có thể cô ấy đã gửi Bob các mệnh lệnh và anh ta
phúc đáp lại việc đã nhận được các lệnh đó. Một ngày nào đó bỗng dưng có một bước
nhảy vọt trong việc trao đổi thư điện tử giữa Alice và Bob. Có thể họ đang lập một kế
hoạch gì đó. Và sau đó là sự im lặng, không có một thông điệp thư điện tử nào được trao
đổi qua lại giữa họ. Ngày tiếp theo toà nhà chính phủ bị đánh bom. Điều này đã đủ làm
bằng chứng để bắt giữ họ chưa còn tuỳ thuộc vào nhiều bằng chứng khác, nhưng ít nhất
chúng đã đem lại cho các cơ quan quan tâm đến lĩnh vực này không ít thông tin quý giá.
Khủng bố không phải là đối tượng duy nhất bị theo dõi thông qua việc phân tích
đường truyền. Việc phân tích đường truyền trao đổi thông điệp thư tín điện tử cũng là
một công cụ để FBI căn cứ trong việc điều tra tội phạm buôn bán ma tuý.
Trong lĩnh vực kinh tế xã hội, một công ty sẽ nghĩ sao khi một thành viên trong
công ty đó thường xuyên liên lạc thư điện tử với một đối thủ cạnh tranh. Điều gì sẽ xảy ra
nếu một người hay ghen nhận thấy vợ hoặc chồng mình thường xuyên liên hệ với “đối
thủ tiềm năng” thông qua thư điện tử.
Tóm lại việc phân tích đường truyền thư điện tử là một công cụ thông minh trong
việc ăn cắp thông tin cá nhân.
1.2.4. Giả mạo
Giả mạo là một vấn đề an toàn khác trên mạng máy tính nói chung. Khái niệm ngắn
nhất về giả mạo là việc người này giả danh là một người khác. Việc giả mạo có thể xuất
phát từ mục đích trêu đùa, làm mất danh dự, bôi nhọ người khác hoặc là công cụ để lừa
gạt.
Hàng ngày có rất nhiều thông điệp thư tín được gửi một cách tự động đến hộp thư
của người sử dụng trên mạng Internet, với chủ đề kiểu như “tôi là người thích làm phiền

người khác và tôi tự hào về điều đó” hoặc với chủ đề như một khẩu hiệu trong việc phân
biệt chủng tộc, phân biệt giới tính. Nội dung của các thông điệp thư tín điện tử này hoàn
toàn không có ý nghĩa gì. Sau đó một thời gian lại có một thư khác cũng xuất phát từ
cùng một tài khoản với lời xin lỗi về việc đã gửi thư điện tử thứ nhất. Nói chung không
nên tin vào bất kỳ điều gì trong các thông điệp thư tín kiểu như vậy, đấy chỉ là một trò
trêu đùa trên mạng.
Một ví dụ khác, Eve muốn bôi nhọ Alice. Cô ta viết một thư điện tử buộc tội một ai
đó, viết tên của Alice ở cuối thư, giả mạo thông tin cá nhân của Alice trên phần tiêu đề
của thư (điều này được thực hiện một cách dễ dàng đối với các tin tặc), sau đó cô ta gửi
một bản copy tới một tạp chí nào đó, như The New York Times chẳng hạn.
Một kiểu giả mạo khác chúng ta có thể lấy ví dụ như kiểu tấn công của kẻ thứ ba
trong mật mã. Ví dụ, Bob và Alice hợp tác với nhau trong một dự án nào đó, và họ
thương xuyên trao đổi thông tin với nhau qua thư điện tử. Eve giả danh là Bob gửi thư
điện tử cho Alice và nói rằng tài khoản thư điện tử trước đây đã bị huỷ bỏ. Tương tự như
vậy đối với Bob và nếu cả Bob và Alice đều tin vào nội dung thư điện tử nhận được thì
mọi liên hệ giữa Alice và Bob được thực hiện thông qua người thứ ba là Eve. Khi đó Eve
sẽ biết mọi thông tin về dự án mà Bob và Alice đang hợp tác. Eve sẽ là người đánh cắp
thông tin trao đổi giữ Bob và Alice chừng nào Bob và Alice chưa trao đổi trực tiếp hoặc
thông qua điện thoại.
Hiểm hoạ mạo danh có thể được khắc phục thông qua việc sử dụng c hữ ký điện tử.
Với chữ ký điện tử Alice (trong ví dụ trên) hoàn toàn có thể kiểm tra được những thông
điệp thư tín điện tử nào là thật sự của Bob. Và cũng không ai có thể mạo danh Alice để
gửi các thông điệp điện tử cho người khác.
1.2.5. Bom thư
Nếu bạn đang sử dụng thư điện tử, bạn có thể đã từng nhận được một số thông điệp
thư điện tử được gửi một cách tự nguyện từ một địa chỉ nào đó tới mà chưa được sự cho
phép của bạn, những thông điệp thư điện tử đó được gọi là spam. Spam là một kiểu thư
rác trên Internet, spam được sử dụng cho rất nhiều mục đích: quảng cáo, quấy rối, ...
Nếu là một người mới sử dụng Internet có thể bạn chỉ nhận được một số ít thông
điệp điện tử không mong muốn như trên. Nhưng khi bạn đã sử dụng Internet được một
vài năm bạn có thể đã cảm thấy rất khó chịu khi nhận được hàng loạt thư điện tử mà mình
không hề mong muốn.

Dưới đây là một số kiểu thư điện tử thường xuyên xuất hiện trong hộp thư của bạn:
 Các thông điệp điện tử được gửi từ các công ty thương mại nào đó mà bạn
chưa hề có mối quan hệ trước đây.
 Thư điện tử có mục đích quảng cáo cho các sản phẩm hoặc dịch vụ bất hợp
pháp, mờ ám hoặc thậm chí là có mục đích đánh lừa
người nhận.
 Các thư điện tử được gửi từ một địa chỉ không rõ ràng.
 Các thư không hề có địa chỉ để người nhận có thể phúc đáp
Nếu bạn đã từng nhận được một mẩu bom thư nào đó, có thể bạn đã có cảm giác bối
rối, và tự mình đặt ra những câu hỏi như: thông điệp này là gì vậy? Nó được gửi từ đâu
đến và bằng cách nào những người gửi thư có được địa chỉ hộp thư của mình?
Khi những băn khoăn của mình vừa qua đi thì bạn đã nhận được liên tiếp các thư
rác tiếp theo, và như vậy chúng đã gây nên sự bực mình cho bạn. Có thể, bạn sẽ viết thư
than phiền với người gửi thư rác, nhưng sự bực mình của bạn sẽ tăng lên khi biết thư điện
tử than phiền của mình sẽ không đến được đối tượng mình cần gửi, vì kẻ gửi thư rác
thường nguỵ trang hoặc dựng giả một hộp thư nào đó khi gửi cho bạn.
Một số loại bom thư:
 Thư điện tử thương mại tự nguyện (UCE - Unsolicited Commercial
Email): là các thông điệp thư điện tử mà người sử dụng nhận được ngoài ý
muốn, với nội dung nhằm quảng cáo cho một sản phẩm hay một dịch vụ
nào đó. Loại bom thư này còn được gọi là "Junk mail".
 Thư điện tử gửi hàng loạt (UBE - Unsolicited Bulk Email): được biết đến
như các thông điệp điện tử được gửi với số lượng lớn cho hàng nghìn thậm
chí hàng triệu người nhận. UBE có thể được sử dụng cho mục đích thương
mại, trong trường hợp đó nó cũng là UCE. Nhưng nó cũng có thể được sử
dụng cho nhiều mục tiêu khác, như vận động bầu cử trong lĩnh vực chính
trị, hay chỉ đơn giản là gây rối hệ thống thư điện tử.
 Các thông điệp thư điện tử kiếm tiền nhanh (MMF - Make Money Fast):
thường các thông điệp này là một chuỗi các thư cùng một mẫu. Nội dung
của các thông điệp thư điện tử kiểu này gợi ý người nhận rằng họ có thể trở
nên giàu có nếu thực hiện theo các bước như:

 Hãy gửi tiền cho người có tên đầu tiên trong danh sách (danh sách được
gửi kèm theo thư)
 Loại bỏ tên của người đó, bổ sung tên của mình vào cuối danh sách và
chuyển thông điệp đó cho người khác.
Các thông điệp thư điện tử MMF được xem là trò sổ số bất hợp pháp ở nước Mỹ.
Các tấn công sự nổi tiếng: là các thông điệp thư điện tử mà người sử dụng cho là nó được
gửi từ một người hoặc một tổ chức cụ thể, nhưng thực tế nó lại được gửi từ một địa chỉ nào
đó khác. Mục đích của các thông điệp điện tử kiểu này không phải nhằm quảng cao cho
sản phẩm hay dịch vụ, mà nhằm mục đích làm cho người nhận giận người gửi xuất hiện
trong thư.

CHƯƠNG 2
CÁC GIAO THỨC SỬ DỤNG CHO THƯ TÍN
2.1. Các chế độ hoạt động trạm - chủ trong thư tín
Trong mục này chúng ta tìm hiểu một số khái niệm cơ bản về các mô hình trạm chủ
được sử dụng trong thư tín điện tử. Có 3 mô hình được sử dụng là:
 Mô hình Offline: Trong mô hình này, một ứng dụng thư client kết nối định kỳ tới
máy chủ thư tín. Nó tải tất cả các thông báo tới máy client và xoá các thông báo này
khỏi máy chủ thư tín. Sau đó, quá trình xử lý mail được diễn ra cục bộ trên máy
client đó.
 Mô hình Online: Mô hình này thường được sử dụng với các giao thức hệ thống tệp
trên mạng (NFS). Trong chế độ này, một ứng dụng client thao tác với dữ liệu
mailbox trên máy chủ thư tín. Một kết nối tới máy chủ thư tín được duy trì trong
suốt phiên làm việc. Không có dữ liệu mailbox nào được giữ trên máy client; cl ient
lấy dữ liệu từ máy chủ thư tín khi cần.
 Mô hình Disconnected: Đây là một mô hình biến thể của mô hình Offline và mô
hình Online, được sử dụng bởi giao thức PCMAIL. Trong mô hình này, một client
tải một vài thông báo từ máy chủ thư tín, thao tác với chúng trong mô hình offline,
rồi sau đó chuyển các thay đổi đến máy chủ thư tín. Vấn đề đồng bộ được quản lý
(khi có nhiều client) thông qua phương pháp nhận danh duy nhất cho mỗi thông
báo.
Mỗi một mô hình có ưu và nhược điểm, ta có thể so sánh đặc điểm c ủa các mô hình
này trong bảng dưới đây:
Đặc điểm Offline Online Disconnected
Có thể sử dụng nhiều client Không Có Có
Thời gian kết nối tới máy chủ thư tín
là tối thiểu
Có Không Có
Sử dụng nguồn tài nguyên của máy
chủ thư tín ít nhất
Có Không Không

Sử dụng ổ đĩa của client ít nhất Không Có Không
Nhiều mailbox ở xa Không Có Có
Khởi động nhanh Không Có Không
Xử lý mail khi không kết nối online Có Không Có
2.2. Mở rộng thư tín Internet đa mục tiêu (MIME)
RFC 822 cung cấp chuẩn cho việc truyền các thông điệp thư tín điện tử chứa các nội
dung dạng văn bản. Tuy nhiên, chuẩn này không trợ giúp các thông điệp thư tín điện tử
có các thành phần đính kèm (như thông điệp thư tín điện tử có đính kèm các tài liệu word
hoặc các tệp hình ảnh). Để thay thế cho các định nghĩa trong RFC 822, "mở rộng phần
thư tín Internet đa mục tiêu (MIME)" đã được phát triển. Đối với phần tiêu đề (header)
của các thông điệp vẫn tuân theo chuẩn RFC 822, việc sửa đổi và phát triển cho phần mở
rộng MIME được thực hiện đối với nội dung của thông điệp. MIME sử dụng một số quy
ước để thể hiện những nội dung riêng trong một thông điệp thư tín điện tử.
Ví dụ minh hoạ cho các kiểu nội dung như sau:
 Âm thanh- dùng để truyền các âm thanh hoặc dữ liệu bằng âm thanh.
 Ứng dụng- sử dụng để truyền ứng dụng hoặc dữ liệu nhị phân.
 Hình ảnh- dùng để truyền dữ liệu hình ảnh.
 Thông điệp- dùng để đóng gói thông điệp thư tín khác
 Đa phần- được sử dụng để liên kết nhiều phần thân của thông điệp, có thể
là các kiểu khác nhau của dữ liệu thành một thông điệp cụ thể.
 Văn bản- được sử dụng để biểu diễn những thông tin dưới dạng văn bản
theo một bộ ký tự nhất định nào đó .
 Video- dùng để truyền video hoặc dữ liệu hình ảnh động, có thể có âm
thanh như một phần của phần định dạng dữ liệu video tổng hợp.
Hiện tại có 5 tài liệu mô tả MIME là: RFCs 2045, 2046,2047,2048 và 2049. Trong
đó mô tả định dạng cho phần thân thông điệp, các kiểu truyền thông, mã định dạng không
thuộc chuẩn của Mỹ, …. Ngoài những tính năng được bổ sung đã liệt kê, các tính năng
quan trọng khác của thư tín như phần đính kèm thông điệp, nhúng trực tiếp phần dữ liệu

dưới định dạng ngôn ngữ siêu văn bản (HTML) cũng được đưa ra trong các tài liệu trên.
Lưu ý rằng, mặc dù các phần mở rộng MIME cho phép sử dụng nội dung thông điệp
dạng nhị phân, nhưng nội dung dưới dạng nhị phân phải được biểu diễn dưới định dạng
Base64 để phù hợp với chuẩn qui định trong RFC 822.
2.3. Các chuẩn truyền thư
2.3.1. Giới thiệu
Nhằm đảm bảo độ tin cậy và khả năng tương tác giữa các ứng dụng thư tín khác
nhau, các tiêu chuẩn truyền thư tín được thiết lập. Trong trường hợp đơn giản nhất, việc
truyền tải thư là quá trình một thông điệp thư tín được gửi từ người sử dụng cục bộ này
tới người sử dụng cục bộ khác, khi đó LDA chịu trách nhiệm xác định và chuyển thông
điệp thư tín điện tử đến hộp thư thích hợp. Trong trường hợp phức tạp hơn, khi đối tượng
nhận bên ngoài nhóm cục bộ, cần phải có một MTA để gửi thông điệp từ máy chủ thư tín
cục bộ tới máy chủ thư tín từ xa. Tuỳ vào kiểu và phạm vi của hệ thống hiện có, mà một
hoặc nhiều MTA khác nhau được sử dụng, và bản thân mỗi cặp MTA có thể sử dụng các
giao thức truyền thư khác nhau.
Giao thức chuyển giao MTA phổ biến nhất hiện nay là giao thức truyền thư đơn
giản (SMTP). SMTP là chuẩn cho việc truyền các thông điệp điện tử trên Internet (chi
tiết về giao thức này chúng tôi sẽ trình bày trong phần tiếp theo). Bởi vậy hầu hết các hệ
thống thư tín điện tử trên Internet đều hỗ trợ giao thức SMTP cho việc truyền thư.
2.3.2. Giao thức truyền thư đơn giản (SMTP)
Jon Postel thuộc Trường đại học Nam California đã phát triển SMTP vào tháng 8
năm 1982. SMTP là một giao thức truyền thư tín điện tử một cách tin cậy và hiệu quả.
SMTP độc lập đối với các hệ thống truyền tải đặc biệt và chỉ yêu cầu kênh truyền
dữ liệu tin cậy (cổng 25/TCP). Một dịch vụ truyền tải (TCP, X.25, …) cung cấp một môi
trường truyền thông liên tiến trình (IPCE, Interprocess Communication Environment).
Một IPCE có thể bao gồm một mạng, nhiều mạng, hoặc tập con của một mạng. Như vậy,
điều quan trọng ở đây là các hệ thống (hoặc các IPCE) không phải là các mạng one-to-one.
Một tiến trình có thể truyền thông trực tiếp với tiến trình khác thông qua IPCE đã
được biết. Mail là một ứng dụng hoặc là sự sử dụng truyền thông giữa các tiến trình. Mail
có thể được truyền thông giữa các tiến trình trong các IPCE lưu chuyển thông qua một

tiến trình đã kết nối với 2 hoặc nhiều IPCE. Đặc biệt hơn nữa, mail có thể được lưu
chuyển giữa các máy trên các hệ thống truyền tải khác nhau bằng một máy gồm có cả 2
hệ thống truyền tải đó. Dưới đây chúng ta sẽ đi tìm hiểu mô hình cụ thể của SMTP.
2.3.2.1. Mô hình hoạt động của SMTP
Thiết kế SMTP được dựa trên mô hình truyền thông sau: tương tự như một yêu cầu
thư của người sử dụng, Sender-SMTP thiết lập một kênh truyền tải 2 chiều tới một
Receiver-SMTP. Receiver-SMTP hoặc là đích hoặc là điểm tạm thời. Các lệnh SMTP
được sinh ra bởi Sender-SMTP và gửi tới Receiver-SMTP. Đáp lại SMTP được gửi từ
Receiver-SMTP các lệnh tới Sender-SMTP.
Mỗi khi kênh truyền thông được thiết lập, thì Sender-SMTP gửi một lệnh MAIL chỉ
rõ người gửi thư. Nếu Receiver-SMTP có thể chấp nhận thư đó thì nó đáp lại OK. Sau đó
Sender-SMTP gửi lệnh RCPT định danh người nhận thư. Nếu Receiver-SMTP có thể
chấp nhận thư đó cho người nhận thì nó đáp lại OK; ngược lại, nếu Receiver -SMTP
không chấp nhận thì nó loại bỏ thư đó. Sender-SMTP và Receiver-SMTP có thể thoả
thuận với nhau là sẽ có nhiều người nhận. Sau khi đã thoả thuận xong những người nhận
thư thì Sender-SMTP gửi dữ liệu thư, và đưa kèm chuỗi đặc biệt <CRLF> để kết thúc.
Nếu Receiver-SMTP đã xử lý dữ liệu mail thành công thì nó đáp lại OK (là lời thoại mỗi
khi hoàn thành một bước giữa Sender-SMTP và Receiver-SMTP). Mô hình sử dụng
SMTP được thể hiện như sau:
User
HÖ
thèng
file
Sender-
SMTP
Receiver-
SMTP
HÖ
thèng
file
SMTP
commands/replies
Mail
Hình 2.1: Mô hình sử dụng SMTP
SMTP cung cấp các kỹ thuật truyền tải thư điện tử, trực tiếp từ máy của người gửi
tới máy của người nhận khi 2 máy được kết nối cùng một dịch vụ truyền tải (chủ yếu sử
dụng TCP), hoặc gửi qua một hoặc nhiều Server-SMTP lưu chuyển khi các máy nguồn

và đích không được kết nối cùng dịch vụ truyền tải. Để có thể cung cấp các khả năng lưu
chuyển thì Server-SMTP phải được cung cấp tên máy đích cuối cùng (tên mailbox đích).
Tham số của lệnh MAIL là reverse-path (tuyến ngược) để chỉ ra thư được chuyển từ
người nào. Tham số của lệnh RCPT là forward-path (tuyến thuận) để chỉ ra thư được
chuyển tới người nào. forward-path là một tuyến đích trong khi đó reverse-path là tuyến
trả về (có thể được sử dụng để trả về một thông điệp tới người gửi khi xuất hiện những
lỗi trên thông điệp lưu chuyển). Khi cùng một thông điệp được gửi tới nhiều người nhận
thì SMTP giúp sự truyền tải chỉ có một bản sao của dữ liệu cho t ất cả người nhận trên
cùng một máy đích.
Các lệnh hỏi đáp khi gửi thư có cú pháp chặt chẽ. Riêng phúc đáp cũng có thể là
một mã dạng số. Những ví dụ về gửi thư và các lệnh khi gửi và đáp lại sẽ được chúng tôi
trình bài ở phần sau. Các ký tự của lệnh hỏi đáp có thể tuỳ ý: có thể là chữ hoa, chữ
thường, hoặc cả hai. Điều này không đúng đối với tên người dùng trên mailbox. Đối với
một số trường hợp khác tên người sử dụng dễ bị ảnh hưởng, và các cài đặt SMTP quản lý
trong trường hợp tên người sử dụng khi chúng xuất hiện trên các tham số mailbox. Tên
máy cũng không bị ảnh hưởng vấn đề này. Các lệnh hỏi đáp nằm trong tập ký tự ASCII.
Khi dịch vụ truyền tải cung cấp một kênh truyền tải 8-bit (octet), thì các ký tự 7-bit cũng
được truyền tải như là một octet nhưng bit cao sẽ lấy giá trị 0.
2.3.2.2. Các thủ tục truyền SMTP
Trong mục này chúng tôi sẽ trình bày các thủ tục sử dụng trong SMTP. Trước tiên
thủ tục thư cơ bản truyền tải thư tín. Tiếp theo là mô tả về các thủ tục gửi thư, kiểm tra
các tên trong mailbox và mở rộng danh sách thư, gửi tới các terminal hoặc kết hợp với
các mailbox, mở và đóng phiên giao dịch, lưu chuyển thư. Trong tài liệu này không đề
cập đến vấn đề phân vùng thư và thay đổi vai trò chương trình khi truyền thông qua kênh
truyền tải, để thêm thông tin bạn có thể tham khảo trong RFC 821.
Thủ tục truyền tải
Thủ tục truyền tải SMTP có 3 bước:
 Bước 1: Sử dụng lệnh MAIL để định danh người gửi.
 Bước 2: Một hoặc nhiều lệnh RCPT để định danh thông tin người nhận.
 Bước 3: Sử dụng lệnh DATA để xác định dữ liệu thư.

Các lệnh trên có cú pháp như sau:
MAIL <SP> FROM:<reverse-path> <CRLF>
RCPT <SP> TO:<forward-pa th> <CRLF>
DATA <CRLF>
Ví dụ người gửi tiendq gửi thư tại máy vdc tới người dùng thaith, toannq và khoanc
trên máy vol như sau:
S: MAIL FROM:<tiendq@vdc.vn>
R: 250 OK
S: RCPT TO:<thaith@vol.vn>
R: 250 OK
S: RCPT TO:<khoanc@vol.vn>
R: 550 No such user here
S: RCPT TO:<toannq@vol.vn>
R: 250 OK
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah...
S: ...etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 OK
Trong đó S của bên gửi và R của bên nhận (quy ước này sẽ được sử dụng cho tất cả
các ví dụ). Ví dụ trên chỉ chấp nhận mail của thaith và toannq, còn khoannc không được
chấp nhận bởi không có mailbox trên máy vol.
Thủ tục gửi mail
Trong một số trường hợp thì thông tin đích trong <forward-path> bị sai, Receiver-
SMTP sẽ nhận biết đích đúng khi <forward-path> đúng. Khi đó sẽ xảy ra một trong 2

lệnh đáp lại dưới đây được sử dụng để cho phép người gửi liên lạc với đích được cho là
đúng.
251 User not local; will forward to <forward-path>
hoặc 551 User not local; please try <forward-path>
Lệnh đáp lại 251 chỉ ra rằng Receiver-SMTP nhận ra mailbox của người sử dụng
trên một máy khác và xác định đúng forward-path sẽ được sử dụng về sau (lưu chuyển
qua nhiều SMTP). Lệnh 551 chỉ ra rằng Receiver-SMTP nhận ra mailbox của người sử
dụng trên một máy khác và xác định đúng forward-path sử dụng ngay lúc đó. Ví dụ:
S: RCPT TO:<Postel@USC-ISI.ARPA>
R: 251 User not local; will forward to <Postel@USC-ISIF.
ARPA>
hoặc
S: RCPT TO:<Paul@USC-ISIB.ARPA>
R: 551 User not local; please try <Paul@USC-ISIF.
ARPA>
Kiểm tra và mở rộng danh sách thư
SMTP cung cấp thêm một số đặc tính như: kiểm tra tên người sử dụng bằng lệnh
VRFY, và mở rộng danh sách mail bằng lệnh EXPN. Các lệnh này có cú phá p như sau:
VRFY <SP> <string> <CRLF>
EXPN <SP> <string> <CRLF>
Trong đó lệnh VRFY sẽ kiểm tra về thông tin của tên người sử dụng <string> đã chỉ
ra, lệnh EXPN định danh <string> cho một danh sách thư (có thể gửi thư cho tất cả người
nhận có cùng định danh).
Ví dụ về kiểm tra tên người sử dụng như sau:
S: VRFY Smith
R: 250 Fred Smith <Smith@USC-ISIF.ARPA>
hoặc

S: VRFY Smith
R: 251 User not local; will forward to <Smith@USC-ISIQ.
ARPA>
hoặc
S: VRFY Jones
R: 550 String does not match anything.
hoặc
S: VRFY Jones
R: 551 User not local; please try <Jones@USC-ISIQ.
ARPA>
hoặc
S: VRFY Gourzenkyinplatz
R: 553 User ambiguous.
Ví dụ về mở rộng danh sách mail như sau:
S: EXPN Example-People
R: 250-Jon Postel <Postel@USC-ISIF.ARPA>
R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
R: 250-Sam Q. Smith <SQSmith@USC-ISIQ.ARPA>
R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.
ARPA>
R: 250-<joe@foo-unix.ARPA>
R: 250 <xyz@bar-unix.ARPA>
hoặc
S: EXPN Executive-Washroom-List
R: 550 Access Denied to You.
Phân phối tới mailbox và terminal

Mục đích chính của SMTP là phân phối các thông điệp tới mailbox của người sử
dụng. Một số ít dịch vụ phân phối thông điệp tới các terminal của người sử dụng (người
sử dụng được kích hoạt). Việc phân phối thông điệp tới các mailbox của người sử dụng
được gọi là "mailing", còn phân phối thông điệp tới các terminal của người sử dụng được
gọi là "sending" (người dùng gửi thông điệp thông qua terminal). Dưới đây là 3 lệnh đã
được định nghĩa để hỗ trợ "sending".
SEND <SP> FROM:<reverse-path> <CRLF>
SOML <SP> FROM:<reverse-path> <CRLF>
SAML <SP> FROM:<reverse-path> <CRLF>
Lệnh SEND yêu cầu dữ liệu thư được phân phối tới terminal của người sử dụng.
Nếu người sử dụng đó không đặt chế độ kích hoạt (hoặc không chấp nhận thông điệp tới
terminal) thì sẽ trả về mã 450 bằng lệnh RCPT. Lệnh SOML (send or mail) yêu cầu dữ
liệu mail được phân phối tới terminal của người sử dụng nếu người dùng đó đã đặt chế độ
kích hoạt. Nếu người dùng đó không được kích hoạt (không chấp nhận thông điệp tới
terminal) thì dữ liệu mail sẽ được chuyển vào mailbox của người sử dụng. Lệnh SAML
(send and mail) yêu cầu dữ liệu mail được phân phối tới terminal của người sử dụng nếu
người dùng đó đã đặt chế độ kích hoạt (và chấp nhận thông điệp tới terminal). Trong một
số trường hợp khác dữ liệu mail mới được đưa vào mailbox của người sử dụng.
Đóng và mở phiên giao dịch
Tại thời điểm kênh truyền tải được mở thì có sự trao đổi thông tin để chắc chắn rằng
các máy đang truyền thông với nhau. Hai lệnh sau đây được sử dụng để đóng mở phiên
giao dịch cho kênh truyền tải.
HELO <SP> <domain> <CRLF>
QUIT <CRLF>
Trong lệnh HELO máy sẽ gửi lệnh tự định danh cho nó, tương tự như một lời chào
"Chào các bạn, tôi là <domain>". Ví dụ mở kết nối như sau:
R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
S: HELO USC-ISIF.ARPA
R: 250 BBN-UNIX.ARPA

Lệnh QUIT thực hiện đóng kênh truyền tải thông tin, ví dụ:
S: QUIT
R: 221 BBN-UNIX.ARPA Service closing transmission channel
Lưu chuyển mail
Từ khoá forward-path có thể là một tuyến nguồn có dạng "@ONE, @TWO:
JOE@THREE", trong đó ONE, TWO, và THREE là các máy. Dạng này được sử dụng để
làm nổi bật sự khác nhau giữa một địa chỉ và một tuyến. Mailbox là một địa chỉ tuyệt đối,
và tuyến là thông tin về cách thức nhận mail.
Theo khái niệm thì các phần tử của forward-path được chuyển thành reverse-path
khi thông điệp được lưu chuyển từ một Server-SMTP tới Server-SMTP khác (reverse-path
coi là một tuyến nguồn ngược). Khi một Server-SMTP xoá định danh của nó khỏi
forward-path và thay định danh của Server-SMTP đó vào reverse-path, thì nó phải sử
dụng định danh phải được biết bởi đối tượng nó sẽ gửi tới. Nếu khi thông điệp đến tại
một Server-SMTP phần tử đầu tiên của forward-path không phải là bộ định danh của
Server-SMTP đó thì phần tử đó không bị xoá khỏi forward-path mà được dùng để xác
định Server-SMTP tiếp theo cần tiếp tục gửi thông điệp tới. Trong một số trường hợp
khác thì Server-SMTP thêm bộ định danh của nó vào reverse-path.
Sử dụng nguồn định tuyến Receiver-SMTP để nhận mail đã được lưu chuyển từ
Server-SMTP khác. Khi đó Receiver-SMTP có thể chấp nhận hoặc huỷ bỏ tác vụ lưu
chuyển mail theo đúng cách mà nó chấp nhận hoặc huỷ bỏ mail của một người dùng cục
bộ. Receiver-SMTP truyền tải các tham số lệnh bằng cách chuyển bộ định danh của nó từ
forward-path thành định danh của reverse-path. Sau đó Receiver-SMTP sẽ trở thành
Sender-SMTP, thiết lập một kênh truyền tải cho SMTP tiếp theo trong forward-path, và
tiếp tục gửi mail. Máy đầu tiên trong reverse-path sẽ là máy gửi các lệnh SMTP, và máy
đầu tiên trong forward-path sẽ là máy nhận các lệnh SMTP.
Chú ý: forward-path và reverse-path xuất hiện trong các lệnh gửi và đáp lại của
SMTP, nhưng không cần thiết trong các thông điệp. Điều đó có nghĩa là không cần thiết
các đường dẫn này cho thông điệp và đặc biệt cú pháp này chỉ xuất hiện trong các trường
tiêu đề của thông điệp như:"To:", "From:", "CC:",...
Nếu Server-SMTP đã chấp nhận tác vụ lưu chuyển thư và sau đó tìm đúng forward-path
hoặc thư không được phân phối với một lý do nào đó, thì thông điệp thông báo

"undeliverable mail" không thể phân phối mail và gửi nó về nơi xuất phát. Thông báo này
phải bắt đầu từ Server-SMTP của máy đó. Tất nhiên, các Server-SMTP không gửi thông
điệp thông báo lỗi cùng thông điệp đó. Một cách để phòng chống lỗi lặp đó là chỉ ra một
reverse-path có giá trị null trong lệnh MAIL của một thông điệp thông báo lỗi như sau:
MAIL FROM:<>
Ví dụ chúng ta có một hệ thống lưu chuyển như sau: Thông báo trong lệnh trả lời từ
JOE tại máy HOSTW và gửi thông qua máy HOSTX tới HOSTY với những hướng dẫn
lưu chuyển trên máy HOSTZ. Sự giao dịch giữa máy HOSTY và HOSTX ngay bước đầu
tiên trả về thông điệp thông báo lỗi không phân phối thư như sau:
S: MAIL FROM:<>
R: 250 ok
S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA>
R: 250 ok
S: DATA
R: 354 send the mail data, end with .
S: Date: 23 Oct 81 11:22:33
S: From: SMTP@HOSTY.ARPA
S: To: JOE@HOSTW.ARPA
S: Subject: Mail System Problem
S: Sorry JOE, your message to SAM@HOSTZ.ARPA lost.
S: HOSTZ.ARPA said this:
S: "550 No Such User"
S: .
R: 250 ok
2.3.2.3. Các lệnh SMTP cơ bản
Để kết thúc mục này chúng tôi đưa ra bảng các lệnh cơ bản của SMTP để các bạn
tiện tham khảo.

STT Lệnh Cú pháp Sử dụng
1 HELO HELO <SP> domain>
<CRLF>
Định danh Sender-SMTP đối
với Receiver-SMTP, tham số
<domain> thường là tên máy.
2 MAIL MAIL <SP> FROM:<reverse-path>
CRLF>
Khởi tạo phiên giao dịch mail
tới một hoặc nhiều mailbox
và đồng thời định danh người
gửi bằng tham số reverse-path
3 RCPT RCPT <SP> TO:<forward-path>
<CRLF>
Định danh một người nhận
dữ liệu mail thông qua tham
số forward, nếu nhiều người
nhận thì sử dụng nhiều dòng
lệnh.
4 DATA DATA <CRLF> Các dòng sau lệnh này sẽ là
dữ liệu thư.
5 RSET RSET <CRLF> Chỉ ra phiên giao dịch thư
hiện tại sẽ bị loại bỏ.
6 SEND SEND <SP> FROM:<reverse-path>
CRLF>
Khởi tạo phiên giao dịch dữ
liệu thư phân phối tới một
hoặc nhiều terminal. Tham số
reverse-path để định danh
người gửi.
7 SOML SOML <SP> FROM:<reverse-path>
<CRLF>
Khởi tạo phiên giao dịch dữ
liệu mail phân phối tới một
hoặc nhiều terminal hoặc
nhiều mailbox. Tham số
reverse-path để định danh
người gửi.
8 SAML SAML <SP> FROM:<reverse- Khởi tạo phiên giao dịch dữ

path> <CRLF> liệu mail phân phối tới một
hoặc nhiều terminal và nhiều
mailbox. Tham số reverse-path
để định danh người gửi.
9 VRFY VRFY <SP> <string>
<CRLF>
Yêu cầu người nhận mail xác
nhận một người sử dụng.
10 EXPN EXPN <SP> <string>
<CRLF>
Yêu cầu xác nhận tham số để
định danh một danh sách thư.
11 HELP HELP [<SP> <string>]
<CRLF>
Người nhận gửi thông tin trợ
giúp tới người gửi.
12 NOOP NOOP <CRLF> Nhận được lệnh này từ phía
người gửi, tức là không thực
hiện gì khác, thì người nhận
trả lời OK.
13 QUIT QUIT <CRLF> Lệnh này yêu cầu người nhận
gửi tín hiệu trả lời OK, sau đó
đóng phiên giao dịch.
14 TURN TURN <CRLF> Lệnh này yêu cầu người nhận
hoặc là phải gửi tín hiệu OK
và sau đó đóng vai trò là
Sender-SMTP, hoặc là phải
gửi tín hiệu từ chối và trả về
đúng vai trò Receiver-SMTP.
2.3.3. Các mở rộng của giao thức truyền thư đơn giản
Cùng với số lượng người sử dụng thư điện tử ngày càng tăng, các phần mềm thư
client và các SMTP server ngày được bổ sung thêm nhiều tính năng mới. Đối với các
máy chủ SMTP người ta đã mở rộng thêm chức năng cho giao thức truyền thư đơn giản
SMTP. Năm 1993, RFC 1455 đã giới thiệu chung về phần mở rộng cho giao thức truyền

thư đơn giản SMTP. Các tài liệu tiếp theo được ra đời nhằm cụ thể hoá cho RFC 1425 là
RFC 1651 vào năm 1994 và RFC 1869 vào năm 1995. Các RFC này bổ sung thêm ba
phần chính cho SMTP nguyên thuỷ, bao gồm:
 Các lệnh SMTP mới (RFC 1425)
 Đăng ký các mở rộng dịch vụ SMTP (RFC 1651)
 Các tham số bổ sung cho các lệnh SMTP MAIL FROM và RCPT TO (RFC 1869).
Để tương thích với các máy chủ SMTP thế hệ cũ, cần phải có một phương thức
nhằm cho phép ứng dụng thư client xác định xem máy chủ có hỗ trợ các phần mở rộng
hay không. Công việc này được thực hiện qua lệnh “enhanced hello” (EHLO). Khi kết
nối với một máy chủ, người sử dụng thư tín có thể dùng lệnh EHLO. Nếu máy chủ hỗ trợ
các phần mở rộng SMTP, máy chủ sẽ phúc đáp kết quả thực hiện lệnh đã thành công và
liệt kê phần mở rộng hiện máy chủ đó hỗ trợ. Nếu máy chủ không hỗ trợ phần mở rộng
SMTP, sẽ có thông báo kết quả thực hiện lệnh không thành công, khi đó MUA phải thực
hiện lệnh HELO chuẩn. Các máy chủ hỗ trợ các giao thức truyền thư đơn giản mở rộng
được xem như cũng được xem như các máy chủ Extended SMTP (ESMTP).
Dưới đây là một ví dụ về phần giao dịch với máy chủ sử dụng câu lệnh mở rộng
EHLO.
telnet mail.dcs.vn 25
Connected to mail.dcs.vn
Escape character is '^]'
220 test.mail.vn ESMTP Service (Sample Mail Server String)
EHLO test.mail.vn
250 test.mail.vn says hello
250-HELP
250-EXPN
250 SIZE 20971520
...
Trong ví dụ trên, máy chủ chỉ hỗ trợ một phần mở rộng- SIZE. Tuy nhiên, trên thực
tế một server có thể hỗ trợ nhiều phần mở rộng khác nhau. Bảng dưới đây sẽ liệt kê một

số mở rộng cho SMTP được công bố trong các RFC tương ứng. Ví dụ, RFC 2554 chỉ ra
lệnh và giao thức mới cho việc định danh và xác thực người sử dụng.
SMTP Extensions RFC
Mở rộng dịch vụ SMTP cho việc khai báo độ lớn của thông điệp
thư điện tử
1870
Mở rộng dịch vụ SMTP cho đường dẫn lệnh 2920
Mở rộng dịch vụ SMTP cho việc truyền các thông điệp thư điện
tử MIME dưới dạng nhị phân với dung lượng lớn
3030
Mở rộng dịch vụ SMTP cho việc xác thực 2554
Mở rộng dịch vụ SMTP cho việc bảo mật SMTP thông qua giao
thức TLS
2487
Mở rộng dịch vụ SMTP cho việc trả mã lỗi mở rộng 2034
Mở rộng dịch vụ SMTP cho việc bắt đầu một hàng đợi thông điệp
từ xa
1985
Mở rộng dịch vụ SMTP cho việc thông báo trạng thái phân phối
thư
1891
2.4. Các chuẩn Client nhận thư
2.4.1. Giới thiệu
Khi một thông điệp được LDA phân phối, người sử dụng cần phải truy nhập tới
máy chủ thư để nhận thông điệp. Các phần mềm mail client (MUA) được sử dụng để truy
nhập đến các máy chủ thư và nhận các thông điệp thư tín. Hiện tại có nhiều phương pháp
cho phép người sử dụng có thể truy cập đến hộp thư của mình, một trong các phương
pháp đơn giản nhất là truy cập trực tiếp bằng cách sử dụng các lệnh.
Một hệ thống thư điện tử đơn giản là một hệ thống thư tín cho phép tất cả người sử
dụng có thể truy nhập trực tiếp tới hộp thư của họ. Đối với mỗi tài khoản người dùng
trong hệ thống sẽ tương ứng có một thư mục trong thư mục home. Khi các thông điệp thư

tín được nhận, người sử dụng có thể dùng dòng lệnh dựa trên các chương trình thư như
các lệnh “mail” hoặc “pine” để truy cập trực tiếp tới hộp thư.
Đối với người sử dụng, đặc biệt là người sử dụng bên ngoài, việc truy nhập đến máy
chủ thư thông qua thao tác dòng lệnh là một yếu tố làm mất an toàn cho tài khoản thư của
họ. Để giảm bớt rủi ro, các giao thức truy nhập hộp thư được sửa đổi. Hai giao thức truy
cập hộp thư hiện được sử dụng phổ biến nhất là POP3 và IMAP. Dưới đây chúng ta sẽ
tìm hiểu chi tiết về hai giao thức hiện đang được sử dụng phổ biến trên.
2.4.2. Giao thức nhận thư POP3
Giao thức POP3 được sử dụng để truy nhập và lấy các thông điệp thư điện tử từ
mailbox trên máy chủ thư tín. POP3 được thiết kế hỗ trợ xử lý mail trong chế độ Offline.
Theo chế độ này, các thông báo mail được chuyển tới máy chủ thư tín và một chương
trình thư client trên một máy trạm kết nối tới máy chủ thư tín đó và tải tất cả các thông
báo mail tới máy trạm đó. Và sau đó, tất cả quá trình xử lý mail được diễn ra trên chính
máy trạm này.
2.4.2.1. Nguyên tắc hoạt động và các lệnh của giao thức POP3
Hoạt động của giao thức POP3 được thể hiện ở hình dưới đây:
POP3
Client
POP3
Server
TCP connection
AUTHORIZATION state
TRANSACTION state
UPDATE state
Hình 2.2 Sơ đồ hoạt động của POP3
Một POP3 Server được thiết lập chế độ đợi ở cổng 110. Khi POP3 client muốn sử
dụng dịch vụ POP3, nó thiết lập một kết nối TCP tới máy server ở cổng 110. Khi kết nối
TCP được thiết lập, POP3 server sẽ gửi một lời chào tới client. Phiên làm việc giữa client
và server được thiết lập. Sau đó client gửi các lệnh tới server và server đáp lại (response)
các lệnh đó tới tận khi đóng kết nối hoặc kết nối bị huỷ bỏ.

Một phiên POP3 có 3 trạng thái là: AUTHORIZATION, TRANSACTION và
UPDATE.
 Trạng thái AUTHORIZATION: Một khi kết nối TCP được mở và POP3 server gửi
lời chào (greeting) tới client thì phiên vào trạng thái AUTHORIZATION, trong
trạng thái này server sẽ xác thực client. Khi server xác thực client thành công thì
phiên vào trạng thái TRANSACTION.
 Trạng thái TRANSACTION: Tiếp theo trạng thái AUTHORIZATION là trạng thái
TRANSACTION. Trong trạng thái này, client có thể truy nhập tới mailbox của
mình trên server để kiểm tra, nhận thư...
 Trạng thái UPDATE: Khi client gửi lệnh QUIT tới server từ trạng thái
TRANSACTION, thì phiên vào trạng thái UPDATE, trong trạng thái này server gửi
goodbye tới client và đóng kết nối TCP, kết thúc phiên làm việc. Nếu client gửi lệnh
QUIT từ trạng thái AUTHORIZATION, thì phiên PO3 sẽ kết thúc mà không vào
trạng thái UPDATE.
2.4.2.2. Các lệnh trong giao thức POP3
Các lệnh trong POP3 có thể có một hoặc nhiều đối số. Kết thúc của lệnh bởi một
cặp CRLF. Các từ khoá và đối số trong lệnh là các ký tự trong ASCII.
Một lời đáp lại (response) từ POP3 server gồm một mã trạng thái và theo sau là các
thông tin. Có hai mã trạng thái hiện hành là: thành công (+OK) và lỗi (-ERR).
Cơ chế xác thực và các lệnh trong trạng thái AUTHORIZATION.
Khi phiên POP3 vào trạng thái AUTHORIZATION, client phải nhận danh và xác
thực chính nó với POP3 server. Trong tài liệu này trình bày hai cơ chế xác thực: Cơ chế
thứ nhất sử dụng kết hợp hai lệnh USER và PASS; cơ chế xác thực thứ hai sử dụng lệnh
APOP. Ngoài ra còn có các cơ chế xác thực khác được mô tả trong RFC 1734.
Xác thực sử dụng kết hợp hai lệnh USER và PASS:
Để xác thực sử dụng kết hợp lệnh USER và PASS, trước hết client phải gửi lệnh
USER với tham số là tên người dùng đến server, sau khi server đáp lại với mã trạng thái
là thành công (+OK) thì tiếp theo client gửi lệnh PASS kèm tham số mật khẩu của người
dùng để hoàn thành cơ chế xác thực cho user này. Nếu POP3 server đáp lại với mã trạng
thái là +OK thì quá trình xác thực cho user này thành công, còn ngược lại (mã trạng thái

là -ERR) thì xác thực không thành công và client phải sử dụng lại lệnh PASS để xác thực
lại.
Lệnh USER
Cú pháp: USER name
Đối số: name là tên người dùng.
Mô tả: Được sử dụng trong trạng thái AUTHORIZATION để gửi tên của user tới
POP3 server. Server sẽ đáp lại thành công (+OK) nếu nhập tên user là đúng và ngược lại
sẽ trả lại mã lỗi (-ERR). Chú ý: trong các ví dụ kể từ đây, ký hiệu C: được gửi từ Client
và S: là response của Server.
Ví dụ:
C: USER mrose
S: +OK mrose is a real hoopy frood
...
C: USER frated
S: -ERR sorry, no mailbox for frated here
Lệnh PASS
Cú pháp: PASS password
Đối số: password là mật khẩu của user để truy nhập tới mailbox.
Mô tả: Lệnh này chỉ được sử dụng trong trạng thái AUTHORIZATION để gửi mật
khẩu của người dùng tới POP3 server. Lệnh này phải được thực hiện sau lệnh USER và
một khi server đáp lại lệnh USER là thành công.
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 maildrop already locked
Cơ chế xác thực sử dụng lệnh APOP
Cú pháp: APOP name disgest
Đối số:
name: tên của user
disgest: một chuỗi MD5 disgest
Mô tả: Việc xác thực trong phiên sử dụng kết hợp lệnh USER/PASS có nhược điểm
là mật khẩu được truyền rõ trên mạng. Để khắc phục nhược điểm này thì cơ chế xác thực
sử dụng lệnh APOP được sử dụng trong giao thức POP3 . Phương pháp xác thực này cho
phép cả xác thực và bảo vệ replay bằng cách không gửi mật khẩu ở dạng rõ trên mạng.
Một server cài đặt lệnh APOP sẽ gửi kèm một timestamp vào trong lời chào
(greeting) tới client (greeting được gửi khi kết nối TCP được thiết lập gi ữa POP3 client
và PO3 server). Dạng của timestamp được mô tả trong RFC 822 và chúng phải khác nhau
mỗi lần POP3 server gửi lời chào tới client. Ví dụ, trên ứng dụng UNIX, mỗi tiến trình
riêng biệt được sử dụng cho timestamp của một POP3 server, cú pháp của timestamp có
thể là:
<process-ID.clock@hostname>
Trong đó 'process-ID' là số hiệu tiến trình (PID), clock là clock của hệ thống và
hostname là tên miền đầy đủ.
POP3 client sẽ lấy timestamp này (bao gồm cả dấu ngoặc nhọn) cùng với bí mật
dùng chung mà chỉ client và server được biết (mật khẩu truy nhập mailbox của người
dùng) để tính toán tham số disgest sử dụng giải thuật MD5. Sau đó gửi lệnh APOP với
các tham số đi kèm tới server.
Khi POP3 server nhận lệnh APOP, nó kiểm tra disgest đó. Nếu disgest đúng, thì
POP3 server sẽ đáp lại tới client thành công (+OK) và phiên PO3 vào trạng thái

TRANSACTION. Trái lại, server sẽ thông báo lỗi tới client và phiên POP3 vẫn ở trạng
thái AUTHORIZATION.
Ví dụ:
S: +OK POP3 server ready 1896.697170952@dbc.mtview.ca.us>
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK maildrop has 1 message (369 octets)
Trong ví dụ này bí mật dùng chung là chuỗi 'tanstaaf'. Do đó đầu vào của giải thuật
MD5 này là chuỗi <1896.697170952@dbc.mtview.ca.us>tanstaaf
Đầu ra có giá trị là c4c9334bac560ecc979e58001b3e22fb
Các lệnh trong trạng thái TRANSACTION
Các lệnh trong trạng thái TRANSACTION là: STAT, LIST, TOP, NOOP, RETR,
DELE, UIDL, QUIT và RSET
STT Tên lệnh Cú pháp Mô tả
1 STAT STAT Lệnh STAT được sử dụng để nhận số tổng
thông báo và tổng số byte của các thông báo
đó trong mailbox.
2 LIST LIST [msg] [msg] là số nhận danh thông báo
Lệnh LIST được sử dụng có hoặc không tham
số. Nếu không có tham số, LIST sẽ trả lại số
nhận danh và kích cỡ của mỗi thông báo trong
mailbox.
3 RETR RETR msg msg: là số nhận danh của thông báo
Server sẽ gửi toàn bộ thông báo tương ứng với
số nhận danh thông báo tới client
4 DELE DELE msg msg: là số nhận danh của thông báo
Lệnh DELE đánh dấu một thông báo để xoá.

Khi phiên làm việc kết thúc thì tất cả các thông
báo bị đánh dấu là xoá mới bị xoá hẳn.
5 RSET RSET msg msg: là số nhận danh của thông báo
Lệnh này thì ngược với lệnh DELE, tức là nó
được sử dụng để bỏ đánh dấu xoá thông báo
được thực hiện bởi lệnh DELE.
6 NOOP NOOP Lệnh này đơn giản chỉ là để kiểm tra kết nối
đến Server. Server sẽ đáp lại với mã trạng thái
+OK
7 TOP TOP msg
[n]
msg: là số nhận danh thông báo.
n: là số dòng
Nếu không có đối số [n] thì lệnh TOP sẽ lấy
header của thông báo được chỉ ra từ server.
Nếu có đối [n] thì TOP sẽ lấy herder của thông
báo cùng với n dòng của thông báo.
8 UIDL UIDL
[msg]
msg: là số nhận danh thông báo.
Nếu không có đối số [msg] thì lệnh UIDL sẽ
trả lại các nhận danh duy nhất của mỗi thông
báo (unique-id). Nếu có đối số [msg] thì UIDL
sẽ trả lại nhận danh duy nhất cho thông báo
đó. Nhận danh duy nhất của một thông báo là
một chuỗi gồm 1 đến 70 ký tự trong khoảng
0x21 đến 0x7E, nhận danh này là duy nhất cho
mỗi thông báo, nó được duy trì trong phiên
làm việc thậm chí phiên kết thúc mà không vào
trạng thái UPDATE.
9 QUIT QUIT Vào trạng thái UPDATE, kết thúc phiên
POP3.

2.4.2.3. Ví dụ về các lệnh sử dụng trong giao thức POP3
Trong các ví dụ dưới đây được thực hiện bởi sử dụng chương trình Telnet để thao
tác với mailbox trên POP3 mail server. Máy trạm được cài đặt hệ điều hành Win98 và
POP3 server cài MDEAMON.
Để chạy bắt đầu từ Start/Run gõ lệnh telnet <tên_pop_server> 110
Ví dụ1: Một phiên làm việc PO3 sử dụng các lệnh USER, PASS, STAT, LIST,
NOOP, RETR, QUIT
Hình 2.3 Ví dụ phiên làm việc các lệnh POP3
Ví dụ 2: Một phiên làm việc PO3 sử dụng các lệnh USER, PASS, STAT, LIST,
UIDL, DELE, RSET, TOP, QUIT

Hình 2.4 Ví dụ phiên làm việc POP3
2.4.3. Giao thức truy nhập thông báo Internet (IMAP)
IMAP là một giao thức cho phép client truy nhập email trên một server, không chỉ
tải thông điệp thư điện tử về máy của người sử dụng (POP) mà có thể thực hiện các công
việc như: tạo, sửa, xoá, đổi tên mailbox, kiểm tra thông điệp mới, thiết lập và xoá cờ
trạng thái,...
IMAP được thiết kế trong môi trường người dùng có thể đăng nhập vào server
(cổng 143/tcp) từ các máy trạm khác nhau. Nó rất hữu ích khi việc tải thư của người dùng
không về một máy cố định, bởi không phải lúc nào cũng chỉ sử dụng một máy tính.
Trong khi đó POP không cho phép người sử dụng tác động lên các thông điệp trên server.
Đơn giản POP chỉ được phép tải thư điện tử của người dùng đang được quản lý trên
server, trong inbox của người sử dụng đó. Như vậy, POP chỉ cung cấp quyền truy nhập
tới inbox của người sử dụng mà không hỗ trợ quyền truy nhập tới pulbic folder (IMAP).
Sử dụng IMAP với các mục đích sau:
 Tương thích đầy đủ với các chuẩn thông điệp Internet (ví dụ MIME).
 Cho phép truy nhập và quản lý thông điệp từ nhiều máy tính
khác nhau.
 Hỗ trợ cả 3 chế độ truy nhập: online, offline, và disconnected.
 Hỗ trợ truy nhập đồng thời tới các mailbox dùng chung.

 Phần mềm bên client không cần thiết phải biết kiểu lưu trữ file
của server.
2.4.3.1. Hoạt động của IMAP
Kết nối IMAP bao gồm: kết nối mạng cho client/server, khởi tạo trên server hay
gọi là "hello message", và những tương tác client/server tiếp theo. Những tương tác này
bao gồm: lệnh từ client, dữ liệu trên server, và trả lời trên ser ver. Tương tác giữa IMAP
client và IMAP server thực hiện dựa vào các giao thức gửi/nhận của client/server. Cụ
thể sự tương tác được thể hiện như sau.
Giao thức gửi của client và nhận của server
Khi hoạt động, bên client gửi một lệnh, mỗi lệnh có một định danh (sắp xếp theo
alphabel, ví dụ: A00001, A00002) được gọi là một thẻ. Mỗi thẻ này được sinh từ phía
client cho từng lệnh khác nhau. Có 2 trường hợp dòng lệnh gửi từ phía client không được
coi là một lệnh: Thứ nhất, tham số lệnh được trích dẫn trong dấu ngoặc. Thứ hai, tham số
lệnh yêu cầu thông tin phản hồi từ phía server (xem lệnh AUTHENTICATE ở mục sau).
Trong từng trường hợp thì server gửi một thông tin trả lời (cho lệnh tiếp theo bên phía
client) nếu nó đã có các octet và phần lệnh còn lại tương ứng. Chú ý rằng đặt trước thông
tin trả lời là một dấu "+".
Nếu server nhận ra một lỗi dòng lệnh, thì nó gửi thông tin trả lời là BAD để huỷ bỏ
lệnh và chống việc gửi thêm lệnh từ phía client. Server có thể gửi một thông tin trả lời
cho nhiều lệnh khác nhau cùng một thời điểm (trong trường hợp gửi nhiều lệnh), hoặc dữ
liệu không gán thẻ. Trong trường hợp khác khi yêu cầu tiếp tục gửi lệnh đang chờ, thì
client thực hiện theo thông tin trả lời lệnh từ phía server và đọc thông tin trả lời khác từ
server đến. Trong tất cả các trường hợp, thì client phải gửi các thông tin hoàn thành lệnh
trước khi khởi tạo lệnh mới.
Giao thức nhận bên server đọc dòng lệnh từ phía client gửi sang, phân tích lệnh và
các tham số, sau đó truyền tải dữ liệu trên server và thông tin hoàn thành lệnh sang client.
Giao thức gửi của server và nhận của client
Dữ liệu đã truyền tải sang client và tất nhiên gồm cả thông tin trạng thái thông báo
chưa kết thúc lệnh (đặt trước là dấu "*", được gọi là không gán thẻ). Dữ liệu trên server
có thể được gửi theo lệnh từ phía client, hoặc có thể được gửi từ phía server mà không

cần theo lệnh từ phía client. Tất nhiên không có sự khác nhau về cú pháp giữa 2 cách gửi
này. Thông tin hoàn thành đáp lại từ phía server để chỉ ra rằng công việc thực hiện đã
hoàn thành hoặc bị lỗi. Nó được gán thẻ tương tự thẻ lệnh đã sử dụng cho các lệnh bên
phía client. Do vậy, nếu có nhiều hơn một lệnh thì thẻ sử dụng trong thông tin hoàn thành
lệnh từ phía server còn nhằm dùng để xác nhận sự tương ứng với lệnh mà nó cần thông
báo. Thông tin hoàn thành lệnh từ phía server sử dụng một trong 3 chuỗi sau: OK để
thông báo lệnh đã thực hiện thành công, NO để thông báo lệnh thực hiện lỗi, và BAD để
thông báo bị lỗi khi sử dụng giao thức (lệnh không được công nhận, hoặc cú pháp lệnh
sai).
Giao thức nhận của client đọc thông báo từ phía server gửi sang, sau đó nó thực
hiện theo thông báo đó dựa theo dấu hiệu (+, hoặc *) trên thông báo. Chú ý rằng, một
client phải chấp nhận bất kỳ thông báo nào đó từ phía server ở mọi thời điểm, bao gồm cả
dữ liệu của server mà nó đã yêu cầu. Dữ liệu của server được ghi lại, do đó client có thể
tham chiếu tới bản sao mà không cần gửi lệnh yêu cầu dữ liệu tới server. Nhưng điều này
chỉ thực hiện được khi dữ liệu của server đã được ghi lại.
2.4.3.2. Các lệnh IMAP
Trong mục này chúng tôi đưa ra danh sách lệnh IMAP, các lệnh này được tổ chức
theo trạng thái mà lệnh được phép thực thi. Các lệnh được phép với nhiều trạng thái,
nhưng ở đây chúng tôi chỉ đưa ra tối thiểu trạng thái mà lệnh được phép. Để xem chi
tiết về cú pháp chuẩn của các lệnh IMAP bạn tham khảo RFC 2062, 2060. Dưới đây
chúng tôi chỉ đưa ra các tham số, thông tin báo lệnh, thông báo hoàn thành lệnh, và mục
đích sử dụng của các lệnh này.
STT Mô tả lệnh
1 CAPABILITY
Các tham số: none
Phúc đáp: *: CAPABILITY
Kết quả trả về: OK hoặc BAD
Chức năng: Yêu cầu đưa ra danh sách các khả năng mà server hỗ trợ.
2 NOOP

Phúc đáp: không
Chức năng: khởi tạo chu kỳ lấy hoặc cập nhật trạng thái thông điệp
hoặc khởi tạo bộ thời gian tự logout trên server.
3 LOGOUT
Phúc đáp: *: BYE
Chức năng: thông báo ngắt kết nối.
4 AUTHENTICATE
Các tham số: tên kỹ thuật xác thực
Phúc đáp: dữ liệu yêu cầu
Kết quả trả về: OK hoặc NO hoặc BAD
Chức năng: Chỉ ra một kỹ thuật xác thực server (tham khảo RFC
1731). Nếu server hỗ trợ kỹ thuật này, thì nó thực hiện trao đổi giao
thức xác thực để xác thực và định danh client. Nếu kỹ thuật này
không được hỗ trợ bởi server, thì server huỷ bỏ lệnh này bằng cách
gửi lại thông báo NO.
5 LOGIN
Các tham số: mật khẩu, người dùng
Phúc đáp: none
Chức năng: Định danh client đối với server và đưa mật khẩu dạng text
để xác thực người dùng.
6 SELECT

Các tham số: tên mailbox
Phúc đáp: *: FLAGS, EXITS, RECENT hoặc OK *: UNSEEN,
PERMANENTFLAGS.
Chức năng: Chọn mailbox đã chỉ ra để truy nhập.
7 EXAMINE
Phúc đáp: *: FLAGS, EXITS, RECENT hoặc OK *: UNSEEN,
PERMANENTFLAGS.
Chức năng: Tương tự lệnh SELECT nhưng mailbox đã chọn là read-only,
không thể thay đổi thuộc tính PERMANENT của mailbox.
8 CREATE
Phúc đáp: none
Chức năng: Tạo mailbox với tên đã chỉ ra.
9 DELETE
Phúc đáp: none
Chức năng: Xoá mailbox đã chỉ ra.
10 RENAME
Các tham số: tên mailbox cũ, tên mailbox mới
Phúc đáp: none

Chức năng: Đổi tên mailbox đã tồn tại thành tên mailbox mới.
11 SUBSCRIBE
Phúc đáp: none
Chức năng: Thêm mailbox vào tập các mailbox có trạng thái "active"
hoặc "subscribed" của server.
12 UNSUBSCRIBE
Phúc đáp: none
Chức năng: Xoá mailbox đã chỉ ra trong tập các mailbox có trạng thái
"active " hoặc "subscribed" của server.
13 LIST
Các tham số: tên tham chiếu, tên mailbox
Phúc đáp: *: LIST
Chức năng: Trả về tập các tên client có hiệu lực.
14 LSUB
Các tham số: tên tham chiếu, tên mailbox
Phúc đáp: *: LSUB
Chức năng: Trả về tập các tên người dùng có khai báo trạng thái
"active " hoặc "subscribed".
15 STATUS
Các tham số: tên mailbox, tên trạng thái dữ liệu

Phúc đáp: *: STATUS
Chức năng: Yêu cầu các trạng thái dữ liệu cho mailbox đã chỉ ra.
16 APPEND
Các tham số: tên mailbox, [các cờ], [ngày/tháng], thông điệp
Phúc đáp: none
Kết quả : OK hoặc NO hoặc BAD
Chức năng: Nối thêm thông điệp vào cuối mailbox đích đã chỉ ra.
17 CHECK
Phúc đáp: none
Chức năng: Yêu cầu điểm kiểm soát mailbox đã chọn (ví dụ, trạng
thái vùng nhớ của mailbox trên server).
18 CLOSE
Phúc đáp:
Chức năng: Xoá vĩnh viễn tất cả các thông điệp có thiết lập cờ Delete
của mailbox đã chọn, và trả về trạng thái đã xác thực.
19 EXPUNGE
Phúc đáp: *: EXPUNGE
Chức năng: Xoá vĩnh viễn tất cả các thông điệp có thiết lập cờ Delete
của mailbox đã chọn, và trả thông báo OK tới client.

20 SEARCH
Các tham số: OPTIONAL [CHARSET], tiêu chuẩn tìm kiếm
Phúc đáp: *: SEARCH
Chức năng: Tìm kiếm các mailbox có tiêu chuẩn tìm kiếm đã
đưa ra.
21 FETCH
Các tham số: tập thông điệp, danh mục dữ liệu
Phúc đáp: *: FETCH
Chức năng: Lấy dữ liệu đính kèm thông điệp trong mailbox.
22 STORE
Các tham số: tập thông điệp, danh mục dữ liệu, giá trị của danh mục
dữ liệu
Phúc đáp: *: FETCH
Chức năng: Thay đổi dữ liệu đính kèm thông điệp trong mailbox.
23 COPY
Các tham số: tập thông điệp, tên mailbox
Phúc đáp: none
Chức năng: Lệnh này sao lưu các thông điệp đã chỉ ra vào mailbox
đích đã xác định.
24 UID
Các tham số: tên lệnh, các tham số lệnh
Phúc đáp: *: FETCH, SEARCH

Chức năng: Lệnh này thể hiện ở 2 dạng: Dạng thứ nhất, nó sử dụng
lệnh COPY, FETCH, hoặc STORE và các tham số của các lệnh tương
ứng. Dạng thứ 2, nó sử dụng lệnh SEARCH và các tham số của lệnh
này.
2.4.4. So sánh IMAP và POP
Như đã trình bày ở các mục trên thì điểm khác biệt giữa 2 giao thức nhận mail đó
là: POP được thiết kế xử lý mail ở chế độ "offline"; còn IMAP hỗ trợ cả 3 chế độ
"offline", "online", và "disconnected". Trong mục này chúng tôi sẽ so sánh một cách
ngắn gọn về các công nghệ POP và IMAP.
Đặc điểm chung về các công nghệ POP và IMAP
 Hỗ trợ chế độ offline.
 Mail được phân phối tới một Mail server đã chia sẻ (luôn được
kích hoạt).
 Mail đến có thể nhận từ một máy client có nhiều kiểu platform
khác nhau.
 Mail đến có thể nhận từ bất cứ nơi nào trong mạng.
 Các giao thức rất rõ ràng và chuẩn theo các RFC đã được công bố
trên mạng.
 Sử dụng hiệu quả trên nhiều phần mềm miễn phí (có cả source).
 Cho các client trên máy PC, Mac, và Unix.
 Sử dụng hiệu quả trên nhiều phần mềm thương mại.
 Định hướng mạng Internet; không yêu cầu sử dụng SMTP mail gateway.
 Các giao thức chỉ giải quyết vấn đề truy nhập; cả 2 đều có khả năng nhận các mail
được gửi dựa trên giao thức SMTP.
 Hỗ trợ các ID thông điệp cố định (cho hoạt động "disconnected").
Ưu điểm của POP
Giao thức đơn giản hơn và dễ thực hiện hơn.
Có nhiều phần mềm client sử dụng hơn.
Ưu điểm của IMAP

Có thể thao tác các cờ trạng thái thông điệp trên server.
Có thể lưu trữ các thông điệp tương tự như khi lấy chúng.
Có thể truy nhập và quản lý nhiều mailbox.
Hỗ trợ cập nhật và truy nhập đồng thời tới các mailbox đã chia sẻ.
Có thể truy nhập dữ liệu không phải là mail: NetNews, documents,...
Cũng có thể sử dụng lược đồ offline để tối thiểu thời gian kết nối và không gian đĩa.
Có cả phần giao thức quản lý cấu hình người sử dụng.
Xây dựng tối ưu khả năng "online", đặc biệt cho các kết nối tốc độ thấp.

CHƯƠNG 3
AN TOÀN ỨNG DỤNG MÁY CHỦ TÍN VÀ NỘI DUNG
THƯ
3.1. An toàn ứng dụng máy chủ thư tín
3.1.1. Cài đặt máy chủ thư tín an toàn
Việc cài đặt và thiết lập cấu hình an toàn ứng dụng máy chủ thư đối với hệ điều
hành sẽ được bàn luận chi tiết hơn trong chương 5. Do vậy về tổng quan chúng ta có thể
chỉ cần quan tâm đến việc cài đặt và thiết lập cấu hình cho một số các dịch vụ được yêu
cầu đối với một máy chủ thư, và tạm bỏ qua những rủi ro có thể xuất hiện do chưa thực
hiện việc lấp lỗ hổng và cập nhật hệ thống.
Trong quá trình cài đặt thiết lập cấu hình cho máy chủ thư nếu thấy bất kỳ ứng
dụng, dịch vụ hay script nào không cần thiết nên loại bỏ ngay trước khi kết thúc quy trình
cài đặt.
Trong quá trình cài đặt máy chủ thư, những bước sau cần được thực hiện:
 Cài đặt phần mềm máy chủ thư trên máy chủ chuyên dụng,
 Cài đặt ở mức tối thiểu các dịch vụ Internet cần có.
 Áp dụng các công nghệ lấp lỗ hổng và nâng cấp hệ thống để chống các
hiểm hoạ biết trước.
 Tạo ra các phân vùng đĩa (logic hoặc vật lý) sử dụng cho việc cài đặt ứng
dụng thư.
 Loại bỏ hoặc disable tất cả dịch vụ được cài đặt bởi ứng dụng chủ thư
không cần thiết (ví dụ: thư dựa trên Web, FTP, tiện ích quản lý từ xa, ...)
 Loại bỏ tất cả những tiện ích không rõ nguồn gốc khỏi máy chủ thư.
 Loại bỏ tất cả tiện ích được sử dụng làm ví dụ hoặc các công cụ đã được sử
dụng để test khỏi máy chủ thư.
 Áp dụng các cơ chế an toàn có sẵn đối với một server
 Thiết lập lại cấu hình cho các giao thức SMTP, POP, và IMAP.

 Loại bỏ các lệnh không cần thiết hoặc có thể gây nguy hiểm cho máy chủ
thư (Ví dụ, VRFI và EXPN)
3.1.2. Cấu hình an toàn ứng dụng máy chủ thư tín
Hầu hết các hệ điều hành trên các máy chủ thư đã cung cấp khả năng phân quyền
cho việc truy nhập đến hệ thống các file, các thiết bị, và nguồn tài nguyên trên máy chủ
đó. Bất cứ nguồn tài nguyên nào trên máy chủ mà mail server có thể truy nhập đến đều là
tiềm năng có thể chia sẻ cho tất cả người sử dụng trong hệ thống thư tín. Phần mềm mail
server hỗ trợ bổ sung việc truy nhập đến các tệp tin, các thiết bị, và nguồn tài nguyên
nhằm quản lý và vận hành các hoạt động của nó. Quan trọng nhất là việc làm sao có thể
đồng nhất các quyền được thiết lập bởi hệ điều hành và chính bản thân phần mềm mail
server. Bên cạnh đó phải đảm bảo được rằng các đối tượng sử dụng mail không được trao
quá nhiều hoặc quá ít quyền.
Như vậy người quản trị máy chủ thư cần tìm ra phương pháp làm thế nào để thiết
lập cấu hình tốt nhất việc quản lý truy nhập để bảo vệ thông tin được lưu trữ trên máy chủ
thư công khai trong hai mối quan hệ dưới đây:
 Hạn chế sự truy nhập của ứng dụng mail server tới các nguồn tài nguyên phụ của
máy tính.
 Hạn chế sự truy cập của người sử dụng đến hệ thống thông qua các quyền bổ sung
được hỗ trợ bởi máy chủ thư, nơi mà những mức điều khiển truy nhập được thiết lập
chi tiết hơn.
Việc thiết lập cấu hình quản lý truy nhập có thể ngăn cấm các thông tin nhạy cảm,
riêng tư khỏi những hiểm hoạ khi một máy chủ thư được công khai hoá. Hơn nữa, quản
lý truy nhập có thể được sử dụng nhằm giới hạn việc sử dụng nguồn tài nguyên trong
trường hợp máy chủ thư bị tấn công từ chối dịch vụ (DoS).
Những đối tượng điển hình trên máy chủ thư cần được quản lý truy nhập bao gồm:
– Các tiện ích phần mềm và các tệp cấu hình của phần mềm mail server.
– Các hệ thống file trực tiếp liên quan đến cơ chế bảo mật:
 Các tệp lưu giá trị băm của mật khẩu và các tệp được sử dụng cho
việc xác thực.
 Các tệp chứa thông tin uỷ quyền được sử dụng trong việc quản lý truy
nhập

giáo trình an toàn thư điện tử

giáo trình an toàn thư điện tử

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (11)

Similaire à giáo trình an toàn thư điện tử

Similaire à giáo trình an toàn thư điện tử (20)

giáo trình an toàn thư điện tử