exec /usr/local/bin/softlimit -m 2000000 \ /usr/local/bin/tcpserver -v -H -P -R -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \ -u "$QMAILDUID" -g "$NOFILESGID" 0 smtp /usr/local/bin/rblsmtpd -r relays.ordb.org -r relays.osirusoft.com /var/qmail/bin/qmail-smtpd >> /var/log/qmail/rblsmtpd.log 2>&1 

exec /usr/local/bin/softlimit -m 32000000 \ /usr/local/bin/tcpserver -v -H -R -l 0 -P -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \ -u "$QMAILDUID" -g "$NOFILESGID" 0 25 /usr/local/bin/rblsmtpd -b -r sbl-xbl.spamhaus.org -b -r dnsbl.njabl.org /var/qmail/bin/qmail-smtpd >> /var/log/qmail/rblsmtpd.log 2>&1 

tcpserver: pid 27269 from 24.195.254.113 tcpserver: ok 27269 0:xxx.xxx.xxx.xxx:25 :24.195.254.113::1921 rblsmtpd: 24.195.254.113 pid 27269: 553 http://www.spamhaus.org/query/bl?ip=24.195.254.113 tcpserver: end 27269 status 0 

em không bao giờ dùng blacklist, em ghét blacklist, em dọt đây trước khi các bác phang cho gãy giò :-d 

FEATURE(`dnsbl',`sbl-xbl.spamhaus.org',`Rejected - see http://www.spamhaus.org/')dnl

FEATURE(`dnsbl',`dnsbl.njabl.org',`Rejected - see http://www.njabl.org/')dnl

reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client dnsbl.njabl.org

Tớ chúa ghét spam và từ khi bắt đầu dùng qmail làm MTA hồi năm 2000 cho đến nay, tớ đã khoái ứng dụng rblsmtpd (real time backlist smtp daemon) có trong qmail. Ngày trước đoạn script run tớ thường dùng cho qmail-smtpd là:

exec /usr/local/bin/softlimit -m 2000000 \ /usr/local/bin/tcpserver -v -H -P -R -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \ -u "$QMAILDUID" -g "$NOFILESGID" 0 smtp /usr/local/bin/rblsmtpd -r relays.ordb.org -r relays.osirusoft.com /var/qmail/bin/qmail-smtpd >> /var/log/qmail/rblsmtpd.log 2>&1 

trong đó, relays.ordb.org và relays.osirusoft.com là hai RBL servers. Chúng được rblsmtpd hỏi thăm mỗi khi có mail đi vào xem mail này có phải thuộc diện spam hay không trước khi tiếp nhận. Thời gian gần đây, tớ thấy spams đi vào system càng lúc càng nhiều, bèn điều tra. Hóa ra hai cái servers trên chết tiệt hồi nào rồi nên chẳng còn real time blacklist gì ráo :P) . Tớ bèn google 1 phát và ra cái này: http://www.email-policy.com/Spam-black-lists.htm Sau khi duyệt xuyên qua cái danh sách và hí hoáy thử nghiệm, tớ thấy có 2 "anh chàng" ngon nhất và nhanh nhất đó là: sbl-xbl.spamhaus.org và dnsbl.njabl.org. Thế là đoạn script run tớ dùng cho qmail-smtpd trở thành:

exec /usr/local/bin/softlimit -m 32000000 \ /usr/local/bin/tcpserver -v -H -R -l 0 -P -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \ -u "$QMAILDUID" -g "$NOFILESGID" 0 25 /usr/local/bin/rblsmtpd -b -r sbl-xbl.spamhaus.org -b -r dnsbl.njabl.org /var/qmail/bin/qmail-smtpd >> /var/log/qmail/rblsmtpd.log 2>&1 

Điểm khác biệt tất nhiên là 2 cái server mới ở trên. Tuy nhiên, điểm quan trọng là tớ dùng -b thêm vào. -b cho rblsmtpd có nghĩa là "Use a 553 error code for IP addresses listed in the RBL" (theo nguyên bản chú thích của Dan Bernstein). Bởi thế, một đoạn log mới của qmail's rblsmtpd.log cho thấy:

tcpserver: pid 27269 from 24.195.254.113 tcpserver: ok 27269 0:xxx.xxx.xxx.xxx:25 :24.195.254.113::1921 rblsmtpd: 24.195.254.113 pid 27269: 553 http://www.spamhaus.org/query/bl?ip=24.195.254.113 tcpserver: end 27269 status 0 

