Sebelumnya, dengan menjawab pertanyaan ini, saya bukannya
memplokamirkan diri sebagai pakar MTA lho :P atau malah saya yang
ke-GR-an ya .. hehehehe..
Satu lagi, pertanyaan di bawah, tidak mungkin bisa dijawab singkat
:-)
On Fri, Mar 17, 2000 at 06:18:05PM -0700, Irwan Hadi wrote:
> bagaimana dengan speednya dari exim dan sendmail, saya penasaran dengan exim.
Pada prinsipnya, paralel remote deliveries akan lebih efisien
dibandingkan dengan serial remote deliveries. Pertama, pengiriman
secara paralel mengatasi network latency, kedua, mengatasi smtp
latency (ie. perlu response 'ok' sebelum lanjut). Kelihatannya,
sendmail baru mendukung paralel remote delivery mechanism (belum
ngecek sendiri).
> Terus bagaimana efektifitas keduanya, mis. qmail ditulis di 486 ram 16 M,
> bisa handle 100 ribu surat outbound.
Eh.. itu maksudnya menggunakan mekanisme remote queue (ie. via qmqp)
bukan standar smtp (juga bukan qmtp). Setahu saya, belum ada MTA yang
punya mekanisme beginian kecuali qmail (setahu saya = sendmail,
zmailer, smail, exim, mmdf dan postfix). Ada 'nullmailer' tapi boleh
dibilang ini termasuk golongan qmail.
> nah bagaimana dengan postfix , exim + sendmail , perlu hardware sebagaimana.
Nggak bisa jawab :-) Tergantung kondisi/kebutuhan kayaknya. Yang
jelas, untuk irit-mengirit, yang modular akan menang. BTW, soal 3x
lebih cepat, itu kan dalam kondisi 'angan-angan', boleh dibilang,
ceteris paribus (hehe.. ini yang angan-angan, maksudnya dalam kondisi
sama), postfix 3x lebih cepat. Anyway, soal mail bukan soal
angan-angan kan, seperti yang Oom DJB bilang, 'profile don't
speculate' :-)
> terus bagaimana dengan handle inbound, mending yang mana ? (kenapa di
> mail.com / iname.com inbound pakai sendmail 8.9.3 outbound pakai 8.9.1),
Seperti asisten saya, Wietse Venema, bilang :P 'enough is enough'.
Serious bug(s) di sendmail berkenaan dengan mekanisme penerimaan
email. So, tidak ada alasan, mengganti outgoing smtp server dengan
yang baru. Barangkali saja orang-orang iname menganggap input untuk
outgoing MTA mereka selalu trusted. Wah, ini spekulasi saya doang :-)
> jadi di test, mis qmail suru send dengan concurency remote 120 atau mungkin
> 400 send ke exim, lalu ke postfix dan sendmail.
Postfix 'menang'. Anyway, tanda petik amat penting. Dengan jumlah
incoming mail semakin banyak, katakanlah jauh lebih banyak dari
outgoing mail, performance postfix bisa kelihatan buruk.
> terus penanganan bounce bagaimana ?. seandainya ada dDOS dengan email, jadi
> bounce ke mail server itu, nah siapa yang lebih tahan terhadap serangan
> "bounce" email ini ?
Dengan 'serangan' ini, qmail harus lebih waspada :-), setidaknya
karena qmail tidak memiliki kemampuan menolak bogus envelope
recipient secara instan (saat transaksi smtp). Perhatikan email
bounce 'user unknown' dari qmail selalu berasal dari server tempat
qmail berada (Hi! this is ... dst) :-)
> Terus lagi, bagaimana dengan pembukaan koneksi, mis. dibuka 1000 koneksi
> saat bersamaan, nah siapa lebih dulu keok (saya kadang pakai
> smtp.telkom.net suka refuse connection dia, mungkin sudah maximum kali ya
> koneksi yang boleh dibuka)
Wuih .. kenapa harus sampai 1000 ??? kalau smtp client yang membuka
1000 koneksi paralel ke tempat saya langsung saya blok :-) Hehehe..
nggak perlu diblok ding, kan udah ke-blok sendiri :-) Misalkan, kita
set remote concurrency sampai 1000, dan kebetulan, dalam saat
bersamaan mengirimkan ke 1 host, dan host tersebut tewas, jadi sampai
1200 detik, 1000 qmail-remote linglung di memory dan email lain yang
seharusnya bisa segera dikirim harus ngantri? ;-(
Kalau qmail-smtpd dijalankan dari tcpserver, default, hanya akan
menerima 40 koneksi secara bersamaan. Tapi kalau dijalankan via
inetd, ya nggak ada batasannya (?). Susahnya, kalau sendmail
dijalankan via inetd, dan kecelakaan, orang bilang salah sendmail,
tapi kalau qmail dijalankan via inetd, dan kecelakaan, orang bilang
salah inetd ;-(
Salam,
P.Y. Adi Prasaja
PS. untuk menguji siapa yang paling handal dengan koneksi paralel,
tidak bisa diuji dari satu komputer. Kan email itu proses baca/tulis
disk-nya hebat sekali, jadi, dalam kasus saya, bottle neck justru di
komputer saya, bukan MTA-nya, apapun MTA-nya.
--------------------------------------------------------------------------
Utk berhenti langganan, kirim email ke [EMAIL PROTECTED]
Informasi arsip di http://www.linux.or.id/milis.php3
Pengelola dapat dihubungi lewat [EMAIL PROTECTED]
