Smtp Gateway

SMTP Gateway: Các Thông Tin Cần Biết Khi Thiết Lập & Cấu Hình

Các khái niệm cơ bản liên quan đến email online và email offline services: Trên Internet các emails được gởi qua lại cho nhau thông qua các Message Transfer Agent (MTA) sử dụng ghi thức SMTP, khi một công ty có domain là abc.com muốn gởi một email đến domain dfe.com chẳng hạn thì việc làm đầu tiên là MTA của abc.com phải query DNS để biết được giá trị MX record của dfe.com tương ứng với giá trị Internet IP nào, để từ đó mới có thể tạo một connection trực tiếp từ abc.com SMTP đến dfe.com SMTP để gởi email. Đối với các kết nối Internet dùng leased line thường trực, thông thường các công ty được các ISP cấp phát các subnet /29 hoặc /28 tương ứng với 6 hoặc 14 IP khả dụng thì chỉ cần khai báo các MX records đối với các IP mình thích để làm SMTP gateway, khi đó từ bên ngoài các Internet email sẽ hội tụ về các SMTP servers của bạn. Đối với các kết nối Internet được cấp phát IP động thì giải pháp hiệu quả nhất là đăng ký email offline, khi đó Internet IP có MX record tương ứng với domain của công ty mình sẽ nằm ở ISP mà mình đăng ký, sau đó các email gởi đến domain của mình sẽ hội tụ về SMTP của mail offline server đặt tại ISP, công ty của bạn khi đó phải cần dùng thêm một công cụ để kéo các email từ mail offline đó về để phân phát cho mọi người, và khi muốn gởi email từ công ty bạn đi ra Internet thì cần phải nhắm đến địa chỉ IP của mail offline server đó mà "bắn", sau đó các email của bạn sẽ được mail offline server phân giải và chuyển tiếp "bình yên" đến các đích khác dựa vào domain tương ứng của các recipients. Các cách khai báo và thai thác MX records: Giả sử domain def.com có khai báo MX records trên DNS như sau: def.com. 86400 IN MX 5 mx1.def.com. def.com. 86400 IN MX 10 mx2.def.com. Và các A record trên DNS tương ứng: mx1.def.com. 86400 IN A 203.162.3.3 mx2.def.com. 86400 IN A 203.162.3.4 Khi đó emails từ domain abc.com chẳng hạn sẽ ưu tiên kết nối tới mx1.def.com (203.162.3.3) server trước để gởi messages. Trường hợp mx1.def.com bị chết thì các emails từ bên ngoài sẽ hội tụ về mx2.def.com (203.162.3.4), nếu mx1 online trở lại thì tùy theo cơ chế polling giữa các giá trị MX và thời gian cache giá trị Time To Live (TTL) là bao nhiêu (trong trường hợp này là 01 day = 86400 s) để Internet emails sẽ tiếp tục chuyển tới MX2 hay trở về lại MX1. Các giá trị ưu tiên là 5 hay 10 hoặc 1 hay 2 không quan trọng, cái quan trọng là giá trị nào bé hơn sẽ được ưu tiên nhận email trước, và nếu có nhu cầu thì bạn có thể khai báo đến 100 cái MX cũng được. Thế khi ta khai báo mx1=mx2=...=mxn=A (A số nguyên dương) thì sao? Khi đó ta có hình thức load balacing cho các mx records. Hiện nay ta thấy hầu hết các công ty ở VN chỉ thấy đăng ký có mỗi một MX record (?) mà không hề có một MX record thứ hai để dự phòng dù MX backup đó chỉ cần được yêu cầu khai báo sẵn trên DNS Chống open relay cho SMTP gateway servers: Thông thường các email admin chưa có kinh nghiệm thường bỏ qua vấn đề này khi thiết lập SMTP gateways, và khi phát hiện ra các SMTP của mình bị khai thác để spamming các domain khác thì có thể lúc đó đã quá muộn, SMTP gateway IP addresses của tổ chức bạn đã bị liệt vào danh sách đen, các tổ chức chẳng hạn như abuse.net chuyên làm nhiệm vụ cập nhật các “danh sách đen” cho các