Đại khái tcpserver daemon báo rằng, - process id 27268 nhận mail từ 24.195.254.113. - sau đó, nó tiếp nhận (ok) ở dòng tiếp theo. xxx.xxx.xxx.xxx:25 là cổng smtp và IP của server của tớ, 24.195.254.113 và cổng 1921 là IP và cổng của máy (hoặc open relay server đó) gởi mail đến server tớ. - dòng kế tiếp, rblsmtpd nhảy vào và query spamhaus.org xem IP 24.195.254.113 có bị blacklist hay không và cho biết kết quả 553 (SMTP Relay denied). - dòng cuối cùng, tcpserver báo rằng process đó kết thúc, không có chuyện gì xảy ra. Điều này có nghĩa rằng, spam mail từ 24.195.254.113 không hề vào được hệ thống của tớ :P) Ai dùng qmail nên thử xem thế nào? Ở đây tớ không bàn đến các phương pháp chống spam khác (như spamassasin... dùng fuzzy check, Bayesian filter... ) vì RBL là 1 dạng trong nhiều dạng chống. Tớ nói thêm, những ai chưa dùng qmail thì bài viết này không có giá trị gì cả. Thân mến. 

exec /usr/local/bin/softlimit -m 32000000 \ /usr/local/bin/tcpserver -v -H -R -l 0 -P -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \ -u "$QMAILDUID" -g "$NOFILESGID" 0 25 /usr/local/bin/rblsmtpd -b -r sbl-xbl.spamhaus.org -b -r dnsbl.njabl.org /var/qmail/bin/qmail-smtpd >> /var/log/qmail/rblsmtpd.log 2>&1 

exec /usr/local/bin/softlimit -m 40000000 \ /usr/local/bin/tcpserver -v -H -R -l 0 -P -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \ -u "$QMAILDUID" -g "$NOFILESGID" 0 25 \ /usr/local/bin/spamdyke -f /etc/spamdyke.conf \ /var/qmail/bin/qmail-smtpd /bin/true 2>&1 

log-level=verbose
local-domains-file=/var/qmail/control/rcpthosts
max-recipients=5
idle-timeout-secs=300
graylist-dir=/var/qmail/graylist
graylist-level=always
graylist-min-secs=300
graylist-max-secs=1814400
sender-blacklist-file=/var/qmail/blacklist/bl-send
recipient-blacklist-file=/var/qmail/blacklist/bl-recv
ip-in-rdns-keyword-blacklist-file=/var/qmail/blacklist/bl-keywords
ip-blacklist-file=/var/qmail/blacklist/bl-ip
rdns-blacklist-dir=/var/qmail/blacklist/blacklist_rdns.d
reject-empty-rdns
reject-unresolvable-rdns
reject-ip-in-cc-rdns
rdns-whitelist-file=/var/qmail/whitelist/wl-rdns
ip-whitelist-file=/var/qmail/whitelist/wl-ip
greeting-delay-secs=5
dns-blacklist-entry=dnsbl.sorbs.net
dns-blacklist-entry=bl.spamcop.net
dns-blacklist-entry=zen.spamhaus.org
reject-missing-sender-mx
sender-whitelist-file=/var/qmail/whitelist/wl-send
config-dir=/etc/spamdyke.d

