At 03:29 PM 3/7/01 +0700, you wrote:
>On Wed, Mar 07, 2001 at 11:14:36AM +0700, Dani Matias wrote:
>> soal ip? hehe...saya kira hackers yg "bijaksana" pasti akan pake
>> public komputer :).
>
>Justru itu .. kalau menurut opini saya, misalkan ada system yang bisa
>memungkinkan cracker remain anonymous, mestinya system tsb. bisa kena
>sanksi, minimal ditutup. System yang dimaksud, isp, warnet, telkomnet
>instant :-) Serius, ada pepatah 'banyak jalan menuju roma', begitu
>juga dengan cracker. System yang mengijinkan cracker remain anonymous
>hanya menambah susah dunia yang sudah susah he..he..
mencegah user anonymous? menutup cybercafe? perpustakaan? isp?
justru disini anda sedang berkhayal! :)
>> ok, sekarang pengertian "timeout" anda dan saya kayaknya beda deh.
>
>It's *not* about pengertian :-) Coba lihat rfc1123 (kalau gak salah),
>ada banyak alasan mengapa MTA perlu kasih limitasi berupa timeout
>*per session*
lho gimana sih? udah jelas2 anda salah *ngerti* dgn yg dimaksud timeout itu.
anda menyangka kalau "kirim file/mail besar akan kena timeout". itu yang
saya bilang anda *salah mengerti* (baca:tidak tahu) apa yg dimaksud
*timeout* :).
timeout itu hanya terjadi jika *delay* antara satu data dengan data berikutnya
dianggap terlalu lama (melebihi batas timeout yg ditentukan). jadi bukan
sekedar
"session limit". coba deh anda pelajari data communication programming, anda
akan temukan istilah2 crc,framing error,overrun, dan juga *time out*.
btw, jangankan tiap session, tiap byte yg dikirim pun pasti ada timeoutnya.
itu udah prinsip data communication mas. ngga perlu liat rfc pun saya udah
tau :).
saya yakin rfc nya tidak salah, mungkin anda saja yg salah ngerti.
pernah chat di irc kan? pernah disconnect karena "ping timeout" ?
nah...itu contoh paling mudah untuk mengerti makna *timeout* yg sebenarnya :)
ot:
eh jadi keingetan nih. ngomong2 soal overrun, saya ingin meluruskan salah
kaprah istilah ini. anda berkali-kali bilang "buffer overrun" sebagai
penyebab abend (abnormal end) pada mdaemon. yg tepat untuk istilah ini
sebenarnya "buffer overflow". *overrun* itu terjadi jika data pada buffer
DCE tertimpa oleh data sender. penyebabnya biasanya karena DCE "telat"
mengirimkannya ke DTE (or vice versa). overrun hanya terjadi di layer
komunikasinya,
bukan di aplikasinya sehingga overrun tidak akan menyebabkan abend.
sedangkan *overflow* terjadi di aplikasi, penyebabnya sangat sederhana:
variable
penampung tidak cukup besar untuk menampung input data. ini akan menyebabkan
abend karena kelebihan data terebut akan "merusak" area memory yg lain.
hehe...maaf buat yg sudah tau, bagi yg belum tau mudah2an semakin "cerah"
:))).
>Session yang dimaksud: helo/ehlo, mail, rcpt, data, done
>Yang lazim dipakai adalah untuk receiver-smtp digunakan timeout yang
>sama untuk masing-masing session. sedangkan untuk sender-smtp
>biasanya bervariasi.
anda tau ada timeout di tiap2 session. but it's obvious anda tidak ngerti
apa yg dimaxud *timeout* itu :).
>Gini, kalau misalkan MDaemon menerapkan limitasi timeout seperti yang
>anda bilang, coba deh dirundingkan dengan developernya. Kalau anda
>takut dan developernya gak mau ganti. Ya sudah pakai saja MTA lain,
>it is a free world :-)
nah mulai nyalahin arvel lagi nih :). saya ngga akan tanya arvel ah,
takut diketawain...lol...lagian konsep timeout saya emang udah
sama koq sama mdaemon. ngapain juga pake komplain :).
jadi penasaran nih, definisi *timeout* anda sebenarnya apa sih? :))))
>> soal message size limit? oke lah, katakanlah limitnya 5MB atau berapapun.
>> tapi datanya udah kepalang masuk kan? terus terang, saya belum tahu
>> pasti mekanisme message limit itu, apakah bisa ketauan sebelum client
>> kirim data (spt pada protokol ftp) atau tidak.
>
>setiap byte yang dikirim oleh sender-smtp, akan dihitung oleh
>receiver-smtp. gitu, bisa jadi diterima dulu macam qmail. tapi itu
>tidak bisa lepas dari limitasi timeout.
ooo...jelas tidak bisa lepas dari limitasi timeout. saya setuju sekali.
tapi bukan timeout yg spt anda maxud lho :)
>> >> seorang yg baru belajar C language bisa membuat program dengan algoritma
>> >> sederhana sbb.:
>...
>> lah yg saya gambarkan itu bukan "cara apa saja". algo itu juga pake
>> telnet client mas,
>
>silakan baca tulisan anda sendiri :-) no comment he..he..
hehehe...sorry, mestinya saya ngga perlu kasih contoh algoritma segala yah :).
mungkin pseudo-code yg saya berikan itu terlalu c-like, jadi agak susah
dicerna ya. apa perlu saya berikan pseudo-code cobol-like? LOL j/k
>> (ini bedanya pertanyaan retorik dan pertanyaan murni :)).
>
>FYI, justru makna retorik yang saya maksud. Buat apa? kita sedang
>diskusi. Bukan menang-menangan.
wah statement anda malah menunjukkan bahwa anda merasa ini kompetisi
untuk "menang2an" :). bagi saya ini tetap merupakan diskusi yg sehat.
tapi kalau ada pemahaman yg salah atas suatu konsep (macem timeout itu),
*wajib* diluruskan. kesian member milis ini yg masih rookie...ntar ikut2an
salah lagi :)
keyboard boleh panas...monitor mesti tetap dingin....setuju? :)))
>> jadi kalau saya connect ke mailserver pake ftp atau irc client ngga
>> bisa dibedakan dengan mail client gitu? hmmm...terus terang aja,
>> technically hal ini meragukan.
>
>Oh boy lagi .. :-) Bukan metode yang perlu diragukan, tapi
>efektivitasnya. Yang bisa dilakukan adalah mencoba tahu itu rumah ada
>anjing atau tidak dengan pijit bel, kalau begitu bel kita pijit (send
>telnet negotiation) anjingnya menggonggong (telnet client kasih
>response) berarti itu telnet client.
oh boy juga.... :)
koq jadi lari ke efektivitas sih. saya cuman heran kenapa cuman telnet
yg bisa dikenal oleh mailserver, *bagi saya* secara teknis ini meragukan
karena
client yg lainpun yg sama2 pake tcp connection bisa melakukan "kontak"
dengan mailserver.
>Dari logika di atas saja mudah dimengerti bahwa metode itu banyak
>kelemahannya, gimana kalau anjingnya diam dan tidak menggonggong? :-)
>Itulah kenapa disebut useless. Kalau anda mengharapkan metode yang
>lebih canggih lagi, berarti anda pemimpi :-P
ngga apa2 disebut pemimpi juga :). paling ngga saya tau persis bagaimana
mekanisme 1 byte data dikirim dan diterima :))).
>Ok. Ini yang terakhir dari saya untuk thread ini.
>
>Sampai jumpa di lain kisah.
thx God....LOL
>PS. please check statement anda. profile, don't speculate :-)
wow...saya ngga pernah "speculate". semua statement saya dibuktikan
dengan fakta *yang saya lakukan sendiri*. jadi bukan sekedar "kata orang".
bahkan semua pembuktian yg saya lakukan saya share juga dengan anda.
-DM-
--
--MDaemon-L----------------------------------------------------------
Milis ini untuk Diskusi antar pengguna MDaemon Mail Server.
Untuk menghubungi moderator/List Owner double click link dibawah ini:
<mailto:[EMAIL PROTECTED]>
Untuk Unsubscribe, double click link dibawah ini langsung kirim
<mailto:[EMAIL PROTECTED]>
Untuk Subscribe, double click link dibawah ini langsung kirim
<mailto:[EMAIL PROTECTED]>
--POWERED BY MDAEMON!------------------------------------------------
Anda terdaftar di List ini dg alamat : [email protected]
