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 ..., để có thể cung cấp Unify Messaging trong tương lai.
4.9.11. Có thể thiết lập thông tin cá nhân: mật khẩu, ngôn ngữ, vcard, chữ ký. 4.9.12. Có khả năng tập hợp các thư điện tử từ POP3 server và lưu trữ tới một thư
mục lựa chọn.
4.9.13. Có cơ chế quản lý phiên làm việc và tự động thoát (logout)
4.9.14. Cần cho phép tuỳ chọn công cụ soạn thảo Rich text bao gồm HTML editor cho soạn thư.
4.10. Yêu cầu về các tính năng của MSS
4.10.1. Hệ thống cần cung cấp khả năng tự động xóa các thư tồn tại quá lâu trên hệ thống, đặc biệt là các thư trong trash folder với khả năng cấu hình được khoảng thời gian xoá thư (thư điện tử aging).
4.10.2. Hệ thống cần hỗ trợ tính năng single-instance cho thành phần lưu thư (thư gửi cho nhiều người chỉ cần lưu một bản sao trên hệ thống.)
4.10.3. Hệ thống cần hỗ trợ tính năng shared folder(nhiều người có thể truy nhập tới một thư mục chung).
4.10.4. Hệ thống cần hỗ trợ khả năng người quản trị xử lý các thư riêng lẻ trên MSS. (Thí dụ xóa các thư spam ngẫu nhiên lọt đầy hệ thống có thể bị xóa mà bởi người quản trị mà không ảnh hưởng tới các thư khác).
4.10.5. Hệ thống cho phép định nghĩa Quota cho từng nhóm, quản trị nhóm có thể định nghĩa Quota cho từng thành viên của nhóm. Hỗ trợ cấu hình quota,
4.10.6. Điều khiển Quota dựa trên kích thước mailbox. 4.10.7. Dựa trên số lượng thư .
4.10.8. Dựa trên kích thước thư.
4.10.9. Hỗ trợ quota cứng và quota mềm.
4.10.10. Hỗ trợ backup online mà không dừng dịch vụ.
4.11. Yêu cầu về các tính năng chống virus và spam
4.11.1. Hệ thống phải được thiết kế để có khả năng chống và lọc spam, khả năng chống virus, có thể hoạt động với nhiều sản phẩm khác nhau.
4.11.2. Hệ thống phải có khả năng lựa chọn các hành động đối với các thư điện tử nhiễm virus: tự động diệt virus, xóa nội dung có chứa virus, cách ly (quarrantine) các nội dung có chứa virus.
4.11.3. Hệ thống phải có khả năng thông báo cho người gửi và/hoặc người nhận về thông tin thư điện tử có nhiễm virus.
4.11.4. Hệ thống cần có biện pháp tuỳ chọn cho người dùng đăng ký (subscribe) vào hệ thống diệt virus. Khả năng kiểm tra tất cả các thư vẫn phải được duy trì. 4.11.5. Hệ thống phải có biện pháp cho phép cập nhật các mẫu virus theo định kỳ (có
thể cấu hình được) hoặc bất thường (do người quản trị).
4.11.6. Hệ thống phải có khả năng phát hiện các thư spam theo các tiêu chí có thể được cấu hình bởi người quản trị.
4.11.7. Hệ thống cần cung cấp khả năng cho người dùng tự định nghĩa nội dung spam (“mark as spam’’). Người quản trị có thể xem xét trước khi chính thức đưa vào sử dụng cho hệ thống.
4.11.8. Hệ thống cần có khả năng tùy chọn đưa các thư nghi ngờ vào thư mục spam của IMAP hoặc Webmail.
4.11.9. Hệ thống cần có biện pháp cho mỗi người dùng đăng ký (subscrbe) vào hệ thống lọc spam. Khả năng lọc đối với tất cả các thư vẫn phải được duy trì. Hệ thống cho phép End-User tự xây dựng chính sách spam cho mình sẽ được đánh giá cao.
4.11.10. Cần sử dụng ngôn ngữ tiêu chuẩn SIEVE cho việc lọc thư.
4.11.11. Hệ thống phải có biện pháp cho phép cập nhật các mẫu spam theo định kỳ (có thể cấu hình được) hoặc bất thường (do người quản trị).
4.11.12. Hệ thống cần có cơ chế quản trị antispam, antivirus, báo cáo thống kê antispam, antivirus theo phương thức tập trung, và giao diện đồ hoạ, giao diện dòng lệnh nếu cần.
4.11.13. Có giao diện cho phép khách hàng cấu hình cung cấp khả năng mailbox filtering của mình.
4.11.14. Giải pháp chống spam kết hợp được với cơ sở dữ liệu hộp thư khách hàng để chống spam đạt hiệu quả cao.
4.12. Yêu cầu về cơ sở dữ liệu hộp thƣ của hệ thống
4.12.1. Hệ thống cần đảm bảo đồng bộ dữ liệu khách hàng đối với các site. Đồng bộ theo thời gian thực là một tính năng cao cấp cần có.
4.12.2. CSDL khách hàng phải hỗ trợ việc đồng bộ linh hoạt toàn bộ/một nhánh CSDL, sử dụng phương thức đồng bộ lũy tiến, Hỗ trợ đồng bộ theo các phân đoạn, khả năng đồng bộ chỉ các thuộc tính cần đồng bộ, trong trường hợp đồng bộ theo phân đoạn, tất cả các entries sẽ được đồng bộ, song một số thuộc tính của các entry có thể được lọc ra ngoài.
4.12.3. Hỗ trợ đồng bộ Multimaster/slave. Master database được cấu hình ở chế độ High Availability.
4.12.4. Hệ thống cần có khả năng tối ưu hoá giao dịch với cơ sở dữ liệu khách hàng khi số lượng các giao dịch tăng.
4.12.5. Hệ thống cần có khả năng giám sát CSDL khách hàng & hộp thư, khả năng backup, restore, reindex.
4.12.6. Hỗ trợ LDAP V3
4.12.7. Hỗ trợ Access Control List hạn chế truy cập đến CSDL khách hàng để tăng cường an ninh hệ thống.
4.12.8. Hỗ trợ sử dụng các hàm băm như SHA, MD5 để bảo mật mật khẩu. 4.12.9. Hỗ trợ mã hóa các thuộc tính.
4.13. Yêu cầu về hệ thống quản trị
4.13.1. Nhân viên quản trị có thể truy nhập và quản trị từ xa bằng SSH và thực hiện hầu hết các thao tác quản trị qua command-line.
4.13.2. Có giao diện quản trị đồ họa (GUI). Có khả năng quản trị tập trung đối với