Aug 4 23:08:08 localhost spamdyke[28734]: DENIED_RDNS_MISSING from: inflammationp7241@kallmannkonzept.com to: copperiad@tienve.org origin_ip: 123.248.17.77 origin_rdns: (unknown) auth: (unknown) Aug 4 23:08:08 localhost spamdyke[28734]: DENIED_RDNS_MISSING from: inflammationp7241@kallmannkonzept.com to: czupryn@tienve.org origin_ip: 123.248.17.77 origin_rdns: (unknown) auth: (unknown) Aug 4 23:08:21 localhost spamdyke[28767]: FILTER_RDNS_RESOLVE ip: 190.55.99.38 rdns: cpe-38.99.55.190.in-addr.arpa Aug 4 23:08:21 localhost spamdyke[28767]: DENIED_RDNS_RESOLVE from: factxp8@laubergedelavallee.com to: isaganimerz@tienve.org origin_ip: 190.55.99.38 origin_rdns: cpe-38.99.55.190.in-addr.arpa auth: (unknown) Aug 4 23:08:21 localhost spamdyke[28767]: DENIED_RDNS_RESOLVE from: factxp8@laubergedelavallee.com to: it@tienve.org origin_ip: 190.55.99.38 origin_rdns: cpe-38.99.55.190.in-addr.arpa auth: (unknown) Aug 4 23:08:21 localhost spamdyke[28767]: DENIED_RDNS_RESOLVE from: factxp8@laubergedelavallee.com to: itp@tienve.org origin_ip: 190.55.99.38 origin_rdns: cpe-38.99.55.190.in-addr.arpa auth: (unknown) Aug 4 23:11:26 localhost spamdyke[28521]: ERROR: unable to write 37 bytes to file descriptor 1: Connection reset by peer Aug 4 23:11:26 localhost spamdyke[28521]: TIMEOUT from: xxx@tienve.org to: xxx@tienve.org origin_ip: 123.236.6.243 origin_rdns: (unknown) auth: (unknown) reason: TIMEOUT Aug 4 23:11:46 localhost spamdyke[29134]: ALLOWED from: admin@tienve.org to: karma_dt_91@yahoo.com origin_ip: 127.0.0.1 origin_rdns: localhost auth: (unknown) Aug 4 23:12:23 localhost spamdyke[29182]: FILTER_WHITElist_NAME ip: 124.146.189.165 rdns: st0085.nas951.n-yokohama.nttpc.ne.jp file: /var/qmail/whitelist/wl-rdns(1) Aug 4 23:12:23 localhost spamdyke[29182]: ALLOWED from: (unknown) to: hoangngocdieu@tienve.org origin_ip: 124.146.189.165 origin_rdns: st0085.nas951.n-yokohama.nttpc.ne.jp auth: (unknown) Aug 4 23:13:16 localhost spamdyke[29321]: FILTER_RDNS_MISSING ip: 123.19.104.2 Aug 4 23:13:16 localhost spamdyke[29321]: DENIED_RDNS_MISSING from: crotchets96@corlok.com to: xxx@tienve.org origin_ip: 123.19.104.2 origin_rdns: (unknown) auth: (unknown) Aug 4 23:15:28 localhost spamdyke[29606]: FILTER_RDNS_MISSING ip: 89.165.8.249 Aug 4 23:15:28 localhost spamdyke[29606]: DENIED_RDNS_MISSING from: conclusions9380@livingfaithcapecoral.com to: info@tienve.org origin_ip: 89.165.8.249 origin_rdns: (unknown) auth: (unknown) 

Như cách trên, postfix sẽ cho phép client gửi mail khi thuộc mynetworks, và cái thứ 2 chính là đã sasl_authenticated. Khi đã xác thực, thì tôi chắc chắn rằng đó là user hợp lệ của chúng tôi, và bỏ qua các bước reject phía dưới, kể cả check RBL.  

Hi bác conmale. Thì đúng là nếu sử dụng webmail hoặc là qmail tách biệt incomming/outgoing thì chả nói làm gì. Nhưng mô hình cho doanh nghiệp cỡ nhỏ (và có thể là vừa) ở VN, với quy mô 10K users, 5GB mail/ngày, thì 1 smtp dùng cho cả 2 mục đích sẽ hợp lý và tiết kiệm hơn (1 con server, chắc chắn thế). Cái tôi muốn nói ở đây, là hiểu qmail, biết được 1 số ưu, nhược của nó, để mà triển khai phù hợp nhu cầu. Tôi thực đã gặp khó khăn với qmail + RBL, khi mà chỉ có 1 smtp server cho cả in/out, rất nhiều user của tôi xài Internet ADSL, hay bị coi là trong RBL và khỏi gửi mail. Thế là lại phải bỏ cái RBL. Nhưng nếu tôi có income/out riêng, thì incoming (là server gán bản ghi MX) có thể tôi sẽ xài qmail, vì qmail + simscan chạy rất lẹ, ăn ít tài nguyên, ít hơn mô hình tôi đang dùng là postfix + amavis. Còn việc dùng telnet, đó chẳng qua là cách test thôi mà bác. Cái mail client như Outlook hay là Thunderbird nó cũng chạy y hệt vậy. 

myquartz wrote:

