Messages posted by: myquartz

Thường phải hỏi thêm đó là môn học gì, ví dụ mạng (bảo mật mạng) hoặc là kiến trúc hệ điều hành.
Nếu môn đó là môn ... toán học thì cũng phải xem kỹ.
Hash injection có phải là để phá hoặc để giảm hiệu quả của hàm hash chăng?

Đúng là khi request đến mycompany.com.vn sẽ ra 4 địa chỉ.
Tuy nhiên đa số các ứng dụng nó chỉ lấy và xài cái địa chỉ đầu tiên (thường là qua hàm gethostbyname). Do đó nên nó sẽ ko thể kết nối được nếu cái đầu tiên đó vô tình trúng cái máy bị chết.
Mà DNS server thì nó round robin cái đầu tiên đó khi gửi về client, mỗi lần request sẽ trả về 1 địa chỉ khác nhau, thay nhau vòng tròn.

Có pass rồi mà connect chập chờn, thì do sóng yếu. Sóng Win báo như vậy là yếu rồi.
Thử mang laptop tới các vị trí gần hơn hoặc ít bị che khuất hơn so với AP xem. Một cách khác là mua an-ten tăng phạm vi phủ sóng cho AP, loại to, dài hơn ấy, sẽ cải thiện đáng kể.

gõ 2 lệnh là chown root.root /etc/php.ini và chmod 444 /etc/php.ini
Đảm bảo ko có thằng nào change đc.

Một cách khác là xài flag ở trong mod_php với apache, là php_admin_flag safe_mode on trong directory chứa script php. Cái file config của apache này ko ai change đc trừ root.

phamduccanh wrote:

Khi bị mất dữ liệu thì với FAT32 và NTFS thì phân vùng nào có thể khôi phục lại dễ dàng và nhiều hơn ?

Mất dữ liệu kiểu gì mới được chứ? Ví dụ nếu format nhầm, hay là xóa nhầm thì cả 2 đều rủi ro như nhau cả. Có khác là để khôi phục NTFS sẽ tốn $$ hơn vì nó bí mật cấu trúc.

Còn mất dữ liệu kiểu như bị cúp điện đột ngột, treo máy hoặc lớn hơn là bị hư vài sector thì NTFS sẽ chịu lỗi tốt hơn. Việc cúp điện đột ngột là việc hết sức thường xuyên, NTFS thiết kế để chịu những sốc như thế, FAT thì không.

