Hallo Syafril, Friday, December 10, 2004, 6:54:10 PM, you wrote:
> Benar, dan kalau Anda sering memperhatikan log, membaca header dll, maka > terlihat bahwa spam messages (bahkan skr ini juga worm virus) sebagian besar > masuk melalui MX backup bukan melalui primary MX; krn spammer tahu betul bahwa > pada umumnya user lebih memberi perhatian kepada primary server ketimbang > secondary, bahkan dalam banyak kejadian MX backup berada diluar kendali mereka > shg pasti tidak akan seketat setting di primary server. Sebentar, saya butuh konfirmasi.. Bila Primary MX pakai MD+MDAV+SA, lalu Secondary MX pakai mail server lain yg tidak ada AV/CF/SA, apakah saat mail yang tadinya ditampung di Secondary MX, lalu dikirim ke Primary MX, apakah langsung bypass mechanism MDAV/CF/SA ?? Bila tidak, kenapa harus khawatir problem diatas ?? Ada yang terlewat oleh saya ?? Mohon petunjuk locianpwee Bila iya, koq bisa demikian ?? Khan vulnerability-nya tinggi ?? > Saya pernah debat panjang dg John Navas (itu lho pemilik Navas Groups) di > Milis > [EMAIL PROTECTED] ttg perlu tidaknya MX backup ini. > Saya ringkas saja saja isi yg saya sampaikan di diskusi itu spy tdk > kepanjangan > : > 1. Dg hanya single MX maka saya sebenarnya virtually memiliki unlimited MX > backup. > Semua MTA yg mengikuti standard Internet (RFC compliance) wajib untuk retry > to send non fatal first attempt delivery, RFC merekomendasikan retry > dilakukan selama 5 hari, jadi asalkan server atau link kita tidak down > selama > 5 hari berturut-turut maka kejadian message failed diterima akan kecil. Dari sisi bisnis: * User tidak mau/perlu tahu apakah MTA yang mereka pakai sudah RFC-compliant atau belum * Management tidak mau risiko kehilangan e-mail (atau mail delayed) hanya karena ada problem server/link dan tidak ada MX Backup (disini time is real money, misalnya di industri kami, bila ada keterlambatan informasi via e-mail, lalu line produksi berhenti 1 jam saja itu sudah berarti sekian ratus dollar terbuang) * Management dan IT sendiri cenderung feel safer kalau segala sesuatunya ada backup, termasuk diantaranya Mail Server <g> > 2. Dg single MX maka saya menghindari adanya thundering heart attack. > Karena semua deffered mail ada di masing-2x MX sender, dan setiap MX sender > memiliki masing-2x schedule of delivery maka saat server saya up kembali > tidak akan mengalami burst mail dalam jumlah besar dalam satu selang waktu > yg > pendek, melainkan akan terdistribusi merata dalam selang waktu yg lebih > panjang shg akan terhandle oleh server saya (tidak menyebabkan server saya > crash). Betul, ini bisa dimengerti karena kami pernah alami sendiri, bandwidth penuh justru karena 'serangan' kiriman e-mail dari MX backup secara bertubi2.. tapi masih bisa di-handle, dengan mematikan SMTP MX Backup lalu transfer secara remote/fisik <g> dari MX Backup ke Local Queue-nya MX Primary. > 3. Dg single MX maka server saya tidak akan menerima beban berlebihan jika > sender mensupport Smartspooling atau MX piggy backing. > Hal ini sdh Anda rasakan sendiri, semua mail yg dikirim secara > smartspooling > akan diterima sbg single session oleh server saya, itu pasti. Nah kalo ini lain cerita, berarti MX piggy backing hanya akan jalan pada single MX ?? Bukankah secara persentase umum di dunia, Multiple MX lebih banyak dijumpai ketimbang single MX ?? BTW bahkan altn.com-pun punya 3 MX lho: altn.com MX preference = 20, mail exchanger = c3po.altn.com altn.com MX preference = 30, mail exchanger = smtp.helpdesk.altn.com altn.com MX preference = 10, mail exchanger = r2d2.altn.com > Saya sering kali omongkan di milis ini, jangan letakkan MDaemon dibelakang any > firewall sebagus apapun firewall yg Anda miliki; jangan terlalu banyak > "gembok" > dipasang di depan MDaemon. MDaemon sudah dilengkapi dengan fasilitas utk > menjaga > dirinya sendiri, tambahan firewall (apalagi jika dibikin oleh orang yg > kurang ngerti email) hanya bikin susah diri sendiri saja. Bisa berakibat > responsenya salah (mestinya diresponse Error 430 I am busy pleas retry later > eh > ditulis Error 530 sorry out of buffer), memblock pipeline connection atau > rejection message on smtp level because out of size, viruses, spam, mailbox > full > (mis. saja sontoloyonya smtp_fix_up nya PIX yg melakukan kegoblogan fatal > kayak > gini). Dalam kasus tertentu, kita tidak bisa menghindari kebutuhan pemasangan firewall, misalnya dalam penggunaan ComNet, karena keluarannya Ethernet, mereka memberikan 1 IP public untuk interfacing dengan mereka di Jakarta dan 16 IP public pada block yang berbeda untuk range IP kami.. berarti mau tidak mau, kita harus menggunakan sejenis firewall/router bukan ?? > Sekali lagi saya ulangi, membuang semua firewall yg ada didepan MDaemon adalah > tindakan yg paling bijaksana, Howgh! Uf uf, saudara saya kulit merah Old Syafril telah menggali kapak perang untuk pemasangan firewall di depan MDaemon.. rasa2nya kita perlu mengisap pipa perdamaian dulu ke empat penjuru angin.. Howgh! Salam, Hian -- --[MDaemon-L]------------------------------------------------ Milis ini untuk Diskusi antar pengguna MDaemon Mail Server. Mohon tidak posting dalam format HTML! Arsip : <http://mdaemon-l.dutaint.com> Moderator : <mailto:[EMAIL PROTECTED]> Henti Langgan : <mailto:[EMAIL PROTECTED]> Berlangganan : <mailto:[EMAIL PROTECTED]> Versi Terakhir : MD 7.2.1, LD 2.1.0, WA 3.0.2, MDAV 2.2.7, MDGW 1.0.7 Anda terdaftar di List ini dg alamat : [email protected]