Hi bác conmale. Thì đúng là nếu sử dụng webmail hoặc là qmail tách biệt incomming/outgoing thì chả nói làm gì. Nhưng mô hình cho doanh nghiệp cỡ nhỏ (và có thể là vừa) ở VN, với quy mô 10K users, 5GB mail/ngày, thì 1 smtp dùng cho cả 2 mục đích sẽ hợp lý và tiết kiệm hơn (1 con server, chắc chắn thế). Cái tôi muốn nói ở đây, là hiểu qmail, biết được 1 số ưu, nhược của nó, để mà triển khai phù hợp nhu cầu. Tôi thực đã gặp khó khăn với qmail + RBL, khi mà chỉ có 1 smtp server cho cả in/out, rất nhiều user của tôi xài Internet ADSL, hay bị coi là trong RBL và khỏi gửi mail. Thế là lại phải bỏ cái RBL. Nhưng nếu tôi có income/out riêng, thì incoming (là server gán bản ghi MX) có thể tôi sẽ xài qmail, vì qmail + simscan chạy rất lẹ, ăn ít tài nguyên, ít hơn mô hình tôi đang dùng là postfix + amavis. Còn việc dùng telnet, đó chẳng qua là cách test thôi mà bác. Cái mail client như Outlook hay là Thunderbird nó cũng chạy y hệt vậy. 

Hình như bồ không hiểu ý tôi. qmail nào cũng có qmail-smtp và qmail-send cả. Đây là cái mà bồ gọi là "incoming" và "outgoing" đó. Còn nếu bồ nói đến chuyện dựng 2 con servers, cài 2 con qmail, 1 con cho đường vào, 1 con cho đường ra thì thú thật... tôi chưa hề thấy mô hình đó bao giờ. qmail luôn luôn handle in và out từ khi nó... chào đời. Riêng phần màu cam ở trên thì hình như bồ vẫn chưa hiểu ý tôi nói về vai trò và vị trí của một mail client và một MTA. Bồ dùng telnet là bồ telnet thẳng từ máy của bồ đến target SMTP server (mail server của tôi). Bồ dùng Outlook hay Thunderbird là bồ phải đăng ký địa chỉ smtp server trên phần settings của chúng. SMTP server này chính là SMTP server của bồ chớ chẳng phải của tôi. Khi Outlook hay Thunderbird gởi mail đi, mail đi từ máy của bồ đến SMTP server của bồ. Sau đó, SMTP server của bồ mới gởi mail đến SMTP server của tôi. Trên Outlook hoặc Thunderbird, bồ không cách gì khai báo SMTP server là SMTP server của tôi được cả vì tôi đâu có open để bồ relay mail như vậy? Đó là sự khác biệt giữa telnet và Outlook mà bồ đã nhầm lẫn. Nếu bị black list, chính cái SMTP server của bồ bị blacklist vì nó vi phạm quy định chung chớ chẳng phải máy của bồ vi phạm. Nói tóm lại, tôi ngờ ngợ là bồ không phân biệt được thế nào là mail client, thế nào là MTA và quy trình gởi mail đúng tiêu chuẩn là gì. 

- Xét điểm 3 và 4: user của em là thuê bao ADSL, Dynamic IP, mà dải đó bị RBL. Họ gửi mail cho 1 ai đó. MUA sẽ kết nối đến mail server, sau chuỗi lệnh: EHLO xxx, AUTH LOGIN .... bị reject luôn vì RBL (giống như cái telnet em paste trước đó). Thế là họ khỏi gửi luôn => complaint. Đúng ra thì sau khi AUTH LOGIN, user của em được relay thoải mái.  

Qmail + RBL không phân biệt được MUA với MTA trong trường hợp này, dù cả MUA lẫn MTA đều dùng SMTP nhưng MUA có AUTH LOGIN trước mọi cái khác. Tại sao Qmail lại thế thì các post trước của em đã nói. Em dùng Postfix thì xử lý được vấn đề trên.  

- Xét điểm 3 và 4: user của em là thuê bao ADSL, Dynamic IP, mà dải đó bị RBL. Họ gửi mail cho 1 ai đó. MUA sẽ kết nối đến mail server, sau chuỗi lệnh: EHLO xxx, AUTH LOGIN .... bị reject luôn vì RBL (giống như cái telnet em paste trước đó). Thế là họ khỏi gửi luôn => complaint. Đúng ra thì sau khi AUTH LOGIN, user của em được relay thoải mái. Qmail + RBL không phân biệt được MUA với MTA trong trường hợp này, dù cả MUA lẫn MTA đều dùng SMTP nhưng MUA có AUTH LOGIN trước mọi cái khác. Tại sao Qmail lại thế thì các post trước của em đã nói. Em dùng Postfix thì xử lý được vấn đề trên.  