Bài này kiểu như xào lại bài tớ viết từ lâu lâu lắm rồi. Xào lại nhưng có 1 đôi chỗ ko chính xác lắm.
(Nguồn http://www.vninformatics.com/forum/post/1023487672/ ).

Modem ở đây chắc là ADSL modem (gói cước 250k chắc là FPT).
Cách nối kiểu song song dây điện thoại đó, sẽ chỉ có 1 modem hoạt động được trong cùng 1 thời điểm. (tức là 1 cái mở thì cái kia phải tắt, cả 2 cùng mở thì ko bên nào vào đc Internet được).
FPT nó fix account theo địa chỉ MAC của modem, do đó cần phải có 1 modem clone được MAC của modem kia và kết nối PPPoE, hoặc là 1 bên có 1 cái Router làm được việc đó.

Nếu muốn sử dụng cả 2 bên cùng lúc (mà cái này quan trọng), thì chỉ cắm modem 1 bên thôi, share 2 nhà, mạng nối bằng dây điện thoại 2 nhà với nhau, 2 bên dùng 1 cái gọi là Telephone Line Network, ko rõ ở VN có chỗ nào bán ko. Xem khái niệm ở: http://en.wikipedia.org/wiki/HomePNA và http://www.homenethelp.com/network/phoneline.asp
Kết nối qua cái line này có thể đạt được 300m, tốc độ 10mbps.
1 cách nữa, xài qua đg đt đó là dùng modem G.SHDSL hay VDSL (chớ có nhầm với ADSL rẻ tiền nhé), tốc độ tối đa là 2mbit/s, nhưng khoảng cách có thể dài tới 3-5km. Giá đầu cuối khoảng 500USD mỗi 1 đầu đấy.

Tốt nhất, lời khuyên là bạn nên cố mua dây mạng LAN, giá chứng 3k-5K/m, tối đa là 100m (nghĩa là cũng chỉ hết có 500KVND thôi. Nếu như khoảng cách đó ok.

Terminus tớ xài lâu rồi, quả là tốt.
Nhưng cái dở của Terminus là ko ... support tiếng Việt, nên dùng cho cái code editor, soạn code HTML chẳng hạn, rất bất tiện. Nên xài với console thì ít bị khó chịu này.
Giá có ai rảnh thêm hỗ trợ tiếng Việt vào thì hay biết mấy.

Hầu hết các router/modem đều chỉ kiểm soát được việc up lên (tức là phân chia bandwidth, ưu tiên... của luồng dữ liệu gửi đi từ mạng LAN ra Internet).
Còn kiểm soát và ưu tiên bandwidth cho download rất khó làm vì nó phụ thuộc vào bên gửi hơn là bên nhận. Phía server gửi về bao nhiêu thì con router nó nhận bấy nhiêu và chuyển lại cho client hết. Việc kiểm soát down xuống thường chỉ áp dụng được với TCP, còn với UDP (xem truyền hình trực tuyến chẳng hạn), thì không thể làm gì cả, bao nhiêu UDP đổ về phải xài bấy nhiêu. Cái này thường bị lợi dụng để làm nghẹt đường truyền của ai đó.
Người ta kiểm soát TCP bằng mấy cách sau:
- Tìm cách shape dữ liệu down về, giữ trễ lại ở queue ko chuyển cho client vội nếu như vượt quá tốc độ cho phép. Nếu như ko có dữ liệu về, client ko ACK, thì server sẽ tự giảm tốc độ gửi đi. Cách này có thể áp dụng cho một số thiết bị xịn như Cisco router, hoặc Linux cũng có thể làm được. Ưu của cái này là áp dụng cho nhiều giao thức được, còn nhược là con router/gateway phải xịn hơn và phải biết thiết lập nó.
- Tìm cách tỉnh chỉnh gói tin ACK từ client, thay đổi receive window size để báo cho server biết mà giảm tốc độ. Cái này ít thấy áp dụng, chỉ có một giải pháp là routeskeeper gì đó áp đặt vào. Cái này cũng là Linux thôi.
- Dùng proxy có khả năng delay/limit bandwidth: dùng squid với delay pool có thể limit tốc độ down của client.

Các giải pháp ăn sẵn hiện tại, tức là mua, cắm, chỉnh tí xíu rồi chạy, đều khó kiếm và cũng mắc tiền. Bạn phải thuê chuyên gia hoặc tự tìm mà triển khai. Với việc hạn chế down qua web, cách hay nhất và rẻ tiền nhất là xài squid. Nó limit tốc độ down của các client một cách chính xác, và khá là thoải mái.
Microsoft ISA ko có khả năng limit bandwidth như thế, đừng hi vọng trông mong gì cả ở nó.

Dùng Fedora trên desktop và CentOS cho server là chính, hầu như ko dùng Windows (chỉ xài một vài lúc để ... chơi game).
Kiến thức về Win giờ mai một nhiều rồi, ko còn biết nhiều Vista, 7 nó ra sao nữa, vào cái laptop chạy Vista lúng ta lung túng, hic.

Nên dùng fail2ban hay hơn, nó sẽ chặn cho việc tấn công không thể liên tục, và tự động giải việc ban đó khi kết thúc tấn công.

StarGhost wrote:

---> Bạn myquartz thử ví dụ cho mình xem điều luật ở đâu đó quy định việc chịu liên đới nếu như mạng (hoặc máy tính) của ai đó bị lợi dụng để thực hiện tấn công. Mình mù tịt về chuyện này nên cũng muốn biết rõ.

---> Vậy cái này ngăn chặn được ai đây?

---> Thế còn "kiểu" gì nữa, tại sao phải nói ở topic khác? Vậy cái "kiểu" ở topic này là "kiểu" gì?

- Luật đó thì ko cụ thể, nhưng nói chung khi xảy ra chuyện, bên công an họ sẽ lần ra dấu vết của quán cafe đó, họ sẽ phỏng vấn chủ quán và nhân viên, hỏi khách hàng nào, đã ra vào ra sao, dùng máy tính thế nào, mô tả nhận dạng... Nói chung là phiền phức và có thể chủ quán sẽ bị điều tra (biết đâu anh ta chính là thủ phạm...). Trách nhiệm liên đới là thế. Cái này nhiều chủ quán Internet đã dính đòn, khi việc đó liên quan đến an ninh quốc gia, bên an ninh họ tới bê nguyên cả dàn máy tình về, kiểm tra từng ổ cứng, kiểm tra xem chủ quán có ghi lại số CMND... của khách không, chỉ mặt từng ông khách...

- Việc đó ngăn chặn được ai đó muốn tạo virtual server một cách bừa bãi, ko có pass đó thì quên việc tạo VS đi.

- Kiểu dùng ở nhà hay cơ quan khác với kiểu ở quán cafê hay là Hotel, đơn giản vì tập hợp người sử dụng là tương đối ổn định, biết mặt biết tên. Ở Hotel hay cafe, thì khách vãng lai, nhiều loại wifi client khác nhau. Do đó giải pháp áp dụng security cho 2 trường hợp này khác nhau. Bài này nói về kiểu Hotel hay cafe nên về security hiện chưa có gì nhiều để mà nói.

Wifi chỉ là công cụ kết nối tương tự mạng LAN, chỉ khác là nó không có dây. Việc bảo mật nó là trách nhiệm của chủ cái mạng WLAN đó, họ cho phép/không cho phép, dù vô tình hay hữu ý để mạng WLAN và kết nối ADSL của họ bị lợi dụng, để làm phishing hay bất cứ thứ gì (kể cả kết nối outbound tấn công 1 site nào đó), thì họ phải chịu trách nhiệm liên đới (nếu có việc xảy ra).
Về cái việc mở Inbound hay Virtual Server, kỳ thực dễ chống lắm, chỉ cần thay đổi mật khẩu mặc định của router/gateway kết nối Internet thành 1 chuỗi khó đoán là được.

Còn bảo mật riêng cái Wifi, kiểu như để người nhà mình hay cơ quan xài thay cho LAN, thì nên nói ở một mục khác. Cái này nó tuỳ theo điều kiện, loại client mà mình phải phục vụ và mức độ an toàn cần thiết.

Bài này đến đây được đánh giá là đi lạc chủ đề ... trầm trọng, xa tít mù tắp. Chả liên hệ gì đến cái gọi là "Remote Desktop qua Internet" cả, và cũng ko rõ chủ nhân của topic đã ... có thành quả gì khi giải quyết trục trặc gặp phải.

Tìm 2 từ khoá là Open Source (chứ không phải open soft) và Sendmail (viết liền).

Tóm lại là bác chủ topic đưa câu hỏi, làm ơn post cái nội dung cấu hình của con r2800 (gõ lệnh show run lên rồi còp nội dung paste vô đây).
Con Draytek thì làm ơn post mấy cái capture của các page cần thiết (gồm NAT, static routing, LAN setting).

Viết đi viết lại mà lại quá ít thông tin thì ma nào có thể biết đang sai sót cái gì đây.

Cái này phụ thuộc cách triển khai, nếu con R2800 chạy chế độ NAT, tức là che đi mạng bên trong đối với bên ngoài, thì cần phải xem nó NAT thế nào (đây là NAT 2 lần ở 2 con). Còn nó chạy non-NAT (thường router người ta làm cái này là chính), thì phần routing của Draytek phải có cái static route về mạng trong.

PC --- subnet 10.x.x.x - R2800 (NAT trên Interface này) 192.168.2.2 ------- 192.168.2.1 (Draytek) --- Internet

Draytek nó forward 1 port vào 192.168.2.2, thì R2800 phải cấu hình để NAT 1 lần nữa vào trong 10.x.x.x nào đó.

Sẽ cấu hình khác với:

PC --- subnet 10.x.x.x - R2800 (không-NAT) 192.168.2.2 ------- 192.168.2.1 (Draytek) --- Internet.

Draytek sẽ forward thẳng vào 10.x.x.x, nếu thiếu route, Draytek nó ko biết mạng 10.x.x.x sẽ phải đi về 192.168.2.2, nên nó sẽ ko thể route các gói tin được gửi tới đúng được.

Linh tinh quá.
Post cái config của con router 2800 đó vào đây, kiêm cả các thông số IP, subnet... của con Draytek.
Nói chung nếu R2800 chạy chế độ routing only (non-NAT) 2 subnet (1 nối PC, 1 nối Draytek), thì lỗi cơ bản thường là do trên con Draytek ko có tạo cái route back cái subnet nối với PC qua con R2800.

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 ạ.

Theo em, cách sử dụng SMTP của ISP để relay khá cổ điển, truyền thống, nhưng chính nó lại không đảm bảo việc chống SPAM hiện tại. Tại sao thế? các máy tính botnet của KH trong ISP đó hoàn toàn có thể lợi dụng SMTP của chính ISP để gửi SPAM đi, nếu SMTP đó chỉ lọc chặn theo IP để cho relay. Nếu có thêm phương pháp nào đó khác thêm ngoài việc lọc theo IP thì rẻ riền và dễ làm nhất là SMTP-AUTH. Trong 1 ISP hầu như em chưa gặp giải pháp sử dụng VPN để nối với KH của họ tới SMTP, còn webmail thì cũng hạn chế tính năng (xem ở dưới ạ).
Còn 2 điểm nữa liên quan đến việc bất lợi khi sử dụng SMTP của ISP, đó là với mobile client, họ có thể vào cafe wifi, mạng 3G, ADSL ở nhà để gửi mail, không có gì đảm bảo là chúng sẽ được cung cấp bởi 1 ISP, và user sẽ phải thay tham số SMTP outgoing liên tục? Và điều khó khăn thực sự nếu 1 quán cafe wifi họ xài WAN load balancing với 2 ISP khác nhau, đi lối nào chỉ biết khi mở kết nối TCP? Đó là điều khác nhiều với 10 năm trước đây cách người ta dùng Internet.

Còn việc SMTP-AUTH rồi mới cho relay, theo em thì không thể làm nguồn cho SPAM được, đơn giản spammer không có password của 1 ai đó của công ty. Tất nhiên giả sử rằng chính sách mật khẩu của công ty là tốt. Nếu lộ mất password thì nguy hiểm không chỉ là bị lợi dụng gửi spam đi. Bảo mật hay kém bảo mật không phải vì cái SMTP-AUTH mà là vì cái mật khẩu đó bị lộ. Nếu cần strong hơn, em sẽ ép user xài TLS/SSL với Token để xác thực user, khỏi lo luôn.

Em không tranh cãi về các cách để VPN hay sử dụng webmail so với cách SMTP-AUTH over TLS, mỗi cái có cái hay/dở riêng và là các con đường cho mục đích giống nhau. Tuy nhiên, nếu đảm bảo bảo mật, không phải là cái đó sẽ tăng thêm hay giảm đi bảo mật đâu bác. Các công ty ở Úc không xài cái SMTP-AUTH, cái đó bác biết rõ, nhưng em biết ở VN thì nhiều công ty họ xài SMTP-AUTH lắm, và họ cho phép user của họ relay qua SMTP của họ, thay vì dùng SMTP của ISP. Điều này cũng an toàn như VPN/webmail vì mail gửi nội bộ trong công ty sẽ không đi qua 1 host trung gian xử lý nào khác như là SMTP của ISP.

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.

Nói chung, bác yêu và bảo vệ qmail, em cũng thấy nó rất tốt nhưng chỉ chê nó cổ rồi và không uyển chuyển (tức là nó không dễ dàng thay đổi bằng tham số cấu hình) để đáp ứng nhiều kiểu khác nhau, trong đó có kiểu kiêm nhiệm 2 chức năng như em đã gặp phải.

Mọi giải pháp đều để đáp ứng yêu cầu thực tế đề ra, yêu cầu thực tế bác gặp phải khác em nên giải pháp kỹ thuật em chọn nó khác, không xài được qmail. Còn em thực sự không quan tâm xem RFC này nọ có hợp không.
Cảm ơn bác đã quan tâm.

StarGhost wrote:

- 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ì?

The last thing: cái chủ đề này đã đi xa khỏi cái topic title rồi. Tôi cũng stop tại đây, xin cảm ơn.

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.

- 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.

=> Cái này qmail cũng không làm được nốt, vì hầu hết các patch của nó đều xác thực trước, pass rồi thì tới đoạn MAIL FROM/RCPT TO. Tới công đoạn sau rồi thì không còn check thêm gì về user nữa.

nxthao wrote:

Sếp e yêu cầu ghê quá
Yêu cầu của sếp là biến Ubuntu thành cái Router với 1 đường ADSL,1 đường FPT và 1 đường Lan nối vào internal network.Sếp muốn cái Router này phải có load balancing và fail over giữa ADSL và FPT,tiếp theo là speed của Lan cable = speed của ADSL + FPT ( vd ADSL la 4mb,fpt 8m thì tốc độ down ở Lan phải đo được là 12mb ).Chưa hết,yêu cầu thêm là nếu có 10 packets thì 7 packets đi qua FPT,3 packets đi qua ADSL.Xin hỏi là có làm được không,e đã tìm cách làm khá lâu rồi mà chưa được,xin cám ơn!

Cái màu vàng thì khó đạt được 100% (có thể lấp đầy các kênh ở mức độ nhất định nào đó thôi, nhưng chú thích là không phải down 1 kết nối đạt được như thế nhé, phải là tổng nhiều kết nối, nhiều site khác nhau), còn cái màu đỏ thì không thể làm được (với điều kiện của bạn).
Các cái khác có thể đáp ứng được.
Dùng Fedora đi, tớ sẽ chỉ cho, tớ ko thích Ubuntu lắm.

conmale wrote:

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ì.

Hì, em nghĩ bác đang hiểu lầm ý em, em mô tả lại cho bác hiểu nhé.
Em tạm gọi mail client của bác là mail user agent = MUA, cho nó đồng hành với MTA.

Công ty em, mycompany.vn, có 1 cái mail server đặt tại 1 ISP nào đó, có static IP. tên cái server này là mail.mycompany.vn, với bản ghi MX của domain mycompany.vn được ghi là mail.mycompany.vn. Sơ bộ các đặc điểm như sau:

1. mail server được cài đủ cả dịch vụ: POP/IMAP/SMTP/Webmail. Tuy nhiên ta chỉ nói đến cái SMTP và MTA trên cái mail server vì nó là chủ đề thảo luận chính.
2. mail server có nhiệm vụ nhận email từ công ty khác, nghĩa là email từ @domain không phải mycompany.vn tới. Các MTA khác sẽ gửi tới mail server qua SMTP với 1 chuỗi lệnh: EHLO xxx, MAIL FROM, RCPT TO....
3. mail server cũng là "outgoing SMTP server" cho các user của công ty. Mọi MUA của công ty đều phải setup để tham số outgoing SMTP server = mail.mycompany.vn.
4. Để không là Open Relay, nhưng cần relay cho các user của em, em setup để mọi user công ty muốn gửi mail (relay cho domain khác hay cho cùng domain) phải xác thực bằng chính user của họ, qua cái mail server. Các MUA đều được bật cái này lên. Lúc này MUA sẽ kết nối đến mail server với 1 chuỗi lệnh SMTP: EHLO xxx, AUTH LOGIN, MAIL FROM, RCPT TO...
5. Để chống spam, em dùng RBL.

Nếu em dùng qmail + RBL (thỏa mãn điểm 5), kết quả sẽ như sau:

- Xét điểm 2: Các MTA khác gửi tới mail server ok, ngon lành, nếu pass được cái RBL check.
Nhưng 1 thằng spammer, giả làm MTA, IP của nó nằm trong RBL, thì sao?
Khi nó gửi mail đến user của em. IP của nó bị check và nằm trong RBL. sau chuỗi lệnh: EHLO xxx, MAIL FROM: xxx nó nhận ngay được câu reject. => OK very good.

IP nằm trong RBL khi nào? đó là các MTA bị Open Relay, bị lợi dụng... Nhưng có 1 loại IP thường bị nằm trong này, chính là Dynamic IP của 1 ISP nào đó. Tại sao vậy, vì các MTA hợp lệ thường ... giống công ty em, thuê server ngon lành, có static IP ngon lành... các RBL liệt Dynamic IP vào dạng blacklist (nếu làm MTA).
Dynamic IP thường được gán cho các thuê bao ADSL, dial-up... Do đó nếu dùng các kết nối này làm MTA gửi thì hay bị reject lắm (không kể trường hợp ADSL nhưng lại mua IP tĩnh nhé)

- 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.

Em hi vọng là bác hiểu ý em. Nếu không thì em cũng xin hàng vì khả năng diễn đạt của em chỉ có đến vậy.

P/S: À, mà cái vụ tách tời incoming/outgoing SMTP server là thế này:
- Công ty em có rất nhiều user, rất nhiều email/ngày và có 1 số lý do bảo mật khác, nên em tách việc nhận/gửi riêng ra. Em có 2 server cho việc này, 1 cái là in-mail.mycompany.vn, cái kia là out-mail.mycompany.vn.
- Bản ghi MX của @mycompany.vn được gán thành in-mail.mycompany.vn => mọi email từ domain khác đến đều vào in-mail.
- Các MUA của công ty setup để xài out-mail.mycompany.vn. như là Outgoing SMTP Server.

2 cái khác nhau của in-mail và out-mail là:
- In-mail: chỉ nhận từ MTA khác qua SMTL về local => có RBL, có check anti-virus, spam, TLS là optional.... Sử dụng qmail + RBL ok.
- Out-mail: chỉ nhận mail từ MUA qua SMTP rồi relay đi (hoặc lưu về local): ko có RBL, ko chống spam, nhưng bắt buộc phải authenticate, có anti-virus, TLS là bắt buộc... Qmail cũng làm tốt tuy nhiên không linh hoạt lắm trong trường hợp này.

Em không nhầm lẫn với qmail-send và qmail-smtp (dù khái niệm nó hơi ... giống nhau). Trên cả 2 con in-mail và out-mail đều xài 1 hoặc cả 2 cái này. In-mail chỉ xài qmail-smtp là chính và xài qmail-send 1 ít (khi gửi các mail daemon notification chẳng hạn). Còn out-mail thì cả 2 cái tích cực.

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.

vdtruong2003 wrote:

Ah, mình thường vào bằng 192.168.1.10, nhưng vì lúc chụp hình đưa lên mạng tiện thể đang vào bằng hlucin.mine.nu thì dùng luôn.

Mình đang dùng mạng Lan cùng với IP camera và router để xem camera, chứ ra ngoài mạng khác vẫn chưa xem được mà.

Hợp đồng không có khoản nào ràng buộc là không được phép làm sever cả.

Mình cũng đã thử đổi port nhiều lần nhưng vẫn vô phương.

Cho mình hỏi chút, nếu trường hợp này mọi thứ mình đã làm đúng, nguyên nhân không ra net xem được theo các bạn là do mô hình của mình đã qua modem còn thêm router. Vậy nếu ở nhà cung cấp ISP khác, với đường truyền ADSL chỉ có Modem (Modem router)---> máy tính, camera IP thì sẽ chạy OK phải không.
Thanks !

Hic, vào bằng hlucin.mime.nu, mà lại ở cùng mạng LAN, thì nó sẽ phải khác chứ nhỉ? Thường thì các router sẽ không cho phép bạn kết nối tới hlucin.mime.nu (là địa chỉ WAN) mà nó forward vào 1 địa chỉ bên trong rồi. Có điều gì chưa clear hoặc sai sót ở đây.
Bạn thử mở cửa sổ lệnh cmd, gõ thử: ping hlucin.mime.nu
Dynamic DNS của hlucin.mime.nu bắt buộc phải thiết đặt trên router, không đặt trên Camera (vì router mới có địa chỉ public). Nếu ping ra đia chỉ khác với địa chỉ WAN thì sai sót ở đây.

Bạn an tâm về mô hình, nó đúng rồi. Khác với truy cập ADSL modem (thường tích hợp luôn router ở trong), cable modem thường là thiết bị lớp 2 (tức là nó là cái switch 2 port, 1 port nối với nhà cung cấp, 1 port với PC/router của khách hàng). Và ISP thường lock lại để duy nhất 1 MAC có thể truy cập. Muốn chia sẻ phải có router ở sau.

Nếu bước cuối ko thể sửa chữa, mình có thể giúp bạn qua 1 tiện ích remote control như là VNC chẳng hạn. Mình thường online từ 13h-17h chiều, hoặc 20h tới 23h đêm, giờ VN. Sẵn lòng giúp bạn xác định nguyên nhân từ xa, nếu bạn đồng ý.

m3onh0x84 wrote:

Anh tranhuuphuoc cho em hỏi 1 câu nghe chuối:
Trong trường hợp này của anh, tại sao anh lại dùng cái firewall lạ hoắc này mà k0 dùng iptables hay mono firewall hay vô số firewall thông dụng khác ?

Endian nó cũng là iptables thôi, nó dựa trên linux mà. Có 1 phần phát sinh từ IPCop, 1 phần khác thì họ thêm vào. Nói chung nó khá giống IPCop và thêm được 1 loạt thứ mà tôi coi là rất hữu ích (nhất là với khách hàng đang xài IPCop).
Theo tôi, cái hữu ích nhất, mà lại miễn phí khiến tôi chọn Endian là: diệt virus (clamav) cho HTTP proxy. Bây giờ nguồn mã độc từ website rất nhiều, phổ biến. Cái này sẽ bảo vệ hiệu quả cho khách hàng của mình vô tình mở các trang web độc, giảm bớt nguy cơ.
Các loại khác đều không có cái này miễn phí, trừ khi bạn tự ráp các thành phần và build lấy.
Tất nhiên tôi không so sánh với 1 số firewall mà nó phục vụ mục đích khác, mà là nhằm vào "Internet Sharing" như series các firewall: IPCop, Endian, Monowall, pfsense, Smoothwall hay ClarkConnect...

Mọi thử từ router có vẻ đúng rồi đấy, nhưng không chạy được hơi lạ.
Đang thắc mắc sao bạn lại vào cái quản trị IP Camera bằng địa chỉ: hlucin.mine.nu, sao không xài là 192.168.1.10? Cái này là bạn đang sử dụng kết nối nào để quản trị camera đó? mạng LAN cùng với IP Camera + Router hay là ở đâu đó?
Việc xem camera có cùng chỗ với lại trang quản trị không? hay phải dùng soft/port nào đặc biệt?

Một việc nữa, check lại xem thỏa thuận sử dụng với ISP cung cấp dịch vụ Internet với bạn có điều nào họ không cho phép bạn làm server, như là HTTP server?

Bạn thử đổi cổng tất cả các chỗ từ port forwarding tới IP camera thành 1 số khác, ví dụ 10000 chẳng hạn coi.

Cài máy ảo VMware xài, VMware có tạo cái gọi là vmnet, brigde các máy ảo với mạng LAN qua card LAN duy nhất.
Thế là thành ra máy trở thành cái bridger, và có nhiều MAC trên 1 card mạng là chuyện đương nhiên.

Không rõ tại sao post bài trả lời toàn dính lỗi nè:
java.lang.StringIndexOutOfBoundsException: String index out of range: -148
Không rõ mình đã gõ gì bất hợp lệ chăng?

Đành post trả lời ở 1 forum khác: http://forum.vnoss.org/post39292.html

Tớ không có ý chê qmail, nhưng đây chính là hạn chế của qmail khi sử dụng RBL và tích hợp cả gửi và nhận email trên 1 SMTP server duy nhất.
Xem tớ ví dụ đoạn SMTP dialog sau:

Code:

$ telnet hva.net 25
Trying hva.net...
Connected to hva.net.
Escape character is '^'.
220 rblsmtpd.local
HELO test
250 rblsmtpd.local
AUTH LOGIN
451 http://www.spamhaus.org/query/bl?ip=118.68.169.34
QUIT
221 rblsmtpd.local

Do các quá trình check RBL, xác thực, nhận mail ... của qmail xuyên suốt theo 1 cái đường ống pipe, cái nọ nối tiếp cái kia. Phải pass qua cái đầu mới đi đến cái tiếp theo.
Nếu người sử dụng truy cập ở IP bị RBL chặn (như tớ), nhưng xác thực để gửi mail đi, khi xác thực rồi thì không được coi client đó là spammer nữa và phải bypass cái check RBL đi. Kiến trúc của Qmail khó làm được điều này được vì 2 tiến trình check RBL + xác thực là hoàn toàn độc lập nhau (ở đây xác thực tớ xài vpopmail), phải pass qua cái check RBL rồi mới pipe dữ liệu cho xác thực được.
Vì thế qmail + RBL đã giết nhầm client, mà họ lại thường là mobility client, truy cập ở bất kỳ đâu có Internet.

Xem tớ sử dụng postfix cho trường hợp này, thay cho qmail:

Code:

smtpd_recipient_restrictions =
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_rbl_client dnsbl.sorbs.net,
reject_rbl_client bl.spamcop.net,
reject_rbl_client zen.spamhaus.org
permit

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.

Ngoài lề:
Qmail còn 1 hạn chế nữa là cái quá trình xác thực và quá trình nhận mail cũng tách riêng ra, 1 cái do patch tool làm, cái kia do qmail làm, do đó nó không match được username đã xác thực với lại from email. Nghĩa là anh conmale xác thực rồi thì from <xxxx@hva.net> gì cũng được.
Với postfix, có thể chặn điều này, anh conmale nhất định chỉ được phép from: <conmale@hva.net> như sau:

Code:

smtpd_sender_restrictions =
reject_non_fqdn_sender
reject_authenticated_sender_login_mismatch
permit_mynetworks
reject_unknown_sender_domain
reject_unauthenticated_sender_login_mismatch

Cái tham số reject_unauthenticated_sender_login_mismatch cho phép nếu không xác thực thì không thể gửi from @domain của chúng tôi (vì nó match với 1 user nào đó của chúng tôi rồi). Cái này để chống cái kiểu chơi không cần xác thực mà: MAIL FROM: <conmale@hva.net> RCPT TO: <conmale@hva.net>, qmail sẽ pass qua cái này (nếu ko bị RBL), nhưng reject_unauthenticated_sender_login_mismatch sẽ báo là: Not Logged In. Spammer rất khoái xài cái này, ghi nhận của server của tôi nó tới 10 ngàn lần/1 ngày.

Ý kiến riêng: nếu qmail vẫn đảm bảo nhu cầu của bạn, thì cứ dùng nó. Nhưng nếu bạn cần "chống spam" tốt hơn với RBL, linh hoạt hơn như mấy yêu cầu trên, thì postfix có thể tốt hơn. Tớ chưa dùng exim nên không có kết luận gì hơn.

conmale: thử post bài myquartz bị trở ngại khi post.

Windows XP 32bit, nếu cài Service Pack 3 thì sẽ nhận được nhiều hơn 3GB RAM. Nhờ có PAE. (http://en.wikipedia.org/wiki/Physical_Address_Extension)

Hi!
Như thế này là IP public, có khả năng xài được.
Hãy mở cái Forwarding và cái Security coi sao.
Chỉ cần forward vào bên trong, đúng IP, port của cái camera, là ok.
Còn cái security, chắc là dính dáng đến firewall, có thể phải mở port hoặc tắt cái phần firewall vậy.

Bạn cho xem nốt cái thông số qua web-based của cái IP Camera coi xem đã ổn chưa.