CHƢƠNG 3 : HỆ THỐNG MAIL QUY MÔ LỚN VÀ CÁC THÁCH THỨC
3.2. Các thách thức đối với hệ thống thƣ điện tử quy mô lớn
3.2.1. Vấn đề lƣu lƣợng lớn
Lưu lượng lớn là một vấn đề đau đầu của các nhà cung cấp dịch vụ thư điện tử. Lưu lượng lớn có hai dạng chính:
1. Lưu lượng vào giờ cao điểm có thể tăng từ 2-6 lần giờ bình thường và gấp 10 lần giờ thấp điểm.
2. Lưu lượng bùng phát do tấn công hoặc do một đợt lây lan virus trên mạng toàn cầu. Khi đó các máy phục vụ SMTP có thể phải nhận hàng trăm nghìn thư, thậm chí hàng nhiều triệu thư trong 1 giờ, tùy thuộc số lượng địa chỉ hộp thư mà hệ thống này quản lý.
Trong hai dạng lưu lượng lớn thì dạng bùng phát khó giải quyết hơn rất nhiều, vì ngoài việc số lượng thư đến và đi tăng đột biến, các tập tin đính kèm cũng tăng dung lượng lên cỡ vài chục đến vài trăm kilobyte, có thể gây tắc nghẽn bất cứ hệ thống thư điện tử nào.
Để giải quyết vấn đề này, các chuyên gia phải xây dựng giải pháp phân tách lưu lượng cục bộ để giảm tối đa ảnh hưởng đến việc lưu thoát thư trên mạng.
3.2.2. Virus, Spam, Relay
Virus: Như chúng ta đã biết, tình hình lây nhiễm Virus trên mạng ngày càng đáng báo động. Theo thống kê của các tổ chức có tên tuổi như IDG, số lượng thư rác bao gồm thư nhiễm virus và thư không mong muốn(thư rác) chiếm tới trên 70% lượng thư gửi và nhận trên Internet. Vì vậy vấn đề lọc các thư nhiễm virus đã trở thành bài toán lớn đối với các ISP.
Hình 27: Lây nhiễm Virus
Spam: Spam là hiện tượng gửi các thư không mong muốn tới hộp thư của người khác như thư quảng cáo, thư lừa đảo, thư khủng bố gây rối … và nhiều mục đích không lành mạnh khác.
Các khó khăn khi xử lý vấn đề Spam: Nguồn spam có thể xác định theo từng thời điểm theo
Địa chỉ gửi.
IP gửi
Chủ đề(subject)
Nội dung(text)
Các nhà cung cấp dịch vụ dựa vào các yếu tố trên để ngăn chặn nguồn gây rối. Các biện pháp giải quyết là chặn thư theo các tiêu chí nói trên.
Tuy nhiên do tất cả các yếu tố để xác định spam trên đều có thể thay đổi theo thời gian, nên việc ngăn chặn spam cũng chỉ có thể thực hiện theo từng thời điểm. Do chủ đích rõ ràng của người gửi, nên địa chỉ, IP, chủ để, nội dung … cũng thay đổi theo từng lần gửi. Việc này dẫn đến hậu quả là các nhà quản trị thư điện tử phải liên tục nhận dạng và cập nhật lại các chính sách chống spam trên hệ thống của mình.
Hình 28: Thư rác
Relay: Relay là một hiện tượng mượn sử dụng SMTP của các nhà cung cấp dịch vụ(đối với những người phát tán thư thông qua hệ thống mà họ không đăng ký sử dụng, thường là với mục đích xấu) để gửi thư đi với số lượng lớn mà nhà cung cấp dịch vụ không kiểm soát được.
Sở dĩ người gửi có thể thực hiện việc này là do một thông lệ cũ của các nhà cung cấp dịch vụ cho phép gửi thư đi mà không kiểm tra xem người gửi có phải là thuê bao của mình hay không.
Hậu quả là các máy phục vụ bị sử dụng relay sẽ thành công cụ gây tấn công cho các hệ thống khác. Các hệ thống sẽ nhận thư bị ảnh hưởng bởi số lượng thư thường rất lớn và không mong muốn như quảng cáo, quảng bá thông tin với lợi ích riêng, thông tin phản động …. Các máy phục vụ cho phép gửi các thư này đi sẽ bị quá tải và bị cô lập do các mạng khác sẽ áp đặt chính sách cấm không cho thư từ các máy phục vụ này gửi đến họ.
Trong môi trường Internet hiện nay, chống Relay là một yêu cầu quan trọng của các nhà cung cấp dịch vụ nếu họ không muốn bị cô lập với các hệ thống thư điện tử khác trên mạng toàn cầu.
Yêu cầu về không gián đoạn dịch vụ: Khách hàng thường đòi hỏi nhà cung cấp đảm bảo dịch vụ không gián đoạn trong bất kỳ tình huống nào vì nhiều cá nhân và doanh nghiệp rất cần tính liên tục của việc nhận và gửi thư điện tử, đặc biệt là các đơn vị và cá nhân hay giao dịch qua mạng. Tuy nhiên, các hệ thống thư điện tử rất dễ bị gián đoạn cung cấp dịch vụ vì các nguyên nhân sau đây:
Lỗi phần cứng
Lỗi phần mềm
Bị tấn công: Spam, virus
Quá tải giờ cao điểm
Gây ra spam, bị sử dụng làm công cụ relay hoặc phát tán các nội dung phản cảm nên bị cô lập với các mạng khác.
Để giải quyết các vấn đề nêu trên, đòi hỏi kỹ sư thiết kế phải có phương án giải quyết tất cả các vấn đề nêu trên. Có những vấn đề sẽ giải quyết bằng thiết kế phần mềm, có những vấn đề giải quyết thông qua cài đặt, đấu nối phần cứng.
3.2.3 Các khó khăn về băng thông trên mạng diện rộng
Các hệ thống thư điện tử lớn thường có lưu lượng vào ra rất lớn. Trong bối cảnh băng thông kết nối mạng Internet vẫn đòi hỏi chi phí cao như hiện nay, việc thiết kế sao cho tối thiểu hóa băng thông mạng trong và mạng ngoài(Internet) cần sử dụng cho một hệ thống thư điện tử là một yêu cầu bức thiết.
Các nhà thiết kế thường phải tính toán lượng dữ liệu trao đổi qua lại giữa hệ thống thư điện tử với bên ngoài và trong nội bộ hệ thống để đưa ra kiến trúc hợp lý nhất.
Việc thiết kế các thành phần của hệ thống thư điện tử phân tán để đáp ứng yêu cầu trên không dễ dàng. Tuy nhiên một cách thường sử dụng là đưa các máy phục vụ vào ra thư điện tử tới các khu vực có lưu lượng sử dụng lớn nhất, sau đó các lưu lượng không được phục vụ tại cụm thiết bị đó sẽ được chuyển tiếp sang các cụm thiết bị ở xa thông qua băng thông mạng trong(domestic backbone).
THƢ ĐIỆN TỬ LƢU LƢỢNG LỚN 4.1. Về mặt kiến trúc
4.1.1. Hệ thống cần cho phép triển khai kiến trúc phù hợp tập trung hay phân tán tuỳ theo phân bố lưu lượng khách hàng.
4.1.2. Hệ thống cần thiết kế với đầy đủ 4 tầng chức năng:
Tầng chia tải: Có thể dùng DNS hoặc thiết bị chia tải cứng
Tầng lọc thư: Có thể dùng thiết bị cứng hoá(Appliance) hoặc các sản phẩm của Norton, Sophos, Trend ...
Tầng giao nhận trên: Với các thành phần SMTP, POP, IMAP, WebMail
Tầng dữ liệu dưới: Với các thành phần Directory, MSS
4.1.3. Kiến trúc phần mềm cần đáp ứng hàng triệu hộp thư trên một tên miền.
4.2. Yêu cầu về tính năng chung của hệ thống
4.2.1. Hệ thống phải sử dụng giao thức SMTP để gửi và nhận thư.
4.2.2. Hệ thống phải cung cấp các dịch vụ: POP3, IMAP4 và cung cấp khả năng truy nhập thư điện tử qua Web (HTTP - Webmail) cho tất cả các hộp thư trên hệ thống.
4.2.3. Cần hỗ trợ Mailing List với khả năng khách hàng đăng ký sử dụng và có quản trị riêng cho mỗi mailing list.
4.2.4. Hệ thống cần sử dụng giao thức LMTP hoặc giao thức tương đương để phục vụ liên lạc riêng giữa MTA và MSS để giảm yêu cầu xử lý thư tại MSS.
4.2.5. Hệ thống cần hỗ trợ sử dụng các chuẩn SMTP, POP3, IMAP4, HTTP qua SSL. 4.2.6. Hệ thống cần có cơ chế chia tải bằng thiết bị chuyển mạch phần cứng.
4.2.7. Hệ thống phải được thiết kế để có thể mở rộng theo cả chiều dọc (tăng năng lực đơn thể thiết bị) lẫn chiều ngang (tăng năng lực bằng thêm đơn thể thiết bị). Tất cả các thành phần đều phải có khả năng tăng năng lực theo chiều ngang.
4.2.8. Hệ thống phải hỗ trợ nhiều domain ảo (virtual domain). Phải hỗ trợ phân cấp quản trị cho từng domain. Cho phép tên tài khoản hộp thư trùng nhau trên các domain khác nhau. Mỗi domain cần có một postmaster riêng và một admin riêng.
4.3. Yêu cầu về tính sẵn sàng của hệ thống.
4.3.1. Hệ thống phải đảm bảo duy trì hoạt động trong trường hợp có sự cố tại đơn thể thiết bị trong hệ thống. Tính sẵn sàng của hệ thống phải được thiết kế để bảo đảm 99,98% thời gian trong năm, không tính thời gian bảo trì hệ thống theo kế hoạch. Nêu yêu cầu về hạ tầng để đáp ứng tính sẵn sàng được yêu cầu.
4.3.2. Hệ thống phải được thiết kế để trong trường hợp gặp thảm họa tại một trong các trung tâm dữ liệu, nếu sử dụng kiến trúc phân tán, các trung tâm dữ liệu còn lại có thể phục vụ được toàn bộ các khách hàng với sự suy giảm nhất định về chất lượng dịch vụ (chấp nhận quá tải hoặc mất thư cũ của khách hàng)
4.3.3. Hệ thống cần dễ dàng khôi phục sau thảm hoạ để giảm thiểu thời gian gián đoạn dịch vụ.
4.3.4. Hệ thống cần cho phép cấu hình sẵn sàng cao với các chế độ linh hoạt: N+1, N+2, … N+N.
4.4. Yêu cầu về hạ tầng cho hệ thống
4.4.1. Hệ thống cần được thiết kế với đòi hỏi hạ tầng ở mức thấp. Có thể hiểu trên các khía cạnh nguồn điện, băng thông Internet đòi hỏi thấp mà vẫn đảm bảo hoạt động với cùng lượng khách hàng phục vụ.
4.4.2. Hạ tầng đòi hỏi cho hệ thống không có những đặc thù riêng khó đáp ứng, như các điện thế, nhiệt độ môi trường, giao thức kết nối mạng không phổ biến.
4.5. Yêu cầu về nền tảng phần cứng và phần mềm
4.5.1. Hệ thống phải được thiết kế trên nền phần cứng hỗ trợ các tính năng phục vụ xử lý song song ở phần cứng. (Xử lý đa luồng (multi threading), đa vi xử lý trong một lõi (multi-core), đa nhiệm với sự hỗ trợ của phần cứng (hardware context switching)...).
4.5.2. Hệ thống phải được thiết kế dựa trên nền tảng hệ điều hành có độ ổn định cao và đã được chứng minh hoạt động hiệu quả với hệ thống thư điện tử với cường độ khai thác lớn.
4.5.3. Phần cứng và phần mềm dùng cho hệ thống cần có lộ trình cung cấp, hỗ trợ và nâng cấp ổn định, tránh dùng các dòng sản phẩm đang chuẩn bị dừng phát triển. Ví dụ: Dòng máy Alpha của HP.
4.6. Yêu cầu về các tính năng của MTA
4.6.1. Kiểm soát relay bằng địa chỉ hoặc dải địa chỉ IP.
4.6.2. Kiểm soát relay bằng địa chỉ gửi/nhận: chỉ nhận qua SMTP những địa chỉ hợp lệ. Có thể cấu hình để chỉ relay cho các thư điện tử gửi đi bởi những hộp thư có tồn tại trên hệ thống.
4.6.3. Kiểm soát relay qua các black-list. Quản trị viên có thể can thiệp vào black-list khi cần thiết. Có khả năng cập nhật black-list tự động trong đó có thể tự động nhận DNS Real-time black hole list.
4.6.4. Có khả năng kiểm soát địa chỉ người gửi hợp lệ. Có khả năng kiểm tra các địa chỉ thư điện tử người gửi hợp lệ (phải có hoặc MX hoặc A trên bản ghi DNS). Có khả năng kiểm soát địa chỉ người gửi thư ra ngoài hệ thống phải là địa chỉ có thật trên hệ thống.
4.6.5. Có khả năng từ chối relay với các địa chỉ không có reverse DNS record. 4.6.6. Các thiết lập chống Relay cần dùng chung, chia sẻ cho tất cả các MTA
4.6.7. Cần có tính năng kiểm soát relay trước khi tiếp nhận qua SMTP để tránh việc lưu trữ và xử lý thư trên MTA.
4.6.8. Có khả năng xác thực đối với người sử dụng ngoài mạng (SMTP authentication). Có khả năng kiểm soát relay dựa trên thông tin xác thực. 4.6.9. Cần có tính năng “POP/IMAP before SMTP”.
4.6.10. Hệ thống phải kiểm tra quota của hộp thư trước khi chấp nhận một thư điện tử tới hộp thư đó vào hệ thống. Nếu hộp thư đã hết quota, phải có cơ chế thông báo cho cả người nhận và người gửi.
về địa chỉ IP và ngưỡng lưu lượng có thể được quyết định bởi người quản trị. Nêu các khả năng hạn chế thông lượng khác.
4.6.12. Thời gian tối đa thư được lưu trữ trong queue có thể được hiệu chỉnh bởi người quản trị.
4.6.13. Các khoảng thời gian xử lý các thư còn trong queue cũng có thể được hiệu chỉnh bởi người quản trị. Việc xử lý từng queue đơn lẻ cũng có thể do người quản trị thực hiện thủ công (manual.)
4.6.14. Có khả năng gỡ bỏ một hoặc nhiều thư riêng lẻ ra khỏi queue.
4.6.15. MTA cần được hỗ trợ bằng chương trình đa nhiệm multi-threaded, multi- processes để tăng cường khả năng xử lý song song của các máy phục vụ đa vi xử lý.
4.6.16. Cần hỗ trợ khả năng thông báo lỗi theo chuẩn tương thích Delivery Status Notification.
4.6.17. MTA cần được thiết kế để điều khiển được các hàng đợi lớn. Cần có năng lực phân tích và quản lý các hàng đợi lớn trong trường hợp không kết nối được đến các messge store nội bộ hoặc không kết nối được các mail server của các ISP khác hoặc gặp phải Spam. Cần có các tính năng thiết kế queue để chống mất thư và khả năng chịu đựng với Spam, Dos và Virus.
4.7. Yêu cầu về các tính năng của POP3
4.7.1. Tiêu chuẩn POP3 cần được hỗ trợ bằng chương trình đa nhiệm multi- threaded, multi-processes để tăng cường khả năng xử lý song song của các máy phục vụ đa vi xử lý.
4.7.2. Hệ thống cần thiết kế để khách hàng chỉ cần truy nhập đến địa chỉ cố định và thống nhất trên hệ thống, không phụ thuộc vào vị trí lưu trữ của hộp thư.
4.8. Yêu cầu về các tính năng hỗ trợ IMAP4
4.8.1. Tiêu chuẩn IMAP 4 cần được hỗ trợ bằng chương trình multi-threaded, multi- processes để tăng cường khả năng xử lý song song các máy phục vụ đa vi xử lý.
4.8.2. Hệ thống cần thiết kế để khách hàng chỉ cần truy nhập đến địa chỉ cố định và thống nhất trên hệ thống, không phụ thuộc vào vị trí lưu trữ của hộp thư. 4.8.3. Hệ thống cần hỗ trợ access control list qua IMAP hoặc các kỹ thuật tương
đương.
4.8.4. Hệ thống cần hỗ trợ shared IMAP folder. 4.8.5. Hệ thống cần hỗ trợ IMAP Quota Extension
4.9. Yêu cầu về các tính năng hỗ trợ Webmail
4.9.1. Phải có khả năng hiệu chỉnh giao diện cho phù hợp với nhu cầu của nhà cung cấp dịch vụ, có API cho phép tích hợp với các hệ thống quảng cáo.
4.9.2. Hệ thống cần thiết kế để khách hàng chỉ cần khai báo địa chỉ truy nhập cố định và thống nhất trên hệ thống, không phụ thuộc vào vị trí lưu trữ của hộp thư.
4.9.3. Hệ thống webmail phải hỗ trợ các tính năng cơ bản như người dùng sử dụng POP và SMTP với các client đơn giản khác: viết thư, gửi, nhận thư, đọc, trả lời, chuyển thư (forward) và xóa thư qua giao diện web.
4.9.4. Hệ thống phải hỗ trợ thư đính kèm(attachement) tương thích với các đầu cuối thư điện tử của Microsoft và Netscape/Mozzila và các trình duyệt khác. Hệ thống cần hỗ trợ thư đính kèm bao gồm lưu nội dung đính kèm của thư nhận được, tải nội dung đính kèm lên thư đang soạn thảo qua HTTP, hỗ trợ nhiều tập tin đính kèm.
4.9.5. Hệ thống webmail cần hỗ trợ tính năng tìm thư theo các tiêu chí về người gửi, chủ đề và nội dung.
4.9.6. Hệ thống webmail cần hỗ trợ tính năng thư mục (folder).
4.9.7. Hệ thống webmail cần hỗ trợ sổ địa chỉ (address book) cho khách hàng. Có sổ địa chỉ nhóm và sổ địa chỉ cá nhân. Những tính năng cần thiết với address book:
Quản lý Address book (tạo, sửa, xoá)
Truy cập và tìm kiếm
Address dựa trên cơ sở dữ liệu khách hàng
Nhập và xuất từ Outlook và Netscape address book
4.9.8. Hệ thống có thể được cho phép cho phép khách hàng điều chỉnh các tham số cho các tính năng bổ xung khác như đổi mật khẩu, mail forwarding, mail alert, vacation thư điện tử. (chi tiết về các tính năng này ở phần sau).
4.9.9. Hệ thống cần được thiết kế mở để hỗ trợ các hệ thống single sign-on(có API nếu cần).
4.9.10. Giao diện WebMail cần hỗ trợ các multimedia thư điện tử như voice, fax mail