myquartz wrote:

- Xét điểm 3 và 4: user của em là thuê bao ADSL, Dynamic IP, mà dải đó bị RBL. Họ gửi mail cho 1 ai đó. MUA sẽ kết nối đến mail server, sau chuỗi lệnh: EHLO xxx, AUTH LOGIN .... bị reject luôn vì RBL (giống như cái telnet em paste trước đó). Thế là họ khỏi gửi luôn => complaint. Đúng ra thì sau khi AUTH LOGIN, user của em được relay thoải mái. Qmail + RBL không phân biệt được MUA với MTA trong trường hợp này, dù cả MUA lẫn MTA đều dùng SMTP nhưng MUA có AUTH LOGIN trước mọi cái khác. Tại sao Qmail lại thế thì các post trước của em đã nói. Em dùng Postfix thì xử lý được vấn đề trên.  

Theo mình hiểu thì ý bạn myquartz là ví dụ như bạn Alice có email là alice@abc.com tiến hành login vào server smtp.abc.com để gửi email từ alice@abc.com đi bob@def.com. Tuy nhiên, con server stmp.abc.com lại reject bạn Alice vì IP của bạn Alice nằm trong RBL. Trường hợp này thì rõ là con server đó sai, nhưng mình không nghĩ là qmail lại tệ đến vậy, mặc dù mình chưa bao giờ dùng qmail. bạn có chắc là bạn configure đúng không? Ngược lại, nếu ý của bạn myquartz là bạn Alice connect trực tiếp đến smtp.def.com, thì rõ ràng là sai nguyên tắc, như anh conmale đã đề cập. 

Nếu Alice đang dùng một máy có network không thuộc network "white list" mà access MTA này thì nó phải reject bởi vì đây là nguyên tắc không cho phép open relay. Cách duy nhất và tạm gọi là "reliable" là cách cho phép Alice "pop before smtp", đây là một cách buộc Alice phải authenticate xuyên qua pop3 (nhận mail) trước khi tạm thời open relay để Alice có thể gởi mail (xuyên qua smtp) vào qmail (rồi qmail mới gởi mail của Alice đến một MTA khác là đích).  

conmale wrote:

Nếu Alice đang dùng một máy có network không thuộc network "white list" mà access MTA này thì nó phải reject bởi vì đây là nguyên tắc không cho phép open relay. Cách duy nhất và tạm gọi là "reliable" là cách cho phép Alice "pop before smtp", đây là một cách buộc Alice phải authenticate xuyên qua pop3 (nhận mail) trước khi tạm thời open relay để Alice có thể gởi mail (xuyên qua smtp) vào qmail (rồi qmail mới gởi mail của Alice đến một MTA khác là đích).  

Nếu SMTP server đó có implement SMTP-AUTH thì cũng là một giải pháp vậy. Tuy nhiên không biết qmail có cái extension này không. Nếu không có thì đúng là phải authenticate qua pop3 rồi. Phải chăng đây là lý do bạn myquartz không thích dùng qmail. 

Qmail + RBL không phân biệt được MUA với MTA trong trường hợp này, dù cả MUA lẫn MTA đều dùng SMTP nhưng MUA có AUTH LOGIN trước mọi cái khác.  

@conmale: vừa đọc qua post đầu tiên của myquartz, em thấy vấn đề chính là ở việc xử lý SMTP-AUTH của qmail. Cụ thể như sau (dựa vào posts của myquartz): Alice có email là alice@abc.com login sử dụng SMTP-AUTH vào qmail server là smtp.abc.com để gửi email đi bob@def.com. Quá trình này về mặt nguyên tắc là đúng. Tuy nhiên, qmail server smtp.abc.com lại hoạt động như sau: đầu tiên nó check IP của Alice xem có nằm trong RBL hay không, rồi sau đó mới sử dụng SMTP-AUTH để authenticate Alice. Như vậy nếu IP của Alice (e.g., home ADSL connection) nằm trong RBL, thì qmail server sẽ reject Alice ngay lập tức mà không nghĩ đến việc Alice là client của mình (alice@abc.com), và có cả login credential hẳn hoi. Có lẽ đây là lý do bạn myquartz cho rằng:

myquartz wrote:

Qmail + RBL không phân biệt được MUA với MTA trong trường hợp này, dù cả MUA lẫn MTA đều dùng SMTP nhưng MUA có AUTH LOGIN trước mọi cái khác.  