công ty sử dụng dịch vụ Realtime Blackhole List (RBL), có nghĩa là các emails từ công ty của bạn sẽ bị reject khi cố gắng kết nốI SMTP để gởi emails đến các công ty sử dụng RBL. Thực ra việc chống open relay không có gì là khó khăn hết nếu bạn hiểu rõ được nguyên tắc hoạt động của Internet email, chỉ vớI một nguyên tắc cơ bản là “chỉ nhận những cái của mình và chỉ chuyển tiếp đi những cái từ tay những ngườI mà mình biết” sẽ giúp cho bạn chống được open relay cho SMTP gateway của công ty. Ví dụ: Công ty của bạn có domain là abc.com, sử dụng một SMTP gateway có địa chỉ IP 203.162.3.3 để chuyển tiếp email qua lại giữa Internet và một local email server dùng Domino Lotus Notes có địa chỉ IP 192.168.1.3 Khi đó bạn sẽ cấu hình trên SMTP gateway sao cho: Chiều nhận (Incoming): Chỉ nhận các email gởi đến domain @abc.com Chiều đi (Outgoing): Chỉ cho phép IP: 192.168.1.3 chuyển emails có sender domain là @abc.com đi ra ngoài Đối với các mobile users muốn gởI email ra ngoài khi đi công tác, các bạn nên cho các mobile users đó dùng web mail hay dùng authentication SMTP khi họ muốn dùng các tiện ích như MS Outlook Express, Eudora email client... Đối với trưởng hợp do chưa có đủ điều kiện để dùng các SMTP gateways riêng chỉ để làm nhiệm vụ chuyển tiếp email (SMTP gateway servers: chỉ làm nhiệm vụ chuyển tiếp, sàng lọc emails mà không chứa các email accounts cho users) thì cũng cấu hình tương tự như trên. Trước khi để cho hệ thống đi vào hoạt động thật sự bạn nên dùng tiện ích dướI đây để kiểm tra SMTP gateway của mình đã cấu hình đúng hay chưa: http://www.abuse.net/relay.html Chú ý về việc deliver emails: Hiện nay do hiện tượng ngày càng nhiều spam và các thứ linh tinh khác nên các MTA hầu như đều cấu hình kiểm tra ngược lại IP đang kết nối với mình xem nó có được bind với một MX record nào không, nếu không thì phía MTA nhận sẽ reject kết nối đó vì cho rằng kẻ kết nối với mình không có domain email thực, đây cũng chính là biện pháp mà Bill Gate đang hô hào bà con ứng dụng SMTP authentication mà chẳng qua đó chính là cái Sender Policy Framework SPF (thực chất SPF đã có từ lâu rồi mà chỉ vì bà con không chịu tuân thủ nghiêm ngặt mà thôi, chuyện về anti-spam còn dài lắm vì SMTP authentication chỉ chống được các fake domains gởi spam vào thôi còn các real domains gởi spam vào thì phải dùng đến cách khác...). Do vậy các admin chú ý nhớ dùng cái IP nào mà có bind với cái MX record để deliver emails (outgoing) cho nó chắc chắn kẻo emails bị “đá” ngược về là phải chuẩn bị tinh thần để "giải trình" với xếp đấy Xây dựng bộ lọc chống SPAM: Đối với các công ty làm việc và giao dịch thiên về email thì việc chống virus và spam sẽ làm tăng hiệu suất công việc rất đáng kể, thực ra spam được chống ở rất nhiều lớp Lớp giao tiếp phía ngoài: Bao gồm việc kiểm tra kết nối SMTP dùng SPF như đã nói ở trên qua cơ chế revert DNS lookup hay dùng các Realtime Blackhole List (RBL) để reject các spam server ngay

từ thời điểm tạo kết nối SMTP… Lớp bên trong (có thể dùng cho mail offline): Như đã nói ở phần trên là ta không thể chống spam chỉ bằng cơ chế SPF vì spam còn do các real domain email gởi vào, Khi đó SMTP gateway phải nhận hết nội dung email đó rồi mới phân tích các dấu hiệu nhận dạng spam, các kỹ thuật này phải phân tích các câu cú trong nội dung, các kiểu câu quảng cáo thông dụng... bằng các kỹ thuật như content scanner, DCC, Pyzor and Razor, và Bayes... Sau khi qua các kỹ thuật này message emails sẽ được xếp hạng bằng cách cho điểm, điểm càng cao thì có nghĩa là khả năng email đó là spam càng lớn, việc định vị được các ngưỡng để ra quyết định xem cái nào thực sự làm spam, probably spam, hay không phải spam sẽ do ngưởi admin quyết định để block, tag, hay deliver message , nếu ta chọn được giá trị nào thích hợp nhất thì khả năng bị mất email cho user sẽ ở mức minimum (giá trị có thể chấp nhận được là 1/1000) khi điểm số spam ở mức lưng chừng (không cao quá và cũng không thấp quá) thì ta có thể đánh dấu (tag) vào message đó để cho user tiện xử lý ngay tại mail box của mình. Ví dụ: Điểm số có giá trị < 4 : Ligitimate emails (Deliver) Điểm số có giá trị 4 - 8 : Probably spam (Tag) Điểm số có giá trị > 8 : Spam (Block) Khi đó admin có thể tag vào trong subject của probably spam email một chuỗi nhận dạng [MayBeSpam] để cho user dễ dàng định hướng lại email này khi đi vào inbox (có thể tạo thêm một folder chẳng hạn như maybespam trên inbox để có kiểm tra lại các message này vào lúc rãnh rỗi) Với package Spamassassin (http://spamassassin.apache.org/) bạn có thể tự mình build được một bộ lọc spam hiệu quả bao gồm cả hai lớp như đã nói ở trên đấy. Phát triển cơ chế anti-spam cho lĩnh vực content filtering: Phát triển rộng hơn các bạn có thể dựa vào các tính năng của Spamassassin package để có thể lọc được các emails có nội dung chứa các câu, các từ không được lịch sự lắm (profanity) như “hardcore, asshole, blow job, bitch, cock…” quấy phá nhân viên trong công ty, việc thực hiện sẽ sử dụng kỹ thuật gọi là “weighting” có nghĩa là với một lần xuất hiện các từ hay các câu này trong phần body message thì có thể không sao, nhưng khi vượt qua ngưỡng nào đó mà bạn set (3 chẳng hạn) thì message đó sẽ được cách ly ra để “hạ hồi phân giải”