Xin chào ! Nếu đây là lần đầu tiên bạn đến với diễn đàn, xin vui lòng danh ra một phút bấm vào đây để đăng kí và tham gia thảo luận cùng VnPro.

Announcement

Collapse
No announcement yet.

Xây dựng hệ thống Mail Exchange FE/BE Anti-Spam/Virus hoàn chỉnh ntn ???

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Xây dựng hệ thống Mail Exchange FE/BE Anti-Spam/Virus hoàn chỉnh ntn ???

    Chào các anh chị và cô chú,

    Hệ thống Mail nội bộ có vai trò khá quan trọng đối với các doanh nghiệp & tổ chức. Tuy nhiên để xây dựng và hoàn thiện một hệ thống Mail khá lớn là việc không hề đơn giản. Ở đây Mèo Con muốn bàn đến hệ thống mail Exchange của Microsoft, một ứng dụng phổ biến, chuyên nghiệp, scalable và cũng phức tạp. Các hệ thống Mail khá lớn thường dùng mô hình Front end/Back end để chuyên môn hóa công việc, cái này Exchange hỗ trợ rất tốt. Tuy nhiên vấn đề sẽ phức tạp hơn khi phải kết hợp hệ thống Mail với tường lửa, DMZ, SMTP Relay và các công cụ chống Spam/Virus; và khi đó chúng ta có nhiều lựa chọn để cân nhắc. Việc dùng SMTP Relay tại DMZ chủ yếu làm tăng Security nhưng cũng gây phức tạp và lãng phí ko ít. Việc dùng Front End là cần thiết khi hệ thống có nhiều Back Ends, và khi đó việc để Front End ở đâu, trong DMZ hay cùng subnet với Back End cũng cần xem xét. Nếu hệ thống dùng các công cụ chống Spam (như GFI MailEssentials) và Virus (như GFI MailSecurity) thì việc cài đặt các công cụ này trên 1 Seperate machine (SMTP Relay) ko cài Exchange, hoặc cài lên FE Exchange, hoặc cài lên BE Exchange, cũng cần được cân nhắc. Và để phục vụ Fault Tolerance thì việc lựa chọn NLB cho SMTP relay và FE, cũng như Cluster cho BE đôi khi cũng phải tính đến. Rồi là việc Backup Internet line, Backup MX ...

    Tóm lại Mèo Con thấy nhiều vấn đề xung quoanh việc xây dựng một hệ thống Exchange hoàn thiện, an toàn, có khả năng Scalable. Việc chống Spam một cách hiệu quả cũng trở nên khó khăn hơn bao giờ hết. Làm thế nào để cân bằng được các vấn đề finance, security, availability và performance. Một trong các đề nghị đó là đặt FE cùng subnet với BE để tăng performance, Firewall (ISA chẳng hạn) có thể đóng luôn vai trò SMTP Relay (để đỡ tốn 1 SMTP Relay trong DMZ), Anti virus/Anti Spam có thể cài lên FE hoặc BE. Nếu dùng GFI, có thể cài MailEssentials lên từng BE (nếu chỉ cài lên FE thì mình thấy nó ném Spam vào hết trong Junk Mail folder, ko chia được thành các thư mục chứa Spam riêng theo các tiêu chí lọc như: Keyword, Besian, Blacklist, URI, header ...), còn với MailSecurity thì cài lên FE khác gì với cài lên BE. Rất mong được trao đổi với các anh chị về vấn đề này.

    Thanks in advance.

  • #2
    Hi
    Nghe qua thì mình đã thấy bạn expert về phần Mail Exchange này rồi, không hiểu còn trao đổi được cái gì nữa. Mình cũng thích mảng này nên cũng đã có nghiên cứu qua. Bạn đã từng làm hệ thống như thế nào hoặc có mô hình cụ thể nào thì chia sẻ nhé.

    Comment


    • #3
      Chủ đề cua meocondihoc rất hay, bạn có thể đề xuất một vài giải pháp của bạn trong những tình huống cụ thể nào được không ?

      E-mail : vnpro2005 @ gmail . com

      Comment


      • #4
        Bi giờ chúng ta thử đi vào từng scenarios cụ thể hơn xem sao nhé. Mình thử đưa ra 1 scenario với một số yêu cầu như sau, rất mong các bạn bổ sung:

        - Hệ thống Exchange giả định cần có khả năng mở rộng về qui mô người dùng. Vậy là chúng ta cần nhiều BE, và đương nhiên phải có FE.
        - Hệ thống Mail phải có khả năng phòng chống Spam và Virus tốt. Ở đây chúng ta có thể thử dùng MailEssentials và MailSecurity của GFI xem sao, mấy soft này được Windows-Certified rùi nên rất compatible. Với MailSecurity, sẽ có khoảng trống để "nhồi" AntiVirus engine của nhiều hãng khác nhau. Nếu bạn nào có giải pháp khác thì cũng đưa ra nhé.
        - Hệ thống phải có khả năng backup đường truyền Internet. Vậy chúng ta cần tối thiểu 2 kết nối Wan và MX record. Nên sử dụng kết nối gì, và các kết nối đó Terminate ra sao khi gặp Firewall hoặc FE exchange gì đó, nói cách khác chúng sẽ Fail-Over sang nhau ntn.
        - Hệ thống phải có khả năng Fault Tolerance, thời gian Disaster Recovery time phải đủ nhanh, vì mail ko stop được lâu mà.
        - Rùi là Maintenance, Monitor ra sao để duy trì được Checked Points và High Performance nữa.

        .........

        Còn nhìu nhìu lắm. Đại khá diagram sẽ thế này:

        Wan connection 1 ----
        What ---- Firewall --- FE, BEs, DCs
        Wan connection 2 ----

        Mèo Con rất care vấn đề này, nên rất mong được trao đổi cùng anh chị và các bạn. Các anh chị cứ show ý kiến của mình, có thể Mèo con sẽ dựa vào đó để làm thí nghiệm rùi feedback kết quả lại.

        Waiting ......

        Comment


        • #5
          - Mình thì dùng trường phái khác để chặn virus và spam: dùng Norton Antivirus diệt virus, còn dùng chống Spam là Trend Micro rất hiệu quả đang dùng trên > 6000 account.

          - Nhưng mình đang phân vân là mình chì cài duy nhất 1 server mail Exchange, vậy mình lo khi server này chết là các account mail ko thể nào dùng được...

          ==> vậy mong mọi người chỉ giáo dùm mình làm sao dựng 1 con khác vào với độ ưu tiên MX thấp hơn sẽ có tác dụng xử lý và gánh cho con thứ nhất khi bị sự cố trong cùng domain.

          Note: trong cùng domain nhưng việc maibox tại 1 thời điểm chỉ lưu duy nhất trên 1 server...khi con này chết thì làm sao các account mail hoạt động bình được, mình ko biết? mong chỉ bảo.

          Giải pháp cho trường hợp này như thế nào? cách dựng ra sao?

          Comment


          • #6
            Tình huống của Hà đưa ra khá bất ngờ, mình cũng chưa để ý cái đó lắm. Thường thì người ta áp dụng NLB và Cluster. Trong hệ thống Exch, NLB có thể được apply cho các Stateless apps như FE, SMTP Relay, Firewall. Riêng với các ứng dụng Statefull kiểu như BE Exch thì thường dùng Cluster. Dùng Cluster cho BE thì khá phức tạp và tốn kém, cần đến các thiết bị lưu trữ data chuyên biệt riêng như NAS, SAN ... và bản thân các thiết bị đó thường fault-tolerance bằng RAID.

            Trường hợp của Hà đưa ra là muốn tạo thêm 1 Exch server nữa chỉ đóng vai trò Backup (ko load-balance hay load-share gì cả). Và khi con Pri bị down thì con Sec sẽ Online ngay để phục vụ, và Backup MX (internal và external) sẽ đảm nhiệm việc backup dns record.

            Việc fail-over kiểu backup như thế có thể dùng Raid trong phạm vi 1 server, hoặc dùng Cluster: clustering có nhiều chế độ, với Backup như trên thì dùng chế độ Active/Passive gì đấy mình cũng ko bít rõ. Hà thử tìm hiểu phương án Cluster xem sao.

            Ngoài ra mình cũng thấy lạ là với lượng user nhiều như thế mà chỉ dùng 1 Exch server (Hà có thể tiết lộ cấu hình hardware được ko nhỉ, chắc máy fai ngon lém). Mình đoán là lượng user nhiều nhưng có vẻ ít tăng, và storage cho mỗi user chắc ko nhiều lắm. Nếu vì tăng qui mô mà phải thêm Exch server, nghĩa là có nhiều BE Exch, thì khi đó nên có thêm cả FE nữa, bởi vì Internal user có thể trỏ thẳng đến các BE và hệ thống Exch tự biết redirect user đến đúng BE chứa Mailbox cần tìm, nhưng với External user thì khác. External users cần phải biết địa chỉ của từng BE (nếu có nhiều BE) để đến đúng BE cần tìm; việc này sẽ được giải quyết nếu có FE Exch, vì khi đó External users chỉ cần trỏ đến FE và FE sẽ redirect user đến đúng BE Exch.

            Mình thực sự chưa hình dung rõ chỉ với 1 Exch server như tr/hợp của Hà thì sẽ xử lý 6000 acc thế nào, có ảnh hưởng gì đến Performance ko, rồi còn backup nữa chứ.

            Rất mong được trao đổi cùng Hà và các bạn khác.

            Waiting ....

            Comment


            • #7
              Xin chào
              Một số ý kiến và kinh nghiệm tư vấn và xây dựng hệ thống Exchange của mình cho khách hàng, xin chia sẻ như thế này:

              Để tăng khả năng mở rộng của hệ thống Exchange, hiển nhiên là chúng ta phải sử dụng mô hình FE-BE, thậm chí một doanh nghiệp bình thường cũng nên triển khai điều này bởi vì máy chủ FE là đại diện cho hệ thống Exchange giao tiếp với người dùng, người dùng chỉ cần biết đến FE mà không quan tâm đến hòm thư của mình cụ thể nằm đâu, khi cần thay đổi toàn bộ hệ thống BE mà vẫn giữ nguyên FE thì người dùng không cần thay đổi gì, FE cho phép phân tách chức năng của hệ thống thư trên các máy chủ khác nhau do đó sẽ tăng cường hiệu năng chung của hệ thống và tăng cường khả năng bảo mật bởi máy chủ chứa mailbox sẽ không phải public ra Internet...

              Về hiệu năng, máy chủ BE chỉ lưu hòm thư nên cần hệ thống storage mạnh mà không cần khả năng xử lý cao, tuy nhiên lại cần tính sẵn sàng lớn nên thông thường sẽ triển khai cluster trên BE. Giải pháp này tuy tốn kém nhưng mình nghĩ đã là hệ thống lớn thì không nên tiếc tiền cho một giải pháp giá trị như thế, giải pháp cluster thường yêu cầu các tủ đĩa dùng chung và trên bản thân các tủ đĩa dùng chung này cũng đã có dự phòng các thành phần để tránh “single point of failure” rồi (ví dụ như redundant RAID controller, redundant path to host, cấu hình RAID, thậm chí cả redundant fan, power…) Hơn nữa, khi hệ thống cần mở rộng thêm dung lượng đĩa cho các hòm thư thì các tủ đĩa dùng chung này sẽ có khả năng mở rộng tốt hơn là các máy chủ. Còn đối với các FE thì thông thường chúng ta dùng NLB để tăng cường hiệu năng truy cập, lúc này thì cần máy chủ hiệu năng cao, khả năng xử lý lớn.

              Về Disaster recovery, các trường hợp hỏng thông thường về dịch vụ thì mình có thể sử dụng các công cụ, ví dụ như Recovery Storage Group để vừa hoạt động tạm, vừa khôi phục dần dần dữ liệu, nặng hơn mà phải thay máy chủ thì mình phải cài lại thôi, cài lại Exchange theo chế độ Disaster recovery mà có chuẩn bị kỹ càng rồi thì theo mình nghĩ mất cũng không quá 1h, sau đó khôi phục lại dữ liệu dần dần là ổn.

              Về vụ bảo vệ hệ thống thư trước virus và spam thì mình thấy vấn đề này cũng đã được bàn nhiều, có thể sử dụng bất cứ phần mềm nào bởi mình thấy mỗi phần mềm đều có các tính năng nổi bật (Trend, Symantec, GFI…), tuy nhiên nên sử dụng mô hình 2 lớp, trong đó có SMTP Relay Server là trung gian giữa hệ thống Exchange nội bộ với Internet để tăng cường khả năng chống tấn công và bảo mật nhiều tầng.

              Để tăng cường khả năng sẵn sàng trên đường truyền như meocondihoc đưa ra là hoàn toàn đúng rồi, 2 đường truyền, 2 bản ghi MX với các priority khác nhau, kết nối như thế nào thì mình nghĩ phải trong mô hình mạng cụ thể thì mới có thể phân tích sâu hơn được.

              Hệ thống Exchange của tranthanhhakg chắc là của một ISP nào đó nên mới có số lượng user lớn đến thế nhỉ, vì theo những khách hàng lớn mà mình đã từng làm, nhiều lắm cũng mới chỉ tầm 4000 account trên toàn quốc. Thế mà hệ thống của bạn chưa có cluster thì cũng nguy hiểm, mà 6000 mailbox này nằm trên một server duy nhất thì khó có thể đảm bảo hiệu năng dù server có lớn mức nào đi chăng nữa, mà cũng chưa có giải pháp Disaster recovery nữa sao.

              Comment


              • #8
                - Đúng là hệ thống của mình chưa chuẩn bị vấn đề phòng vệ. Các bác phân tích rất hay, tầm hiểu biết về Exchange rất sâu. Nhưng mình xin hỏi cách cấu hình FE, BE cụ thể như thế nào? NLF ? Mình rất quan tâm.

                - FE: có cần cài Exchange ko? có cùng domain với BE?
                - BE: mỗi server phân tải bao nhiêu account mail với quota khoảng 50M chẳng hạn?
                - Thêm BE: mỗi lần có phải cấu hình lại ko.

                Mong mọi người đóng góp ý kiến về vấn đề này. Để mọi người xây dựng 1 mô hình chuẩn thành công.

                Comment


                • #9
                  Chúng ta sẽ đi vào từng chi tiết cụ thể hơn của cái MultiTask này, bắt đầu với việc Sizing servers. Giả sử hệ thống có 1 Front End và vài con Back End gì đó, chúng ta sẽ phải Sizing các Exchange Servers (và cả các DC, Global Catalog) ntn ?

                  Chuyện này sẽ liên quan đến lựa chọn cấu hình Server (CPU, Ram, Disk Systems, RAID ....) cũng như việc đưa từng đối tượng chuyên môn (OS+Exchange sys files, Exch Database như Mailbox store và Public Folder store, Transaction Logs ...) vào từng Disk System khác nhau với các mức độ Raid, Cache, Disk Controller, Bus ... khác nhau.

                  Việc store các đối tượng khác nhau vào các hệ thống đĩa riêng biệt sẽ giúp tăng Performance, tăng Fault Tolerance, stability ... cũng như thuận tiện cho việc Restore, Backup.

                  Ví dụ Transaction Log thì chủ yếu dùng hoạt động Write (sequential) trong khi đó Database (mailbox, public folder) thì gồm cả Read và Write (Write vẫn nhiều hơn) một cách Random. Trans Log lưu các thay đổi đối với Database, trước khi các thay đổi đó được Write vào Database nên việc để riêng TRanslog cũng tăng Fault Tolerance. Và vì hoạt động của Exch nói chung là Write-intensive nên Disk system cần hỗ trợ mạnh Write-back cache ở mức disk controller (hơn là mức disk drive).

                  Chi tiết hơn nữa, có thể để Mailbox store và Public folder ở những vùng riêng biệt. Việc lựa chọn các loại Disk và Raid khác nhau (Raid 0, Raid 1, Raid 0+1, Raid 5, SAN, NAS ...) sẽ được cân nhắc phụ thuộc vào đặc điểm của từng loại data cũng như Budget và admin skill level.

                  Mèo Con mong được trao đổi kĩ hơn với anh chị về từng vấn đề cụ thể.
                  Thank you very much in advance.

                  waiting..

                  Comment


                  • #10
                    Mình cũng góp ý đôi chút với mô hình sau (mình đưa là một hệ thống cụ thể nhé-có diagram sau):

                    =================================================
                    ++++++++++++++++++++++++++++++++
                    +----------- FMS System --------------+
                    +++++++++++ Firewall L1 ++++++++++++ ......||
                    .................................................. ...............||
                    .................Other Server ..............................||> DMZ Outside
                    .................................................. ...............||
                    ------- Server Mail Frontend System ----.......||

                    +++++++++++ Firewall L2 +++++++++++..........||
                    .................................................. .................||
                    ------- Server Mail Backtend System ----..........||> DMZ Inside
                    ------------ Directory Server ------------..........||
                    .................................................. .................||
                    --------------- Storage System ---------.........||
                    =================================================
                    Sau đây mình giải thích mô hình trên, mình sẽ giải thích 2 phần : phần 1 là chức năng và hoạt động của từng hệ thống trên ; phần 2 là message được route như thế nào thông qua đó.
                    Phần 1 :
                    Mô hình trên với hệ thống Firewall 2 lớp gồm 2 vùng DMZ inside và Outside. DMZ Outsize dưới Firewall L1 gồm một hệ thống các server trong đó có Hệ Mail Server Frontend. FMS server được quản lý bởi Firewall L1, FMS Server (Trend Micro )trước tiên là một mail server và có chức năng đặt biệt là hệ thống server này dùng để Filter các vấn đề về virus, size filter, spam filter...cho hệ thống mail Tất cả các policy về mail incomming và outgoing đều được deploy tại đây. Hệ server này cũng được sử dụng để giảm tải đáng kể cho hệ thống mail frontend dưới nó.
                    Server mail Frontend System, là một hệ gồm một hay nhiều các mail server được sử dụng để xử lý các yêu cầu của remote side như SMTP, POP3, IMAP và HTTP. Trên đây, ta vẫn cài đặt hệ thống mail bình thường nhưng không có hệ thống lưu trữ mail. Hệ thống này còn được gọi là Messaging Multiplexor. Khi có client kết nối vào Multiplexor này, nó sẽ thực hiện query Directory Server để lấy thông tin về user và redirect đến hệ Mail Server backend để nhận mail...
                    Tiếp theo, vùng DMZ inside (hay DMZ internal) bao gồm các hệ server như Mail Backend, Directory Server, Storage system.....và các hệ thống server khác dùng cho chức năng lưu trử như File server, ftp server, backend webserver....
                    Hệ Backend Mail server ở đây gồm một hay nhiều mail server và được triển khai clustering để sử dụng chung tài nguyên của hệ Storage system. Hệ server này sử dụng để lưu trử hệ thống các datamail.
                    Và Directory server với triển khai Domain controller được sử dụng như là một Authentication server cho các query của server mail fontend và backend.

                    Phần 2 :
                    Triển khai trên Firewall L1 và L2 để message có route đi như sau :
                    A quên, trước hết để gửi/nhân được mail ngoài Internet ta phải cấu hình các bản ghi MX trên DNS để message của ta "đi đến nơi về đến chốn".
                    FMS server và Mail Frontend Server sẽ có bản ghi MX trên DNS với độ ưu tiên của FMS cao hơn (mình sẽ giải thích vấn đề này sau).
                    Các client muốn kết nối để gửi và nhân mail bằng các hình thức như sử dụng các chương trình mail client (MS, OE) hay dùng Web mail đều phải làm việc trực tiếp với hệ Mail Frontend server (MFE). Khi client kết nối đến MFE, MFE này sẽ query Directory server để kiểm tra authenticate cho user, nếu thành công sẽ redirect đến Mail backend (MBE) để lấy mail. Điều này xảy ra tương tự khi sử dụng webmail, trong trường hợp này MFE sẽ đóng vai trò là mail client (via web interface).
                    Khi muốn gửi mail đi bằng chương trình mail client(OE, MsO), mail sẽ được gửi đi từ MFE qua hệ FMS để kiểm tra virus,.... và khi muốn gửi mail bằng web mail thì mail sẽ được gửi đi từ MBE và cũng phải qua FMS để kiểm tra.
                    Khi mail được nhận về, nó sẽ được nhận bằng FMS system (do có độ ưu tiên cao hơn) và sẽ đẩy mail xuống Hệ MBE mà không thông qua MFE.
                    Đôi lời trao đổi cùng các pác. Các pác xem hệ thống trên có không phù hợp hay sai sót chổ nào không !! mong góp ý !!!
                    Ví phỏng cuộc đời bằng phẳng cả
                    Anh hùng hào kiệt có hơn ai...

                    Comment


                    • #11
                      Thấy mấy Bro bàn luận về chủ đề này cũng rất hay.
                      Mình có một vần đề thề này Mong các Bro cho ý kiến
                      Công ty mình có 3 văn phòng . nằm 3 nơi khác nhau
                      Công ty dùng mail MDEAMon tại văn phòng chính domain ví dụ là
                      : abc.com.vn
                      Chi nhánh chính này Publish Mail này ra net de cho cac User co the check mail = Web Mail và PoP3 .
                      Nhưng một vấn đề là : Mail này Spam nhiều quá , Mà thắng IT trên văn phòng chính nó không chịu chặn . Mình là IT ở văn phòng chi nhánh nên không thể can thiệp vào đó dược.
                      Sếp mình bảo có cách nào để cài một cái Mail Server để Route mail từ văn phòng Chính về chi nhánh và sau đó phân bổ lại cho User và chặn Spam . vậy mình có thể cài Exchange đế Route Mail đc không và làm bằng cách nào.
                      Các Bro cho mình giải pháp ! thanks

                      Comment


                      • #12
                        Pác kiennhan là quangdt fai ko, cái situation pác đưa ra rất hay, mình chưa thử bao giờ nhưng tin là có giải pháp.

                        Còn với đại-ca-nhiễu, đúng là Scenario pác đưa ra nhiễu thật. Phức tạp, và có nhiều chỗ mình ko hiểu. Theo cách suy nghĩ thông thường của mình, thì 1 hệ thống mail cần secu thì họ có thể để 1 hoặc 2 Mail Relay Agent (SmartHost, ko cài Exchange) tại DMZ, còn FE và BE thường để cùng 1 subnet phía bên trong cho tiện. Thế nên khi đọc cái Scen của pác Nhiễu thấy khó hiểu quá.

                        Tại DMZ (outside) bác có SmartHost và FE, và 2 cái này hoạt động kiểu tương đối độc lập. Với các mail traffic vào ra, phải chăng lúc thì nó đi qua chỉ một SmartHost, hoặc FE, lúc thì đi qua cả 2 ? Và trong trường hợp nó đi qua chỉ SmartHost hoặc FE, thì để lọc được, bác fai bố trí các bộ lọc ở cả FE và SmartHost ? Tại sao mail client này thì đi qua cái này, cái khác thì đi qua cái khác ? Một trong các lợi ích của FE là nó unify cái namespace, và dấu đi sự biến động (về name, location, numbers ...) của các BEs đằng sau, vậy nếu khi Mail bên ngoài mà chỉ đi qua SmartHost (ko qua FE) thì liệu có đảm bảo được lợi ích trên ko ? ..v..v....

                        Đúng là Đại-Ca-Nhiễu, nhiễu quá. Ai Nhiễu-Shoot (troubleshoot) giùm ???
                        ... right here waiting for Nhieu-Shooter ...

                        Comment


                        • #13
                          hi meocon
                          Mình nghĩ là mô hình của daicanhieu thì cũng giống mô hình chung mà chúng ta đưa ra thôi, chẳng qua là cách diễn đạt của daicanhieu thì loằng ngoằng quá, đôi chỗ hơi khó hiểu ví như bản ghi MX trỏ về FMS thôi chứ trỏ về FE làm gì, trừ khi muốn sử dụng như là đường về dự phòng của thư từ Internet, thư trao đổi với bên ngoài Internet thì luôn phải đi qua FMS rồi, còn để access hệ thư thì cũng luôn phải thông qua FE. Mô hình thế thì cũng chẳng có gì phải troubleshoot nữa, chỉ có cái cách diễn đạt của daicanhieu đúng là làm nhiễu thật.

                          Về vụ của kiennhan thì theo mình cách giải quyết khó nếu theo đúng yêu cầu của bạn. Máy chủ Exchange hoàn toàn có thể cài đế Route Mail đc, tuy nhiên Mdaemon khó có thể làm được cái việc phân tách: cứ thư của user ở chi nhánh thì forward đến máy chủ Exchange ở chi nhánh (việc kiểu này có sendmail là làm tốt). Nếu bạn muốn thực hiện việc này thì chỉ có cách thay đổi lại cấu trúc hệ thống thư thôi và chắc chắn phải làm nhiều thứ trên HQ

                          Comment


                          • #14
                            Originally posted by meocondihoc View Post
                            Pác kiennhan là quangdt fai ko, cái situation pác đưa ra rất hay, mình chưa thử bao giờ nhưng tin là có giải pháp.

                            Còn với đại-ca-nhiễu, đúng là Scenario pác đưa ra nhiễu thật. Phức tạp, và có nhiều chỗ mình ko hiểu. Theo cách suy nghĩ thông thường của mình, thì 1 hệ thống mail cần secu thì họ có thể để 1 hoặc 2 Mail Relay Agent (SmartHost, ko cài Exchange) tại DMZ, còn FE và BE thường để cùng 1 subnet phía bên trong cho tiện. Thế nên khi đọc cái Scen của pác Nhiễu thấy khó hiểu quá.

                            Tại DMZ (outside) bác có SmartHost và FE, và 2 cái này hoạt động kiểu tương đối độc lập. Với các mail traffic vào ra, phải chăng lúc thì nó đi qua chỉ một SmartHost, hoặc FE, lúc thì đi qua cả 2 ? Và trong trường hợp nó đi qua chỉ SmartHost hoặc FE, thì để lọc được, bác fai bố trí các bộ lọc ở cả FE và SmartHost ? Tại sao mail client này thì đi qua cái này, cái khác thì đi qua cái khác ? Một trong các lợi ích của FE là nó unify cái namespace, và dấu đi sự biến động (về name, location, numbers ...) của các BEs đằng sau, vậy nếu khi Mail bên ngoài mà chỉ đi qua SmartHost (ko qua FE) thì liệu có đảm bảo được lợi ích trên ko ? ..v..v....

                            Đúng là Đại-Ca-Nhiễu, nhiễu quá. Ai Nhiễu-Shoot (troubleshoot) giùm ???
                            ... right here waiting for Nhieu-Shooter ...
                            Hi all
                            Có thể mấy pác nói đúng, cách diễn đạt của tui khá lằng ngoằng nên có khó hiểu khi đọc. Nhưng pác H2SO4 thực sự đã hiểu mô hình đấy_cám ơn pác đã giải thích. Mô hình này được đưa ra vào năm 2002 bởi một công ty giải pháp có tiếng trong thành phố và hiện đang được áp dụng. Mô hình trên không phải chỉ có hệ thống mail, mình chỉ nêu ra mô hình về mail để các pác bàn luận xem cái hay cái dở....

                            Như pác meocondihoc có nói, có thể pác chưa đọc kỹ. Cái mà pác gọi là Smarthost, đối với mô hình mình đưa ra cái đó chính là bộ lọc của hệ thống mail đấy, tất cả những mail vào/ra đều phải thông qua nó để "lọc"... Còn "Tại sao mail client này thì đi qua cái này, cái khác thì đi qua cái khác ?" cái này bạn xem ở đâu ??? Phải chăng là 2 trường hợp khi check/gửi mail bằng webmail và khi check/gửi băng MsO. Cái này thì đâu có gì khó hiểu : Khi check/gửi bằng MsO, client kết nối đến FE sử dụng chương trình MsO, và khi gửi ban phải gửi từ FE gửi đi (và phải qua bộ "lọc") ra ngoài. Còn nếu check/gửi bằng Webmail, bạn cũng phải kết nối tới FE, nhưng lúc này FE đóng vai trò là Mail client kết nối BE và chương trình MsO lúc này là giao diện web, và khi gửi đi phải gửi từ BE chứ.
                            Còn việc tại sao mình lại phải nói cái "Smarthost" đó cũng là một mail server, có thể mình nói thừa nên gây hiểu nhầm (việc bố trí 2 bộ lọc tại Smarthost và FE), nếu vậy thì khi message đến thì phải làm sao ? nếu không có chức năng SMTP (không cần POP3) nó không thể nhận mail và route cho BE được.

                            "Một trong các lợi ích của FE là nó unify cái namespace, và dấu đi sự biến động (về name, location, numbers ...) của các BEs đằng sau, vậy nếu khi Mail bên ngoài mà chỉ đi qua SmartHost (ko qua FE) thì liệu có đảm bảo được lợi ích trên ko ?" :::::::::::::: Chính xác !! cái này thì pác hiểu và nói đúng, đây là cái dở của hệ thống. Nhưng mình có thêm câu hỏi, liệu khi mail được route thông qua FE thì khi gửi ra ngoài, có che dấu được những cái mà pác nói hay không ? .....theo mình nghĩ là không. Mail sẽ luôn show tất tần tật về mọi thứ về tên server , IP, .... trên đường đi mà nó đi qua bắt đầu từ server gửi đi đến server nhận (cái này bạn thử show original của mail thì ắt biết). Vậy có cách giải quyết nào khác không ?

                            Pác nào có ý kiến hoàn thiện thêm về hệ thống này thì mong các pác góp ý !!!

                            P/S to meocondihoc : Mình nghĩ diển đàn là nơi để trao đổi bàn luận để mở mang kiến thức, bạn nên tôn trọng người cùng trao đổi với bạn, như thế mới tỏ ra mình là người lịch sự. Nick của người khác, bạn nên để trạng thái original của nó đừng thay đổi theo ý thích của mình dù với mục đích nào đi nữa. Mong được trao đổi thêm với pác.
                            Ví phỏng cuộc đời bằng phẳng cả
                            Anh hùng hào kiệt có hơn ai...

                            Comment


                            • #15
                              Originally posted by kiennhan View Post
                              Thấy mấy Bro bàn luận về chủ đề này cũng rất hay.
                              Mình có một vần đề thề này Mong các Bro cho ý kiến
                              Công ty mình có 3 văn phòng . nằm 3 nơi khác nhau
                              Công ty dùng mail MDEAMon tại văn phòng chính domain ví dụ là
                              : abc.com.vn
                              Chi nhánh chính này Publish Mail này ra net de cho cac User co the check mail = Web Mail và PoP3 .
                              Nhưng một vấn đề là : Mail này Spam nhiều quá , Mà thắng IT trên văn phòng chính nó không chịu chặn . Mình là IT ở văn phòng chi nhánh nên không thể can thiệp vào đó dược.
                              Sếp mình bảo có cách nào để cài một cái Mail Server để Route mail từ văn phòng Chính về chi nhánh và sau đó phân bổ lại cho User và chặn Spam . vậy mình có thể cài Exchange đế Route Mail đc không và làm bằng cách nào.
                              Các Bro cho mình giải pháp ! thanks

                              Theo mình thì không được bạn kiennhan ơi. Lý do là thế này :
                              Mail Exchange nhận mail OK, ban có thể làm điều đó ở chi nhánh được.

                              Còn mail MDaemon, mail server này cung cấp user rải rác ở 3 chi nhánh, chắc chắn là nó không thể route mail chỉ của một số user về 1 chi nhánh nào đó được. Ngoại trừ việc đẩy toàn bộ mail về (cái này H2SO4 đã nói).

                              Cái cuối cùng quan trọng nhất, khi nhận mail là server Mdaemon nhận mail và nhận luôn cả Spam. Việc chống Spam thực hiện ngay tại thời điểm mail được nhận về, nó sẽ kiểm tra và loại mail Spam lúc đó. Khi mail Spam đã được server nhận, cho dù có route được về Exchange thì mail spam đã nằm trong box mail của bạn rồi đó, không thể lọc được.

                              Giải pháp bạn nên thực hiện là yêu cầu bên chi nhánh chính chặn SPam. Ngay chính chương trinh Mdaemon có cơ chế log spam, Version 6.8 đã có Spam filter, V8 có SpamAssassin ở phiên bản Profesional, AntiSpam của Mdaemon cũng khá manh đó. Hoăc cài phần mềm chặn Spam , rất dể cài và xài, có thể xài thử SPAMfighter SMTP Anti Spam Server hoặc SPAMfighter Hosted spam filter for trial hoặc ra Bùi thị xuân mua đĩa crack.
                              Thân !
                              Ví phỏng cuộc đời bằng phẳng cả
                              Anh hùng hào kiệt có hơn ai...

                              Comment

                              Working...
                              X