Như đã đề cập ở trên, liệu qmail tệ đến vậy chăng, hay là có chút sơ sót trong khâu configuration?  

Trong trường hợp này đó là mối liên quan giữa "sending MTA" và "receiving MTA" (như mô hình bên dưới) chớ không phải giữa "sending MUA" và "receiving MTA" hoặc "sending MTA". sending MUA ---> MSA ---> sending MTA ---> receiving MTA ---> MDA ---> receiving MUA. 

conmale wrote:

Trong trường hợp này đó là mối liên quan giữa "sending MTA" và "receiving MTA" (như mô hình bên dưới) chớ không phải giữa "sending MUA" và "receiving MTA" hoặc "sending MTA". sending MUA ---> MSA ---> sending MTA ---> receiving MTA ---> MDA ---> receiving MUA. 

Good point. Về cơ bản thì SMTP-AUTH chỉ nên dùng trong trusted environment, hơn nữa, việc gửi credential cho smtp server cũng đi hơi lệch với design. Tuy nhiên, nếu MTA thỏa mãn các điểm sau thì có thể chấp nhận được: - MTA đó thuộc sự quản lý trực tiếp của chủ mail server mà client thường login vào để đọc mail, với cùng username+password. - Việc login của MUA từ untrusted network phải thỏa mãn mutual authentication, sử dụng TLS/SSL. Đây là biện pháp tạo nên cái gọi là trusted environment ở trên. Tất nhiên việc dùng Telnet là không thể chấp nhận được, trừ phi client thiết lập VPN đến trusted environment. - MTA phải có cơ chế cho phép một authenticated user chỉ được gửi email từ một số email nhất định. Ví dụ: user Alice chỉ được gửi email từ alice@abc.com.  

- MTA phải có cơ chế cho phép một authenticated user chỉ được gửi email từ một số email nhất định. Ví dụ: user Alice chỉ được gửi email từ alice@abc.com.  

- MTA đó thuộc sự quản lý trực tiếp của chủ mail server mà client thường login vào để đọc mail, với cùng username+password. - Việc login của MUA từ untrusted network phải thỏa mãn mutual authentication, sử dụng TLS/SSL. Đây là biện pháp tạo nên cái gọi là trusted environment ở trên. Tất nhiên việc dùng Telnet là không thể chấp nhận được, trừ phi client thiết lập VPN đến trusted environment.  

2 điểm này cần nói thêm là: - MTA và MUA của 1 tổ chức mới xác thực với nhau, hoặc là của ISP với khách hàng của ISP đó. Chứ còn của 2 công ty partner với nhau để xác thực user+password với nhau thì trao đổi "pass" hơi mệt đấy. - MUA với MTA chỉ cần sử dụng SMTP with START-TLS hoặc là SMTP over SSL là đảm bảo toàn vẹn, bí mật và MUA xác thực được MTA là ai qua SSL cert. Còn MTA xác thực MUA là ai thì bằng user+pass. Như thế đã được coi là trusted rồi, không cần thêm VPN làm gì cho rắc rối. Telnet chỉ là demo thôi, nếu muốn tớ ... telnet over stunnel là được chứ gì?  

StarGhost wrote:

conmale wrote:

Trong trường hợp này đó là mối liên quan giữa "sending MTA" và "receiving MTA" (như mô hình bên dưới) chớ không phải giữa "sending MUA" và "receiving MTA" hoặc "sending MTA". sending MUA ---> MSA ---> sending MTA ---> receiving MTA ---> MDA ---> receiving MUA. 

Good point. Về cơ bản thì SMTP-AUTH chỉ nên dùng trong trusted environment, hơn nữa, việc gửi credential cho smtp server cũng đi hơi lệch với design. Tuy nhiên, nếu MTA thỏa mãn các điểm sau thì có thể chấp nhận được: - MTA đó thuộc sự quản lý trực tiếp của chủ mail server mà client thường login vào để đọc mail, với cùng username+password. - Việc login của MUA từ untrusted network phải thỏa mãn mutual authentication, sử dụng TLS/SSL. Đây là biện pháp tạo nên cái gọi là trusted environment ở trên. Tất nhiên việc dùng Telnet là không thể chấp nhận được, trừ phi client thiết lập VPN đến trusted environment. - MTA phải có cơ chế cho phép một authenticated user chỉ được gửi email từ một số email nhất định. Ví dụ: user Alice chỉ được gửi email từ alice@abc.com.  

Hi! Theo em bác conmale kết luận hơi ... võ đoán về cái SMTP-AUTH dùng cho cái sending MTA với receiving MTA. Vì 2 MTA này thường là thuộc 2 tổ chức khác nhau, ví dụ MyCompany.vn với lại Yahoo.com. Em không thể bảo Yahoo.com là mày cho tao 1 cái user/password để tao set vào MTA của tao khi gửi mail cho mày, và ngược lại mày phải dùng pass tao cấp để gửi cho tao được. Chưa bao giờ em gặp mô hình kiểu đó cả. Chỉ có 1 kiểu giữa MTA này xác thực user/pass với MTA khác mà em từng được biết đó là "SmartHost", còn lại chỉ có sending MUA xác thực user/pass với sending MTA và cần đến SMTP-AUTH mà thôi. Chỉ có sử dụng TLS giữa các MTA với nhau thì có thể, đôi khi MTA gửi check thêm cái CA Cert của MTA nhận khi kết nối đến nó, mà mình biết chắc là hợp lệ. Nhưng cái này là optional. MUA thì luôn kiểm tra TLS CA Cert của MTA nó kết nối đến có hợp lệ hay không (trừ khi bạn bypass nó đi).  

Nói chung, xét cái mô hình em có làm theo RFC ko thì em ko dám chắc, nhưng giải pháp em đang dùng nó thực tế, cũng tuân theo các hỗ trợ RFC mở rộng của hầu hết các MUA và MTA hiện tại. Qmail có thể thiết kế theo kiểu cổ xưa nên nó hoạt động tốt khi nó là như thế, tức là chỉ In-Mail only (MTA -> MDA), hoặc là Relay MTA only, chứ nó không uyển chuyển hoặc không thiết kế cho nhiều các tình huống như là In-mail MTA kiêm relay MTA. Tất nhiên giải pháp để tách đôi nó ra hoặc phân biệt client để mà xử (SMTPS hay VPN thành 1 trusted network), là 1 ý kiến hay, nhưng là để khắc phục yếu điểm uyển chuyển của Qmail mà thôi. Dù sao, hi sinh vài lợi điểm về sự uyển chuyển để được cái tốc độ và tốn ít RAM thì cũng đáng, tùy thuộc vào factor của từng người thôi.  

Hi! Có lẽ bác conmale ở nước ngoài nên chắc là không giống như em ở VN, nơi mà các ISP hầu như không chính thức cung cấp SMTP để cho KH của họ relay. Anyway, em sẽ nói đến lý thuyết chung thôi bác ạ.  

Webmail, theo em, vẫn là cách "lỡ độ đường" không có máy tính của mình mà phải xài ké hoặc thuê, chứ có máy laptop đi kèm em không xài cái đó, chậm và thường là tính năng hạn chế (ví dụ không thể với mail có S/MIME hay soạn mail khi em đang ngồi trên ... máy bay chẳng hạn???).  

Với VPN thì tất nhiên, rất tốt, nhưng nó thường đáp ứng cho nhiều thứ khác kèm thêm với SMTP (ví dụ IM hay VoIP của công ty). Nhưng làm cái VPN này nhiều cái đau đầu lắm bác ạ, nhất là user thường stupid hơn là ta tưởng và các loại client hỗ trợ sẽ hạn chế (ví dụ gửi/nhận mail trên iPhone over VPN??). Bắt làm việc đó chỉ để ... SMTP thì em xin bỏ việc.  

@anh conmale : việc sử dụng pop before smtp có cái hại như thế nào vậy anh. Đối với những user yêu cầu sự tiện dụng cao thì giải pháp nào là có thể áp dụng được anh. Thân  

Hi anh! Nhưng đầu tiên ta phải authen pop3 để chứng tỏ client đó thuộc sự quản lý của server , rồi sau đó server mới cho gởi mail mà anh. Em nghĩ thằng server chỉ tin tưởng vào session những thằng nào thỏa "pop3 before smtp ", đại loại như server bảo " mày gởi chứng nhận là đệ của tao thì tao mới làm giùm mày " 

Hi anh! Cái luật đó nằm ở đâu vậy anh ? Và tại sao thằng server không kiểm tra theo kiểu phải " đối với những thằng ip được lưu tạm thì cứ phải pop3 rùi mới tới smtp"