P. 1
SMTP, POP3,IMAP,MIME

SMTP, POP3,IMAP,MIME

|Views: 2,923|Likes:
Published by dayutzzzzz
pengertian SMTP
pengertian SMTP

More info:

Published by: dayutzzzzz on Jun 01, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

07/21/2013

pdf

text

original

POP3

POP3 (Post Office Protocol version 3) adalah protokol yang digunakan untuk mengambil surat elektronik (email) dari server email. Protokol ini erat hubungannya dengan protokol SMTP dimana protokol SMTP berguna untuk mengirim surat elektronik dari komputer pengirim ke server. Protokol POP3 dibuat karena desain dari sistem surat elektronik yang mengharuskan adanya server surat elektronik yang menampung surat eletronik untuk sementara sampai surat elektronik tersebut diambil oleh penerima yang berhak. Kehadiran server surat elektronik ini disebabkan kenyataan hanya sebagian kecil dari komputer penerima surat elektronik yang terus-menerus melakukan koneksi ke jaringan internet. Protokol ini dispesifikasikan pada RFC 1939.

Saat ini di kalangan masyarakat pengguna internet, POP bukanlah suatu barang baru. Dengan menggunakan POP, seseorang mendapat kemudahan untuk mendapatkan mail miliknya dari sebuah mail server, tanpa perlu koneksi yang lama dengan internet yang tentu saja memakan biaya. Dibawah ini, penulis akan sedikit menerangkan tentang cara kerja dari POP. Pada tulisan ini, akan banyak ditemui istilah client dan server. Client dan server merupakan bagian dari arsitektur yang banyak digunakan pada implementasi layanan internet. Arsitektur ini biasa disebut sebagai client/server architecture. Pengertian client pada pembahasan tentang POP3 ini adalah pihak yang menggunakan layanan POP3 dan server adalah pihak yang menyediakan layanannya

Apakah POP itu ?
POP atau Post Office Protocol, sesuai dengan namanya merupakan protokol yang digunakan untuk pengelolaan mail. POP yang sekarang lebih umum dikenal dengan POP3 (POP - Version 3), dimaksudkan untuk mengizinkan client untuk mengakses secara dinamis mail yang masih ada di POP3 server. POP3 menawarkan pada user untuk meninggalkan mail-nya di POP3 server, dan mengambil mail-nya tersebut dari sejumlah sistem sebarang. Untuk mengambil mail dengan menggunakan POP3 dari suatu client, banyak pilihan yang dapat digunakan seperti Sun Microsystem Inc.'s Mailtool, QualComm Inc.'s Eudora, Netscape Comm. Corp.'s Netscape Mail dan Microsoft Corp.'s Outlook Express. POP3 tidak dimaksudkan untuk menyediakan operasi manipulasi mail yang ada di server secara luas. Pada POP3, mail diambil dari server dan kemudian dihapus (bisa

juga tidak dihapus). Segala sesuatu tentang protokol POP3 ini dibahas dalam RFC (Request For Comment) 1725. Protokol yang lebih tinggi dan lebih kompleks, yaitu IMAP4, dibahas dalam RFC 1730.

Mode POP3
Ada dua jenis mode pada POP3 yaitu mode offline dan mode inline. Pada mode offline, POP3 mengambil dan kemudian menghapus mail yang tersimpan dari server. POP3 bekerja dengan baik pada mode ini, karena terutama memang didisain untuk berlaku sebagai sebuah sistem mail yang memiliki sifat "store-and-forward". Server, pada mode offline, berlaku seperti sebuah tempat penampungan yang menyimpan mail sampai user memintanya. Pada mode inline, POP3 akan mengambil mail dari server tanpa menghapus mail yang sudah diambil tersebut. Mode ini lebih disukai oleh user yang sering berpindah tempat (nomadic user) karena memungkinkan mereka untuk melihat mail yang sama dari tempat atau komputer yang berbeda. Akan tetapi untuk nomadic user yang selalu bekerja dan bepergian dengan selalu membawa notebook, dan tetap menginginkan agar mail miliknya yang ada di server tidak dihapus, tentu saja menginginkan agar setiap kali mengambil mail tidak semua mail yang akan terambil, tapi hanya mail yang belum pernah dia lihat saja yang akan diambil. Keinginan user seperti ini dapat dipenuhi dengan menggunakan informasi pada client yang memungkinkan untuk memberi tanda mail yang sudah pernah dilihat. Setiap client layanan POP3 yang mendukung mode inline akan menyimpan informasi ini dalam sebuah file. Pada user yang menggunakan Netscape Mail, file yang menyimpan informasi ini adalah file popstate.dat, yang biasanya terdapat di /Program Files/Netscape/Users/Mail. File tersebut memberi tahu mail yang mana saja yang sudah diambil sehingga tidak perlu diambil lagi. Jika file ini dihapus maka tentu saja pada pengambilan mail berikutnya semua mail akan terambil. Contoh isi file popstate.dat untuk seorang user yang memiliki login misalnya ‘wandi’ di POP3 server students.itb.ac.id adalah sebagai berikut : # Netscape POP3 State File # This is a generated file! Do not edit. *students.itb.ac.id wandi k c67ee091087ed814337b4cb31e0d488c k 8541822a98e890b88d8299d034993f61 k 652e17a1c984e610e4e55257c07b6ff4 Pada file ini kode dibelakang huruf k merupakan unique-id. Unique-id ini secara unik mengidentifikasi sebuah mail dalam maildrop sehingga masing-masing mail memiliki unique-id yang berbeda. Jika misalnya mail kita yang berada di komputer

lokal sudah terhapus sedangkan kita ingin membacanya lagi, maka sebelum kita mengambil maildrop dari server, file popstate.dat ini harus dihapus terlebih dahulu. Apabila kita belum menghapus file tersebut maka akan ada pesan : “ no new messages on server “, yang diberikan oleh Netscape Mail. Untuk pemakai Eudora, file yang menyimpan informasi ini adalah file lmos.dat, sedangkan untuk pengguna Outlook Express biasanya menggunakan file pop3uidl.dat.

Operasi Dasar POP3
Pada awalnya, server memulai layanan POP3 dengan mendengarkan permintaan pada TCP port 110. Ketika sebuah client meminta layanan tersebut, maka terjadilah hubungan TCP dengan server. Pada saat hubungan dimulai, POP3 server mengirim greeting (kata pembuka). Setelah itu client akan memberikan command (perintah) ke server dan POP3 server akan memberikan response (jawaban) sampai hubungan ditutup atau digagalkan. Perlu diingat bahwa user tidak memasukkan perintah ini, tapi software dari client-lah yang mengirim perintah ini ke server. Perintah-perintah di POP3 terdiri dari sebuah keyword yang tidak case sensitive (tidak mempersoalkan huruf kapital ataupun tidak), yang dapat diikuti oleh satu atau lebih argument. Keyword dan argument masing-masing dipisahkan oleh karakter SPACE (spasi). Keyword terdiri dari tiga atau empat karakter, sedangkan tiap argument dapat mencapai 40 karakter. Jawaban di POP3 terdiri dari sebuah indikator status dan sebuah keyword yang dapat diikuti oleh informasi tambahan. Ada dua indikator status : positif (“+OK”) dan negatif (“-ERR”). Server harus memberikan jawaban +OK dan -ERR dalam huruf kapital. Pada perintah tertentu, server akan memberikan jawaban yang terdiri dari beberapa baris. Sebuah sesi hubungan POP3 dibangun melalui tiga tahap, yaitu tahap authorization, transaction dan update. Sekali hubungan TCP dimulai dan POP3 server telah mengirimkan greeting , maka sesi hubungan telah memasuki tahap authorization. Pada tahap ini client mengirim nama dan password user ke server untuk membuktian keaslian user tersebut agar dapat mengambil mail-nya. Ketika client telah berhasil membuktikan identitas dirinya, server akan memperoleh informasi yang berhubungan dengan mail yang dimiliki client tersebut, dan sesi kini memasuki tahap transaction. Pada tahap inilah terjadi proses penerimaan mail, penandaan mail untuk penghapusan, pembatalan penandaan untuk penghapusan, penampilan statistik mail atau perincian identitas mail. Pada saat client telah memberikan perintah quit untuk mengakhiri hubungan, maka sesi memasuki tahap update. Pada tahap inilah server akan menjalankan semua perintah yang diperoleh selama tahap transaction dan menutup sesi dan selanjutnya hubungan TCP ditutup. Sebuah server harus menjawab perintah yang tidak dikenal, tidak diimplementasi, atau tidak sesuai dengan sintaksis dengan indikator status negatif. Server juga harus memberikan indikator status negatif, jika ada client yang memberikan perintah tidak pada tahap yang seharusnya. Tidak ada metoda umum yang dapat digunakan oleh client

untuk membedakan antara server yang tidak mengimplementasikan perintah tambahan dengan server yang tidak dapat atau tidak bersedia memproses perintah tambahan tersebut. Sebuah POP3 server mungkin memiliki autologout timer untuk client yang sedang tidak aktif dalam rentang waktu tertentu. Timer seperti ini harus paling sedikit memiliki rentang waktu 10 menit. Jika sebuah server menerima sebarang perintah dari client didalam rentang waktu tersebut, maka hal ini sudah cukup untuk me-reset autologout timer tersebut. Ketika waktu rentang timer sudah habis, tanpa ada aktivitas dari client maka sesi hubungan tidak memasuki tahap UPDATE. Server akan menutup hubungan TCP tanpa menghapus mail atau mengirim jawaban ke client. Semua pesan yang disampaikan selama sesi hubungan POP3 harus disesuaikan dengan standar format dari Internet text messages. Internet text messages ini, secara terperinci dibahas dalam RFC 822. Tabel 1. dibawah ini memperlihatkan perintahperintah pada POP3 berikut tahap tempat perintah tersebut digunakan. Perintah USER <user name> PASS <password> QUIT STAT TRANSACTION LIST [msg] RETR [msg] DELE [msg] NOOP RSET QUIT Tabel 1 Perintah POP3 yang terdapat pada tabel diatas adalah merupakan perintah-perintah dasar yang dilayani oleh semua POP3 server dengan implementasi minimal. Selain perintah diatas masih ada lagi beberapa perintah tambahan yang mengizinkan sebuah POP3 client untuk lebih bebas dalam penanganan mail miliknya pada saat berhubungan dengan POP3 server. Perintah tambahan beserta tahap yang dibenarkan untuk penggunaan perintah tersebut dapat dilihat pada tabel 2. dibawah ini : Tahap AUTHORIZATION

UPDATE

Perintah APOP <name> <digest> TOP [msg] n UIDL [msg]

Tahap AUTHORIZATION TRANSACTION

Tabel 2 POP3 mengerti semua perintah yang ditunjukkan oleh kedua tabel diatas, tapi POP3 hanya mengetahui tiga jawaban : “+OK " , “-ERR " dan daftar jawaban yang diakhiri dengan “.” (indikator akhir dari suatu daftar jawaban). Perlu diingat bahwa kecuali untuk perintah STAT, LIST, dan UIDL, jawaban yang diberikan oleh POP3 server pada setiap perintah adalah hanya “+OK” dan “-ERR”.

Cara Setting Email Pop3 dan SMTP dari cPanel
Email pop3 dan SMTP adalah sistem email yang memungkinkan anda untuk dapat mengirim dan menerima email dari dan ke program/software/client/situs favorit anda. Pada umumnya kebanyakan orang menggunakan program microsoft outlook dan free email fetch dari yahoo. Syarat menggunakannya adalah anda sudah mensetting email account di cPanel anda dan memastikan bahwa account email tersebut sudah dibuat serta user name dan password tidak salah. Bagi yang awam : cpanel adalah sistem konfigurasi web hosting untuk subdomain maupun domain. Di internet tersedia hosting cPanel baik yang gratis maupun yang bayar. Untuk mencari yang gratis anda dapat mencarinya di situs ini. Dengan cpanel anda dapat membuat email account dengan jumlah yang telah ditetapkan oleh reseller hosting. Bisa 0 sampai tidak terbatas. Sedangkan space email disesuaikan dari space hosting yang anda miliki. Pada umumnya setting dari cPanel adalah sebagi berikut ini : - Email Address : contoh ---> anda@domainanda.com - Incoming Mail (POP3, IMAP or HTTP) server : mail.doaminanda.com - Outgoing (SMTP) server : mail.domainanda.com - Account Name : anda@domainanda.com - Password : password yang telah anda buat sebelumnya Keterangan : - Apabila ditanya port, maka gunakan port pop3 dan smtp standar. - Biasanya anda dapat memilih untuk meninggalkan copy pesan yang sudah diambil atau dihapus saja di space email hosting anda. - Seting email pop3 dan smtp dari sistem atau provider lain biasanya berbeda.

SMTP (Simple Mail Transfer Protocol) merupakan salah satu protokol yang umum digunakan untuk pengiriman surat elektronik di Internet. Protokol ini dipergunakan untuk mengirimkan data dari komputer pengirim surat elektronik ke server surat elektronik penerima. Protokol ini timbul karena desain sistem surat elektronik yang mengharuskan adanya server surat elektronik yang menampung sementara sampai surat elektronik diambil oleh penerima yang berhak.

Post Office Protocol - Version 3
1. Pengenalan Pada beberapa jenis node yang lebih kecil di Internet ini sering tidak praktis untuk mempertahankan sistem pesan transportasi (MTS). Untuk Misalnya, workstation mungkin tidak memiliki sumber daya yang cukup (siklus, ruang disk) untuk izin server SMTP [RFC821] dan asosiasi sistem pengiriman mail lokal untuk disimpan penduduk dan terus menerus berjalan. Demikian pula, mungkin mahal (atau tidak mungkin) untuk menyimpan komputer pribadi interkoneksi ke jaringan IP-gaya lama jumlah waktu (node tersebut tidak memiliki sumber daya yang dikenal sebagai "Konektivitas"). Meskipun demikian, seringkali sangat berguna untuk dapat mengelola mail node yang lebih kecil ini, dan mereka sering mendukung user agent (UA) untuk membantu tugas-tugas penanganan mail. Untuk mengatasi masalah ini, node yang dapat mendukung sebuah entitas MTS menawarkan layanan maildrop tersebut kurang diberkahi node. Post Office Protocol - Version 3 (POP3) dimaksudkan untuk izin workstation untuk secara dinamis mengakses maildrop di server tuan rumah dengan cara yang bermanfaat. Biasanya, ini berarti bahwa protokol POP3 digunakan untuk memungkinkan workstation untuk mengambil mail yang server memegang untuk itu. POP3 tidak dimaksudkan untuk menyediakan operasi manipulasi ekstensif mail pada server, biasanya, surat-download dan kemudian dihapus. A lebih maju (dan kompleks) protokol, IMAP4, dibahas dalam [RFC1730].

Untuk sisa memo ini, istilah "host klien" mengacu pada tuan rumah memanfaatkan layanan POP3, sedangkan host "istilah server" mengacu pada sebuah host yang menawarkan layanan POP3.

2. Sebuah Penyimpangan Pendek
memo ini tidak menentukan bagaimana sebuah host klien mail masuk ke dalam sistem transportasi, walaupun metode yang konsisten dengan filosofi memo ini disajikan di sini: Ketika user agent pada client host ingin memasukkan pesan ke dalam sistem transportasi, itu membangun koneksi SMTP untuk yang relay host dan mengirimkan semua email itu. Relay host ini bisa dapat, tetapi tidak perlu, host server POP3 untuk host klien. Dari Tentu saja, tuan rumah relay harus menerima email untuk pengiriman ke sewenangwenang alamat penerima, fungsi yang tidak diperlukan dari semua SMTP server.

3. Operasi Dasar
Awalnya, host server memulai layanan POP3 dengan mendengarkan pada TCP port 110. Ketika sebuah host klien ingin menggunakan layanan ini, itu membentuk sebuah koneksi TCP dengan server host. Ketika sambungan dibuat, POP3 server mengirim salam. Itu client dan server POP3 kemudian pertukaran perintah dan tanggapan (Masing-masing) sampai sambungan ditutup atau dibatalkan. Perintah di POP3 terdiri dari sebuah kata kunci kasus-sensitif, mungkin diikuti oleh satu atau lebih argumen. Semua perintah yang diakhiri dengan CRLF pasangan. Kata kunci dan argumen terdiri dari ASCII yang dapat dicetak karakter. Kata kunci dan argumen masing-masing dipisahkan oleh satu SPACE karakter. Kata kunci tiga atau empat karakter. Masing-masing mungkin argumen sampai 40 karakter. Tanggapan di POP3 terdiri dari sebuah indikator status dan kata kunci mungkin diikuti oleh informasi tambahan. Semua tanggapan yang diakhiri oleh sepasang CRLF. Mungkin tanggapan hingga 512 karakter panjang, termasuk CRLF terminating. Saat ini ada dua status

indikator: positif ("+ OK") dan negatif ("-ERR"). Server HARUS mengirim "+ OK" dan "-ERR" dalam huruf besar. Tanggapan untuk perintah tertentu multi-line. Dalam kasus ini, yang jelas ditunjukkan di bawah ini, setelah mengirimkan baris pertama respon dan sebuah CRLF, setiap garis tambahan akan dikirim, masing-masing diakhiri oleh sepasang CRLF. Ketika semua lini respon telah terkirim, sebuah baris terakhir dikirim, yang terdiri dari oktet terminasi (kode desimal 046, "") dan sepasang CRLF.. Jika baris dari garis-multi respon diawali dengan octet terminasi, garis adalah "byte-boneka" oleh pra-pending octet terminasi dengan garis respon. Oleh karena itu respon multi-line diakhiri dengan lima oktet "CRLF.CRLF". Ketika memeriksa jawaban multi-line, cek klien untuk melihat apakah baris dimulai dengan pemutusan oktet. Jika begitu dan jika oktet selain CRLF ikuti, octet pertama dari garis (yang pemutusan oktet) adalah dilucuti. Jika begitu dan jika CRLF segera mengikuti karakter pengakhiran, maka respon dari POP server berakhir dan baris yang berisi "CRLF". tidak dianggap bagian dari respons multi-line. Sesi POP3 kemajuan melalui sejumlah negara selama nya seumur hidup. Setelah koneksi TCP telah dibuka dan POP3 server telah mengirimkan salam, sesi yang memasuki KUASA negara. Dalam keadaan ini, klien harus mengidentifikasi dirinya ke POP3 server. Sekali klien telah berhasil melakukan ini, server memperoleh sumber daya yang terkait dengan maildrop klien, dan sesi memasuki negara TRANSAKSI. Dalam keadaan ini, klien permintaan tindakan pada bagian dari server POP3. Ketika klien memiliki mengeluarkan perintah QUIT, sesi memasuki negara UPDATE. Di negara ini, server POP3 rilis setiap sumber daya yang diperoleh selama TRANSAKSI negara dan mengatakan selamat tinggal. Sambungan TCP kemudian tertutup. Server HARUS menanggapi belum diakui, terimplementasi, atau sintaktis tidak valid perintah dengan menanggapi dengan status negatif indikator. Server HARUS merespon perintah yang dikeluarkan ketika sesi adalah dalam keadaan yang salah dengan menanggapi dengan status negatif indikator. Tidak ada metode umum untuk klien untuk membedakan antara server yang tidak mengimplementasikan perintah opsional dan server yang tidak mau atau tidak dapat memproses perintah.

Server POP3 MUNGKIN mengatur timer autologout tidak aktif. Seperti timer HARUS durasi minimal 10 menit. Penerimaan perintah apapun dari klien selama selang yang seharusnya cukup untuk me-reset autologout timer. Ketika timer berakhir, sesi TIDAK masukkan negara UPDATE - server harus menutup koneksi TCP tanpa menghapus pesan atau mengirim setiap respon kepada klien.

4. Negara KUASA
Setelah koneksi TCP telah dibuka oleh klien POP3, POP3 masalah server garis satu ucapan. Hal ini dapat pun positif respon. Sebuah contoh mungkin: S: + OK POP3 server siap Sesi POP3 sekarang di negara KUASA. Klien harus sekarang mengidentifikasi dan autentikasi dirinya ke server POP3. Dua kemungkinan mekanisme untuk melakukan hal ini dijelaskan dalam dokumen ini, para PENGGUNA dan kombinasi perintah PASS dan perintah APOP. Kedua mekanisme yang dijelaskan nanti dalam dokumen ini. Tambahan mekanisme otentikasi dijelaskan dalam [RFC1734]. Sementara ada tidak ada satu mekanisme otentikasi yang diperlukan dari semua POP3 server, server POP3 harus mendukung setidaknya satu saja mekanisme otentikasi. Setelah POP3 server telah ditentukan melalui penggunaan apapun otentikasi klien perintah yang harus diberikan akses ke maildrop yang sesuai, server POP3 kemudian mengakuisisi eksklusifmengunci akses maildrop, karena diperlukan untuk mencegah pesan dari yang diubah atau dihapus sebelum sesi memasuki negara UPDATE. Jika kunci itu berhasil diperoleh, POP3 server akan meresponnya dengan indikator status positif. Sesi POP3 sekarang memasuki TRANSAKSI negara, tanpa pesan yang ditandai sebagai dihapus. Jika maildrop tidak dapat dibuka karena beberapa alasan (misalnya, kunci dapat tidak diperoleh, klien ditolak akses ke yang tepat maildrop, atau maildrop tidak dapat diuraikan), POP3 server merespon dengan indikator status negatif. (Jika kunci diperoleh tetapi POP3 server bermaksud untuk menjawab dengan indikator status negatif, POP3 server harus melepaskan kunci sebelum menolak perintah.) Setelah kembali indikator status negatif, server dapat menutup sambungan. Jika server tidak menutup sambungan, klien

baik dapat mengeluarkan perintah otentikasi baru dan mulai lagi, atau klien dapat mengeluarkan perintah QUIT. Setelah POP3 server telah membuka maildrop, itu memberikan pesannomor untuk setiap pesan, dan catatan ukuran setiap pesan dalam oktet. Pesan pertama dalam maildrop diberikan sebuah pesan-jumlah "1", yang kedua ditugaskan "2", dan seterusnya, sehingga pesan n dalam maildrop adalah diberi pesan-sejumlah "n". Dalam perintah POP3 dan tanggapan, semua pesan-jumlah dan ukuran pesan disajikan dalam base-10 (dgn kata lain, desimal). Berikut adalah ringkasan untuk perintah QUIT bila digunakan dalam KUASA negara: QUIT Argumen: tidak ada Pembatasan: tidak ada Kemungkinan Responses: + OK Contoh: C: QUIT S: POP3 server Dewey OK + sign off

5. TRANSAKSI Negara
Sekali klien telah berhasil mengidentifikasi dirinya ke server POP3 dan POP3 server telah mengunci dan membuka maildrop yang sesuai, sesi POP3 sekarang di negara TRANSAKSI. klien sekarang dapat masalah semua perintah POP3 berikut berulang kali. Setelah masing-masing perintah, masalah server POP3 tanggapan. Akhirnya, klien masalah perintah QUIT dan sesi POP3 memasuki negara UPDATE.

Berikut adalah perintah-perintah POP3 berlaku di negara TRANSAKSI: STAT Argumen: tidak ada Pembatasan: hanya dapat diberikan dalam keadaan TRANSAKSI Diskusi: Masalah-masalah server POP3 respon positif dengan garis berisi informasi untuk maildrop tersebut. Baris ini disebut "drop daftar" untuk maildrop itu. Untuk menyederhanakan parsing, semua server POP3 adalah dibutuhkan untuk menggunakan format tertentu untuk daftar drop. Itu respon positif terdiri dari "+ OK" diikuti oleh tunggal ruang, jumlah pesan dalam maildrop, tunggal ruang, dan ukuran maildrop dalam oktet. memo ini membuat persyaratan tidak pada apa yang berikut ukuran maildrop. implementasi Minimal hanya harus mengakhiri bahwa garis respon dengan sepasang CRLF. Lebih lanjut implementasi mungkin termasuk informasi lainnya. CATATAN: Ini SANGAT memo menghambat implementasi dari penyediaan informasi tambahan dalam menu drop listing. Lainnya, opsional, fasilitas dibahas kemudian yang mengizinkan klien untuk mengurai pesan di maildrop tersebut. Perhatikan bahwa pesan yang ditandai sebagai dihapus tidak dihitung dalam total baik. Kemungkinan Responses: + OK nn mm Contoh: C: STAT S: + OK 2 320

DAFTAR [msg]

Argumen: pesan-nomor (opsional), yang, jika ada, mungkin TIDAK mengacu pada pesan ditandai sebagai dihapus Pembatasan: hanya dapat diberikan dalam keadaan TRANSAKSI Diskusi: Jika argumen itu diberikan dan isu-isu sebuah POP3 server respon positif dengan garis yang berisi informasi untuk pesan itu. Baris ini disebut sebagai "scan daftar" untuk pesan itu. Jika tidak ada argumen yang diberikan dan isu-isu sebuah POP3 server tanggapan positif, maka respons yang diberikan adalah multi-line. Setelah awal + OK, untuk setiap pesan dalam maildrop tersebut, POP3 server akan meresponnya dengan baris berisi informasi untuk pesan itu. Baris ini juga disebut "Memindai daftar" untuk pesan itu. Jika tidak ada pesan dalam maildrop, maka POP3 server merespon memindai tanpa daftar - itu mengeluarkan respon positif diikuti oleh baris yang berisi octet terminasi dan CRLF pasangan. Untuk menyederhanakan parsing, semua server POP3 adalah dibutuhkan untuk menggunakan format tertentu untuk scan listing. A memindai daftar terdiri dari nomor-pesan dari pesan, diikuti dengan spasi tunggal dan ukuran tepat pesan di oktet. Metode untuk menghitung tepat ukuran pesan yang dijelaskan dalam "Pesan Format" bagian bawah. memo ini tidak membuat persyaratan pada apa mengikuti ukuran pesan di scan listing. Minimal implementasi yang hanya harus mengakhiri garis respon dengan sepasang CRLF. Implementasi mungkin lebih maju termasuk informasi lainnya, seperti parsing dari pesan. CATATAN: Ini SANGAT memo menghambat implementasi dari penyediaan informasi tambahan di scan listing. Lainnya, opsional, fasilitas dibahas kemudian yang mengizinkan klien untuk mengurai pesan di maildrop tersebut.

Perhatikan bahwa pesan yang ditandai sebagai dihapus tidak terdaftar. Kemungkinan Responses: + OK scan listing berikut -ERR tidak ada pesan seperti Contoh: C: DAFTAR S: + OK 2 pesan (320 oktet) S: 1 120 S: 2 200 S:. ... C: DAFTAR 2 S: + OK 2 200 ... C: DAFTAR 3 S:-ERR ada pesan tersebut, hanya 2 pesan di maildrop RETR msg Argumen: pesan-nomor (wajib) yang TIDAK bisa merujuk ke pesan ditandai sebagai dihapus Pembatasan: hanya dapat diberikan dalam keadaan TRANSAKSI Diskusi: Jika masalah server POP3 respon positif, maka jawaban yang diberikan adalah multi-line. Setelah awal + OK, POP3 server mengirim pesan yang sesuai dengan yang diberikan pesan-nomor, berhati-hati untuk byte-hal pemutusan kontrak kerja karakter (seperti halnya dengan semua tanggapan multi-line). Kemungkinan Responses: pesan + OK berikut -ERR tidak ada pesan seperti

Contoh: C: RETR 1 S: + OK 120 octets S: POP3 server mengirimkan pesan <the seluruh sini> S:.

DELE msg Argumen: pesan-nomor (wajib) yang TIDAK bisa merujuk ke pesan ditandai sebagai dihapus Pembatasan: hanya dapat diberikan dalam keadaan TRANSAKSI Diskusi: Tanda POP3 server pesan sebagai dihapus. Setiap masa depan referensi ke nomor-pesan yang terkait dengan pesan dalam perintah POP3 menghasilkan kesalahan. Server POP3 tidak tidak benar-benar menghapus pesan sampai sesi POP3 memasuki negara UPDATE. Kemungkinan Responses: pesan + OK dihapus -ERR tidak ada pesan seperti Contoh: C: DELE 1 S: pesan OK + 1 dihapus ... C: 2 DELE S:-ERR message 2 sudah dihapus

Noop Argumen: tidak ada Pembatasan: hanya dapat diberikan dalam keadaan TRANSAKSI

Diskusi: Server POP3 tidak apa-apa, itu hanya balasan dengan respon positif. Kemungkinan Responses: + OK Contoh: C: noop S: + OK RSET Argumen: tidak ada Pembatasan: hanya dapat diberikan dalam keadaan TRANSAKSI Diskusi: Jika ada pesan telah ditandai sebagai dihapus oleh POP3 server, mereka tak bertanda. POP3 server kemudian balasan dengan respon positif. Kemungkinan Responses: + OK Contoh: C: RSET S: + OK maildrop memiliki 2 pesan (320 oktet)

6. Negara UPDATE
Ketika isu klien perintah QUIT dari negara TRANSAKSI, sesi POP3 memasuki negara UPDATE. (Perhatikan bahwa jika klien masalah perintah QUIT dari negara KUASA, POP3 sesi berakhir tetapi TIDAK masukkan negara UPDATE.) Jika sesi berakhir untuk beberapa alasan lain selain yang dikeluarkan klienPerintah QUIT, maka sesi POP3 TIDAK UPDATE masukkan negara dan HARUS tidak menghapus pesan dari maildrop tersebut.

QUIT Argumen: tidak ada Pembatasan: tidak ada Diskusi: POP3 server akan menghapus semua pesan yang ditandai sebagai dihapus dari maildrop dan balasan untuk status ini operasi. Jika ada kesalahan, seperti sumber daya kekurangan, ditemui ketika menghapus pesan, yang maildrop dapat mengakibatkan memiliki beberapa atau kosong dari pesan ditandai sebagai dihapus dihapus. Dalam hal tidak dapat server menghapus pesan yang tidak ditandai sebagai dihapus. Apakah penghapusan berhasil atau tidak, server kemudian melepaskan setiap kunci yang eksklusif-akses yang maildrop dan menutup koneksi TCP. Kemungkinan Responses: + OK -ERR beberapa pesan dihapus tidak dihapus Contoh: C: QUIT S: POP3 server Dewey OK + sign off (maildrop kosong) ... C: QUIT S: POP3 server Dewey OK + penandatanganan lepas (2 pesan kiri) ...

7. Perintah POP3 Opsional
Perintah-perintah POP3 yang dibahas di atas harus didukung oleh semua minimal implementasi dari server POP3. Perintah POP3 opsional dijelaskan di bawah ini memungkinkan klien POP3 kebebasan yang lebih besar dalam menangani pesan, sambil menjaga sederhana POP3 implementasi server. CATATAN: Ini SANGAT memo mendorong implementasi untuk mendukung perintah ini sebagai pengganti mengembangkan drop ditambah dan scan

listing. Singkatnya, filsafat memo ini adalah untuk menempatkan intelijen di bagian klien POP3 dan bukan POP3 server. TOP msg n Argumen: pesan-nomor (wajib) yang TIDAK bisa merujuk ke ke pesan ditandai sebagai dihapus, dan sejumlah non-negatif garis (diperlukan) Pembatasan: hanya dapat diberikan dalam keadaan TRANSAKSI Diskusi: Jika masalah server POP3 respon positif, maka jawaban yang diberikan adalah multi-line. Setelah awal + OK, POP3 server mengirim header pesan, kosong memisahkan baris header dari tubuh, dan kemudian jumlah baris tubuh pesan ditunjukkan itu, menjadi berhati-hati untuk byte-hal karakter terminasi (seperti semua tanggapan multi-line). Catatan bahwa jika jumlah baris yang diminta oleh POP3 klien lebih besar dari dari jumlah baris dalam tubuh, maka POP3 server mengirimkan seluruh pesan. Kemungkinan Responses: atas + OK pesan berikut -ERR tidak ada pesan seperti Contoh: C: TOP 1 10 S: + OK S: <POP3 server mengirim header dari pesan, sebuah baris kosong, dan 10 baris pertama dari tubuh> pesan S:. ... C: TOP 100 3 S:-ERR ada pesan seperti

UIDL [msg] Argumen: pesan-nomor (opsional), yang, jika ada, mungkin TIDAK mengacu pada pesan ditandai sebagai dihapus Pembatasan: hanya dapat diberikan di negara TRANSAKSI. Diskusi: Jika argumen itu diberikan dan isu-isu server POP3 positif respon dengan garis berisi informasi untuk pesan itu. Baris ini disebut daftar "unik-id" untuk pesan itu. Jika tidak ada argumen yang diberikan dan isu-isu server POP3 positif tanggapan, maka jawaban yang diberikan adalah multi-line. Setelah + Awal OK, untuk setiap pesan dalam maildrop tersebut, server POP3 meresponnya dengan garis berisi informasi untuk pesan itu. Baris ini disebut daftar "unik-id" untuk pesan itu. Untuk menyederhanakan parsing, semua server POP3 diharuskan untuk menggunakan format tertentu untuk daftar unik-id. Sebuah unik-id daftar terdiri dari nomor-pesan dari pesan, diikuti dengan spasi tunggal dan unik id-pesan. Tidak ada informasi yang mengikuti-id unik dalam daftar yang unik-id. The-id unik dari sebuah pesan server ditentukan sewenang-wenangstring, terdiri dari satu 70 karakter dalam kisaran 0x21 untuk 0x7E, yang unik mengidentifikasi pesan dalam maildrop dan yang berlangsung di seluruh sesi. Ini kegigihan diperlukan bahkan jika sesi berakhir tanpa memasuki negara UPDATE. Server tidak boleh menggunakan kembali unik-id di maildrop yang diberikan, selama entitas menggunakan-id ada yang unik. Perhatikan bahwa pesan yang ditandai sebagai dihapus tidak terdaftar. Meskipun umumnya lebih baik untuk implementasi server untuk menyimpan sewenang-wenang ditugaskan unik-id di maildrop tersebut, spesifikasi ini dimaksudkan untuk izin-id unik untuk dihitung sebagai hash pesan. Klien harus mampu

untuk menangani situasi di mana dua salinan identik dari pesan dalam sebuah maildrop memiliki unik yang sama-id. Kemungkinan Responses: + Daftar-id unik OK berikut -ERR tidak ada pesan seperti Contoh: C: UIDL S: + OK S: 1 whqtswO00WBw418f9t5JxYwZ S: 2 QhdPYR: 00WBw1Ph7x7 S:. ... C: 2 UIDL S: + OK 2 QhdPYR: 00WBw1Ph7x7 ... C: 3 UIDL S:-ERR ada pesan tersebut, hanya 2 pesan di maildrop

PENGGUNA nama Argumen: string mengidentifikasi kotak surat (diperlukan), yang merupakan signifikansi HANYA ke server Pembatasan: hanya dapat diberikan dalam keadaan KUASA setelah POP3 salam atau setelah PENGGUNA gagal atau perintah PASS Diskusi: Untuk otentikasi menggunakan PENGGUNA dan perintah PASS kombinasi, klien harus terlebih dahulu masalah PENGGUNA perintah. Jika POP3 server akan meresponnya dengan positif Status indikator ("+ OK"), maka klien dapat mengeluarkan baik perintah PASS untuk melengkapi otentikasi, atau perintah QUIT untuk mengakhiri sesi POP3. Jika POP3 server menjawab dengan indikator status negatif ("-ERR") pada perintah USER, maka klien mungkin baik mengeluarkan perintah otentikasi baru atau dapat mengeluarkan QUIT yang perintah.

Server mungkin kembali respon positif walaupun tidak ada kotak surat tersebut ada. Server mungkin kembali negatif respon jika kotak surat ada, tetapi tidak mengizinkan plaintext sandi otentikasi. Kemungkinan Responses: + OK nama kotak surat yang valid -ERR pernah mendengar nama kotak surat Contoh: C: USER frated S:-ERR maaf, tidak ada kotak untuk frated sini ... C: USER mrose S: + OK mrose adalah frood hoopy nyata

PASS string Argumen: server / sandi kotak-spesifik (diperlukan) Pembatasan: hanya dapat diberikan dalam keadaan segera KUASA setelah perintah USER berhasil Diskusi: Ketika klien masalah perintah PASS, POP3 server menggunakan pasangan argumen dari perintah USER dan PASS untuk menentukan apakah klien harus diberikan akses ke sesuai maildrop. Karena perintah PASS memiliki tepat satu argumen, sebuah POP3 server mungkin memperlakukan ruang dalam argumen sebagai bagian dari sandi, bukan sebagai pemisah argumen. Kemungkinan Responses: + OK maildrop terkunci dan siap -ERR invalid password -Tidak mampu untuk mengunci ERR maildrop

Contoh: C: USER mrose S: + OK mrose adalah frood hoopy nyata C: PASS rahasia S:-ERR maildrop sudah dikunci ... C: USER mrose S: + OK mrose adalah frood hoopy nyata C: PASS rahasia S: + OK maildrop mrose telah 2 pesan (320 oktet) nama APOP mencerna Argumen: string mengidentifikasi kotak surat dan string MD5 digest (Keduanya diperlukan) Pembatasan: hanya dapat diberikan dalam keadaan KUASA setelah POP3 salam atau setelah PENGGUNA gagal atau perintah PASS Diskusi: Biasanya, setiap sesi POP3 dimulai dengan USER / PASS pertukaran. Hal ini menyebabkan server / user-id spesifik password dikirim dalam jelas pada jaringan. Untuk sesekali menggunakan POP3, ini tidak mungkin memperkenalkan cukup besar risiko. Namun, banyak implementasi klien terhubung ke POP3 POP3 server secara teratur - untuk memeriksa baru mail. Selanjutnya interval inisiasi sesi mungkin pada urutan lima menit. Oleh karena itu, risiko password menangkap sangat ditingkatkan. Sebuah metode alternatif otentikasi yang diperlukan menyediakan otentikasi untuk kedua asal dan replay perlindungan, tapi yang tidak melibatkan pengiriman sandi di jelas melalui jaringan. Perintah APOP memberikan fungsi ini. POP3 server yang mengimplementasikan perintah APOP akan termasuk timestamp di banner nya salam. Sintaks dari timestamp sesuai dengan `msg-id 'di [RFC822], dan HARUS berbeda setiap kali masalah server POP3 banner

salam. Sebagai contoh, pada implementasi UNIX di mana proses terpisah UNIX digunakan untuk setiap contoh dari suatu POP3 server, sintaks dari cap waktu itu mungkin: <process-ID.clock@hostname> mana `proses-ID 'adalah nilai desimal dari proses itu PID, jam adalah nilai desimal dari jam sistem, dan nama host adalah domain penuh-kualifikasi-nama yang sesuai ke host dimana server POP3 berjalan. Klien POP3 membuat catatan timestamp ini, dan kemudian masalah perintah APOP. Parameter Nama `'memiliki identik semantik terhadap parameter `'nama PENGGUNA perintah. The `mencerna 'parameter dihitung dengan menerapkan algoritma MD5 [RFC1321] untuk string yang terdiri dari timestamp (termasuk sudut-kurung) yang diikuti oleh berbagi rahasia. Berbagi rahasia ini adalah string yang hanya diketahui oleh POP3 client dan server. Great perawatan harus diambil untuk mencegah pengungkapan rahasia yang tidak sah, seperti pengetahuan rahasia akan memungkinkan setiap entitas untuk berhasil menyamar sebagai user bernama. Para `mencerna 'parameter sendiri adalah sebuah nilai 16-oktet yang dikirim dalam heksadesimal format, dengan menggunakan huruf kecil karakter ASCII. Ketika server POP3 menerima perintah APOP, itu memverifikasi ringkasan disediakan. Jika mencerna benar, POP3 masalah server respon positif, dan sesi POP3 memasuki negara TRANSAKSI. Jika tidak, negatif respon dikeluarkan dan sesi POP3 tetap di KUASA negara. Perhatikan bahwa panjang meningkat rahasia bersama, sehingga tidak kesulitan itu berasal. Dengan demikian, bersama rahasia harus string panjang (jauh lebih lama dari contoh 8-karakter yang ditunjukkan di bawah).

Kemungkinan Responses: + OK maildrop terkunci dan siap -ERR izin ditolak

Contoh: S: + OK POP3 server siap <1896,697170952 @ dbc.mtview.ca.us> C: APOP c4c9334bac560ecc979e58001b3e22fb mrose S: + OK maildrop memiliki 1 pesan (369 oktet) Dalam contoh ini, berbagi rahasia adalah string `tanstaaf '. Oleh karena itu, algoritma MD5 diterapkan pada string <1896,697170952 @ dbc.mtview.ca.us> tanstaaf yang menghasilkan nilai digest c4c9334bac560ecc979e58001b3e22fb

8. Scaling dan Pertimbangan Operasional
Sejak beberapa fitur opsional yang dijelaskan di atas yang ditambahkan ke protokol POP3, pengalaman yang telah terakumulasi dalam menggunakan mereka di besarskala operasi kantor pos komersial di mana sebagian besar pengguna tidak terkait satu sama lain. Dalam situasi ini dan lainnya, pengguna dan vendor klien POP3 telah menemukan bahwa kombinasi penggunaan tersebut UIDL perintah dan tidak mengeluarkan perintah DELE dapat menyediakan lemah versi maildrop "sebagai repositori semi-permanen" fungsionalitas biasanya terkait dengan IMAP. Tentu saja kemampuan lain IMAP, seperti pemungutan suara sambungan yang ada untuk yang baru tiba pesan dan mendukung beberapa folder di server, tidak hadir di POP3. Bila fasilitas ini digunakan dengan cara ini oleh pengguna biasa, ada kecenderungan untuk membaca pesan yang sudah menumpuk di server tanpa terikat. Ini jelas merupakan pola perilaku yang tidak diinginkan dari sudut pandang operator server. Situasi ini diperparah oleh fakta bahwa kemampuan terbatas POP3 tidak mengijinkan efisien penanganan maildrops yang memiliki ratusan atau ribuan pesan. Oleh karena itu, dianjurkan bahwa operator skala besar multiserver pengguna, khususnya yang di mana hanya akses pengguna ke maildrop adalah melalui POP3, pertimbangkan pilihan seperti:

* Pengenaan kuota penyimpanan maildrop per-user atau sejenisnya. Kerugian ke pilihan ini adalah bahwa akumulasi pesan mungkin mengakibatkan ketidakmampuan pengguna untuk menerima yang baru ke dalam maildrop. Situs yang memilih opsi ini harus yakin untuk menginformasikan pengguna kelelahan mendatang atau saat kuota, mungkin dengan memasukkan pesan yang sesuai ke maildrop pengguna. * Paksa kebijakan situs mengenai retensi mail pada server. Situs bebas untuk menetapkan kebijakan lokal mengenai penyimpanan dan retensi pesan di server, baik membaca dan belum dibaca. Untuk Misalnya, situs mungkin menghapus pesan yang belum dibaca dari server setelah 60 hari dan membaca pesan menghapus setelah 7 hari. Seperti pesan penghapusan berada di luar lingkup protokol POP3 dan tidak dianggap sebagai pelanggaran protokol. Server operator menegakkan kebijakan penghapusan pesan harus mengambil perawatan untuk membuat semua pengguna menyadari kebijakan yang berlaku. Klien tidak harus mengasumsikan bahwa kebijakan situs akan mengotomatisasi pesan penghapusan, dan harus terus secara eksplisit menghapus pesan menggunakan perintah DELE saat yang tepat. Perlu dicatat bahwa menegakkan pesan kebijakan penghapusan situs mungkin membingungkan bagi komunitas pengguna, karena klien mereka POP3 dapat berisi opsi-opsi konfigurasi untuk meninggalkan mail pada server yang sebenarnya tidak akan didukung oleh server. Satu kasus khusus dari suatu kebijakan situs adalah bahwa pesan hanya dapat download sekali dari server, dan akan dihapus setelah ini telah dicapai. Ini dapat diterapkan di server POP3 perangkat lunak dengan mekanisme sebagai berikut: "setelah login POP3 oleh klien yang berakhir dengan QUIT, hapus semua pesan download selama sesi dengan perintah RETR ". Hal ini penting untuk tidak menghapus pesan dalam hal terjadi pemutusan hubungan abnormal (Yaitu, jika tidak ada QUIT diterima dari klien) karena klien mungkin tidak berhasil diterima atau menyimpan pesan. Server menerapkan kebijakan download-dan-menghapus juga dapat membantu menonaktifkan atau membatasi perintah TOP opsional, karena dapat digunakan

sebagai mekanisme alternatif untuk men-download seluruh pesan.

9. Perintah POP3 Ringkasan
Perintah POP3 Minimal: PENGGUNA nama berlaku di negara KUASA PASS string QUIT STAT berlaku di negara TRANSAKSI DAFTAR [msg] RETR msg DELE msg Noop RSET QUIT Perintah POP3 Opsional: APOP nama mencerna berlaku di negara KUASA TOP msg n berlaku di negara TRANSAKSI UIDL [msg] POP3 Balasan: + OK -ERR Perhatikan bahwa dengan pengecualian dari STAT, LIST, dan perintah UIDL, jawaban yang diberikan oleh server POP3 untuk perintah apa pun adalah penting hanya untuk "+ OK" dan "-ERR". Setiap teks yang terjadi setelah jawaban ini mungkin diabaikan oleh klien.

10. Contoh POP3 Sesi
S: <wait untuk koneksi pada port TCP 110> C: connection> <open S: + OK POP3 server siap <1896,697170952 @ dbc.mtview.ca.us> C: APOP c4c9334bac560ecc979e58001b3e22fb mrose

S: + OK maildrop mrose telah 2 pesan (320 oktet) C: STAT S: + OK 2 320 C: DAFTAR S: + OK 2 pesan (320 oktet) S: 1 120 S: 2 200 S:. C: RETR 1 S: + OK 120 octets S: POP3 server <the 1> mengirim pesan S:. C: DELE 1 S: OK pesan dihapus + 1 C: RETR 2 S: + OK 200 octets S: POP3 server <the 2> mengirim pesan S:. C: 2 DELE S: pesan OK + 2 dihapus C: QUIT S: POP3 server Dewey OK + sign off (maildrop kosong) C: connection> <close S: <wait untuk connection> berikutnya

11. Format Pesan
Semua pesan dikirim selama sesi POP3 diasumsikan agar sesuai standar untuk format pesan teks Internet [] RFC822. Penting untuk dicatat bahwa jumlah octet untuk pesan pada server host mungkin berbeda dari jumlah yang ditugaskan oktet pesan tersebut karena konvensi lokal untuk menunjuk akhir-of-line. Biasanya, selama negara KUASA dari sesi POP3, server POP3 dapat menghitung ukuran setiap pesan di oktet ketika membuka maildrop. Sebagai contoh, jika POP3 server host internal merupakan end-of-line sebagai karakter tunggal, maka POP3 server hanya menghitung setiap kemunculan karakter ini dalam pesan sebagai dua oktet. Catatan bahwa garis-garis dalam pesan yang dimulai dengan kebutuhan octet terminasi tidak (dan tidak harus) dihitung dua kali, karena klien akan POP3 menghapus semua karakter byte-boneka pemutusan kontrak kerja ketika menerima multi-line respon.

12. Pertimbangan Keamanan
Hal ini menduga bahwa penggunaan perintah APOP menyediakan Asal identifikasi dan perlindungan replay untuk sesi POP3. Dengan demikian, POP3 server yang mengimplementasikan baik PASS dan APOP perintah tidak harus memungkinkan kedua metode akses untuk pengguna tertentu; yaitu, untuk nama kotak surat yang diberikan, baik PENGGUNA / perintah PASS urutan atau perintah APOP diperbolehkan, tapi tidak keduanya. Selanjutnya, perhatikan bahwa panjang meningkat rahasia bersama, sehingga tidak kesulitan itu berasal. Server yang jawaban-ERR untuk perintah USER memberikan potensi penyerang petunjuk tentang nama-nama yang berlaku. Penggunaan perintah PASS mengirim password di atas jelas jaringan. Penggunaan RETR dan perintah TOP mengirimkan mail dalam jelas atas jaringan. Jika tidak, masalah keamanan tidak dibahas dalam memo ini.

SIMPLE MAIL TRANSFER PROTOCOL
1. 1. INTRODUCTION PENDAHULUAN
The objective of Simple Mail Transfer Protocol (SMTP) is to transfer Tujuan dari Simple Mail Transfer Protocol (SMTP) adalah untuk mentransfer mail reliably and efficiently. mail handal dan efisien. SMTP is independent of the particular transmission subsystem and SMTP adalah independen dari subsistem transmisi tertentu dan requires only a reliable ordered data stream channel. hanya membutuhkan saluran yang dapat diandalkan memerintahkan data stream. Appendices A, Lampiran A, B, C, and D describe the use of SMTP with various transport services. B, C, dan D menggambarkan penggunaan SMTP dengan berbagai layanan transportasi. A Glossary provides the definitions of terms as used in this Sebuah Istilah memberikan definisi istilah yang digunakan dalam document. dokumen. An important feature of SMTP is its capability to relay mail across Sebuah fitur penting dari SMTP adalah kemampuan untuk relay mail di transport service environments. layanan transportasi lingkungan. A transport service provides an Sebuah layanan transportasi memberikan interprocess communication environment (IPCE). komunikasi interprocess lingkungan (IPCE). An IPCE may cover one Sebuah IPCE dapat mencakup satu network, several networks, or a subset of a network. jaringan, beberapa jaringan, atau bagian dari jaringan. It is important Penting to realize that transport systems (or IPCEs) are not one-to-one with untuk menyadari bahwa sistem transportasi (atau IPCEs) tidak satu-ke-satu dengan networks. jaringan. A process can communicate directly with another process Sebuah proses dapat berkomunikasi secara langsung dengan proses lain through any mutually known IPCE. melalui saling IPCE dikenal. Mail is an application or use of Mail adalah aplikasi atau menggunakan interprocess communication. interprocess komunikasi. Mail can be communicated between Mail dapat dikomunikasikan antara processes in different IPCEs by relaying through a process connected proses dalam IPCEs berbeda dengan menyampaikan melalui proses yang terhubung to two (or more) IPCEs. untuk dua (atau lebih) IPCEs. More specifically, mail can be relayed Lebih khusus, mail dapat disampaikan between hosts on different transport systems by a host on both antara host pada sistem transportasi yang berbeda dengan host di kedua transport systems. sistem transportasi.

2. 2. THE SMTP MODEL MODEL SMTP
SMTP didasarkan pada model berikut ini komunikasi: sebagai hasil permintaan pengguna mail, pengirim-SMTP menetapkan dua arah saluran transmisi ke penerimaSMTP. The receiver-SMTP Penerima-SMTP dapat berupa tujuan akhir atau menengah. SMTP SMTP perintah dihasilkan oleh pengirim-SMTP dan dikirim ke receiver-SMTP. SMTP balasan dikirim dari penerima-SMTP ke pengirim-SMTP dalam menanggapi perintah. Setelah saluran transmisi didirikan, SMTP-pengirim mengirimkan MAIL menunjukkan perintah pengirim surat. Jika penerima SMTPbisa menerima email akan meresponnya dengan jawaban OK. SMTP-pengirim kemudian mengirimkan perintah RCPT mengidentifikasi penerima surat. Jika SMTP-penerima dapat menerima mail untuk bahwa penerima akan meresponnya dengan OK jawaban; jika tidak, akan meresponnya dengan jawaban menolak bahwa penerima (Tapi tidak seluruh transaksi mail). SMTP-pengirim dan SMTP-penerima dapat menegosiasikan beberapa penerima. Ketika penerima terminating telah menegosiasikan SMTP-pengirim mengirimkan data surat, terminating dengan urutan khusus. Jika penerima SMTP-berhasil memproses data mail akan meresponnya dengan jawaban OK. Dialog sengaja kunci-langkah, satu-di-waktu-. ------------------------------------------------------------- ------------------------------------------------- ----------+----------+ +----------+ +----------+ +----------+ +------+ | | | | +------+ | | | | | User |<-->| | SMTP | | | Pengguna |<-->| | SMTP | | +------+ | Sender- |Commands/Replies| Receiver-| +------+ | Pengirim Perintah-| / Jawaban | Receiver-| +------+ | SMTP |<-------------->| SMTP | +------+ +------+ | SMTP SMTP |<------------->| | +------+ | File |<-->| | and Mail | |<-->| File | | File | |<-->| dan |<-->| Mail | File | |System| | | | | |System| | Sistem | | | | | | Sistem | +------+ +----------+ +----------+ +------+ +------+ +----------+ +----------+ +------+ Sender-Receiver-SMTP SMTP Model untuk Gunakan SMTP Figure 1 Gambar 1

------------------------------------------------------------- ------------------------------------------------- ----------SMTP menyediakan mekanisme untuk transmisi surat; langsung pengguna dari host pengirim ke host penerima pengguna ketika Dua host tersambung ke layanan transportasi sama atau melalui satu atau lebih relay SMTP-server ketika sumber dan host tujuan tidak tersambung ke layanan transportasi yang sama. Untuk dapat memberikan kemampuan relay SMTP-server harus disertakan dengan nama host tujuan akhir serta nama kotak surat tujuan. Argumen untuk perintah MAIL adalah jalan-reverse, yang menentukan yang surat dari. Argumen untuk perintah RCPT adalah maju-jalan, yang menentukan siapa surat adalah. Maju-jalan sedangkan jalan-reverse adalah rute kembali (yang dapat digunakan untuk kembali pesan ke pengirim ketika kesalahan terjadi dengan pesan yang disampaikan). Ketika pesan yang sama dikirimkan ke beberapa penerima SMTP mendorong transmisi hanya satu salinan data untuk semua penerima pada host tujuan yang sama. perintah mail dan balasan memiliki sintaks yang kaku. Balasan juga memiliki kode numerik. Dalam berikut, contoh yang menggunakan sebenarnya muncul perintah dan balasan. Melengkapi daftar perintah dan balasan muncul di Bagian 4 pada spesifikasi. Perintah dan balasan yang tidak sensitif huruf. Artinya, perintah atau mungkin balasan kata huruf besar, huruf kecil, atau campuran dari atas dan kasus yang lebih rendah.Catatan bahwa ini tidak benar nama kotak surat pengguna. Untuk beberapa host nama pengguna kasus sensitif, dan implementasi SMTP harus mengambil kasus untuk melestarikan kasus nama pengguna saat mereka muncul dalam kotak surat argumen. Nama Host yang tidak sensitif huruf. dan balasan yang terdiri dari karakter dari ASCII character set [1]. Ketika jasa transportasi memberikan byte 8-bit (octet) transmission channel, masing-masing karakter 7-bit ditransmisikan benar dibenarkan dalam oktet dengan bit orde yang tinggi dihapus menjadi nol.

Ketika menentukan bentuk umum dari perintah atau membalas, argumen (Atau simbol khusus) akan dilambangkan dengan suatu variabel meta-linguistik (atau constant), misalnya, "<string>" atau "<reverse-path>". Di sini sudut kurung menunjukkan ini adalah variabel meta-linguistik. Namun, beberapa argumen menggunakan kurung sudut harfiah. Untuk contoh, sebuah reverse-path yang sebenarnya ditutupi dalam kurung sudut, yaitu, (yang kurung sudut sebenarnya ditransmisikan dalam perintah atau membalas). 3. 3. SMTP ATAS PROSEDUR Bagian ini menyajikan prosedur yang digunakan pada SMTP dalam beberapa bagian. Pertama datang prosedur mail dasar didefinisikan sebagai transaksi mail. Berikut ini adalah deskripsi dari mail forwarding, memverifikasi kotak nama dan memperluas mailing list, pengiriman ke terminal sebagai pengganti atau dalam kombinasi dengan kotak surat, dan pembukaan dan penutupan bursa. Pada akhir bagian ini adalah komentar pada relaying, catatan pada mail domain, dan diskusi tentang perubahan peran. Sepanjang bagian ini adalah contoh-contoh perintah dan urutan jawaban parsial. 3.1. 3.1. MAIL Ada tiga langkah untuk transaksi SMTP. The transaction Transaksi dimulai dengan perintah MAIL yang memberikan pengirim identifikasi. Serangkaian satu atau lebih perintah RCPT berikut memberikan informasi penerima. Lalu perintah DATA memberikan mail data. mail data. Dan akhirnya, akhir mengkonfirmasikan data indikator mail transaksi. Langkah pertama dalam prosedur adalah perintah MAIL. The Itu <reverse-path> berisi kotak sumber. MAIL <SP> FROM:<reverse-path> <CRLF> <SP> MAIL FROM: <CRLF> <reverse-path> Perintah ini memberitahukan bahwa penerima SMTP-mail baru transaksi awal dan untuk mengatur ulang semua tabel dan negaranya buffer, termasuk penerima atau data mail. Hal ini memberi reverse-path yang dapat digunakan untuk melaporkan kesalahan. Jika diterima, penerima-SMTP kembali jawaban 250 OK. <reverse-path> dapat berisi lebih dari sekedar kotak surat. Itu

<reverse-path> adalah sumber reverse routing daftar host dan sumber kotak surat. Tuan rumah pertama di <reverse-path> harus tuan rumah pengiriman perintah ini. Langkah kedua dalam prosedur adalah perintah RCPT. RCPT <SP> TO:<forward-path> <CRLF> <SP> RCPT TO: <forward-path> <CRLF> Perintah ini memberikan forward-jalan mengidentifikasi satu penerima. and Jika diterima, penerima-SMTP kembali jawaban 250 OK, dan toko maju-jalan. Jika penerima tidak dikenal receiver-SMTP kembali jawaban Kegagalan 550. prosedur dapat diulang setiap beberapa kali. <forward-path> dapat berisi lebih dari sekedar kotak surat. The Itu <forward-path> adalah routing sumber daftar host dan kotak surat tujuan. Tuan rumah pertama dalam <forward-path> tuan rumah harus menerima perintah ini. Langkah ketiga dalam prosedur adalah perintah DATA. DATA <CRLF> DATA <CRLF> Jika diterima, penerima-SMTP kembali jawaban 354 dan menganggap semua lini berhasil menjadi pesan teks. Ketika akhir teks yang diterima dan disimpan di SMTP-penerima mengirimkan jawaban 250 OK. Karena data mail akan dikirim pada akhir saluran transmisi data mail harus ditunjukkan sehingga perintah dan dialog balasan dapat dilanjutkan. SMTP menunjukkan akhir mail dengan mengirimkan data yang berisi hanya garis periode. A A transparansi prosedur digunakan untuk mencegah hal ini dari campur tangan dengan teks pengguna (lihat Subbab 4.5.2). Harap diperhatikan bahwa data mail termasuk header memo item seperti Tanggal, Subyek, Untuk, Cc, Dari [2]. Akhir data indikator mail juga menegaskan surat dan memberitahu penerima-SMTP untuk sekarang proses disimpan dan data penerima mail. Jika diterima,

receiver-SMTP kembali jawaban 250 OK. DATA perintah harus gagal hanya jika transaksi surat tidak lengkap (misalnya, tidak penerima), atau jika sumberdaya tidak tersedia. Prosedur di atas adalah contoh dari sebuah transaksi mail. perintah harus digunakan hanya dalam urutan yang dibahas di atas. Contoh 1 (bawah) mengilustrasikan penggunaan perintah ini di mail transaksi. ------------------------------------------------------------- ------------------------------------------------- ----------Example of the SMTP Procedure Contoh dari SMTP Prosedur Contoh SMTP menunjukkan surat yang dikirim oleh Smith di host Alpha Jones, Green, dan Brown di host Beta.ARPA. Di sini kita mengasumsikan bahwa host host Alpha Beta kontak langsung. S: MAIL FROM:< Smith@Alpha.ARPA > R: 250 OK S: RCPT TO:< Jones@Beta.ARPA > R: 250 OK S: RCPT TO:< Green@Beta.ARPA > R: 550 Tidak ada user seperti di sini RCPT TO: < Brown@Beta.ARPA > R: 250 OK S: DATA R: 354 Start mail input; berakhir dengan <CRLF>. <CRLF> S: Blah blah blah ... S: ... dll etc. etc. dll dll S: <CRLF>. <CRLF> R: 250 OK mail sekarang telah diterima untuk Jones dan Brown. Green did Hijau itu tidak punya kotak surat pada host Beta. Contoh 1

------------------------------------------------------------- ------------------------------------------------- ----------3.2. 3.2. Ekspedisi Ada beberapa kasus di mana informasi tujuan dalam <forward-path> tidak benar, tapi penerima-SMTP tahu tujuan yang benar. Dalam kasus tersebut, salah satu hal berikut balasan harus digunakan untuk memungkinkan pengirim untuk menghubungi yang benar tujuan. 251 Pengguna tidak lokal; akan maju untuk <forward-path> Jawaban ini menunjukkan bahwa penerima-SMTP tahu pengguna mailbox pada host lain dan menunjukkan yang benar maju-jalan untuk digunakan di masa depan. Perhatikan bahwa baik host atau pengguna atau keduanya mungkin berbeda. penerima mengambil tanggung jawab untuk menyampaikan pesan. 551 Pengguna bukan lokal; silakan coba <forward-path> Jawaban ini menunjukkan bahwa penerima-SMTP tahu pengguna pada host lain dan menunjukkan yang benar maju-jalan untuk digunakan. Perhatikan bahwa baik host atau pengguna atau keduanya mungkin berbeda. penerima menolak untuk menerima email the mail untuk user ini, dan pengirim juga harus menurut informasi yang disediakan atau kembali kesalahan respon kepada pengguna berasal. Contoh 2 mengilustrasikan penggunaan tanggapan ini. ------------------------------------------------------------- ------------------------------------------------- ----------Contoh Forwarding Salah satu S: RCPT TO:< Postel@USC-ISI.ARPA > R: 251 Pengguna tidak lokal; akan maju ke < Postel@USC-ISIF.ARPA > Atau S: RCPT TO: < Paul@USC-ISIB.ARPA > R: 551 Pengguna bukan lokal; silakan coba < Mockapetris@USC-ISIF.ARPA >

Contoh 2 ------------------------------------------------------------- ------------------------------------------------- ----------3.3. 3.3. Memeriksa DAN MENGEMBANGKAN SMTP memberikan sebagai fitur tambahan, perintah untuk memverifikasi user nama atau memperluas daftar mailing. Hal ini dilakukan dengan VRFY dan EXPN commands, EXPN perintah, yang telah argumen string karakter. Untuk perintah VRFY, string adalah nama pengguna, dan respon dapat mencakup nama lengkap pengguna dan harus menyertakan kotak surat dari pengguna. Untuk perintah EXPN, string mengidentifikasi sebuah daftar, dan respon multiline mungkin termasuk nama lengkap pengguna dan harus memberikan kotak surat di milis. "Nama pengguna" adalah istilah fuzzy dan digunakan sengaja. Jika tuan rumah menerapkan VRFY atau perintah EXPN maka setidaknya daerah kotak surat harus diakui sebagai "nama pengguna". Jika tuan rumah memilih untuk mengenali string lain sebagai "nama pengguna" yang diperbolehkan. Dalam beberapa host perbedaan antara mailing list dan sebuah alias untuk kotak surat tunggal agak sedikit kabur, karena struktur data umum dapat memegang kedua jenis masukan, dan adalah mungkin untuk memiliki mailing daftar satu kotak surat. Jika permintaan dibuat untuk memverifikasi sebuah mailing dapat diberikan jika pada penerimaan pesan sehingga ditangani itu akan dikirimkan ke semua orang di daftar, dinyatakan kesalahan harus dilaporkan (misalnya, "550 Itu mailing list, not a user"). bukan pengguna "). Jika permintaan dibuat untuk memperluas pengguna nama respons positif dapat dibentuk dengan mengembalikan daftar (eg, "550 That berisi satu nama, atau kesalahan dapat dilaporkan (misalnya, "550 Itu adalah nama pengguna, bukan milis "). Dalam hal jawaban multiline (normal untuk EXPN) tepat satu kotak surat yang akan ditetapkan pada setiap baris jawabannya. Dalam hal sebuah permintaan ambigu, misalnya, "VRFY Smith", di mana ada respon dua Smith harus "553 User" ambigu. Kasus memverifikasi nama pengguna langsung seperti ditunjukkan pada contoh 3.

------------------------------------------------------------- ------------------------------------------------- ----------Contoh Verifikasi Nama Pengguna Salah satu S: Smith VRFY R: 250 Fred Smith < Smith@USC-ISIF.ARPA > Atau S: Smith VRFY R: 251 Pengguna tidak lokal; akan maju ke < Smith@USC-ISIQ.ARPA > Atau S: Jones VRFY R: 550 String tidak cocok dengan apa-apa. Atau S: Jones VRFY R: 551 Pengguna bukan lokal; silakan coba < Jones@USC-ISIQ.ARPA > Atau S: Gourzenkyinplatz VRFY R: 553 User ambigu. Contoh 3 ------------------------------------------------------------- ------------------------------------------------- ----------Kasus memperluas daftar kotak surat membutuhkan jawaban multiline sebagai ditunjukkan dalam contoh 4. ------------------------------------------------------------- ------------------------------------------------- -----------

Contoh Memperluas Mailing List Salah satu S: EXPN Contoh-Orang R: 250-Jon Postel < Postel@USC-ISIF.ARPA > R:-Fred Fonebone 250 < Fonebone@USC-ISIQ.ARPA > R: 250-Sam T. Smith < SQSmith@USC-ISIQ.ARPA > R: Quincy Smith <-250 @ USC-ISIF.ARPA: Q-Smith@ISI-VAXA.ARPA > R: 250 - < joe@foo-unix.ARPA > R: 250 < xyz@bar-unix.ARPA > Atau S: EXPN Eksekutif-Toilet-Daftar R: 550 Akses Ditolak untuk Anda. Contoh 4 ------------------------------------------------------------- ------------------------------------------------- ----------Argumen string karakter VRFY dan perintah EXPN tidak dapat lebih jauh karena dibatasi berbagai implementasi nama pengguna dan konsep daftar kotak surat. Pada beberapa sistem itu mungkin cocok untuk argumen dari perintah EXPN menjadi nama file untuk file yang berisi daftar mailing, tapi sekali lagi ada berbagai konvensi penamaan file di Internet. VRFY dan perintah EXPN tidak termasuk dalam minimum pelaksanaan (Bagian 4.5.1), dan tidak diwajibkan untuk bekerja di relay ketika mereka diimplementasikan.

3.4. 3.4. SENDING AND MAILING MENGIRIM SURAT DAN Tujuan utama dari SMTP adalah menyampaikan pesan ke pengguna mailboxes. kotak surat. Sebuah layanan sangat mirip disediakan oleh beberapa host adalah menyampaikan pesan ke terminal pengguna (disediakan pengguna aktif on the host). pada host). Pengiriman ke kotak surat pengguna disebut pengiriman ke terminal pengguna disebut

"Pengiriman". Karena dalam banyak penghuni pelaksanaan pengiriman dengan pelaksanaan mailing kedua digabungkan dalam fungsi SMTP. Namun perintah pengiriman adalah tidak termasuk dalam pelaksanaan minimum (Bagian 4.5.1). Pengguna harus memiliki kemampuan untuk mengendalikan menulis pesan di terminal mereka. Kebanyakan penghuni mengizinkan pengguna untuk menerima atau menolak pesan tersebut. Berikut tiga perintah didefinisikan untuk mendukung pengiriman Pilihan. Ini digunakan dalam transaksi mail bukan perintah dan menginformasikan penerima-SMTP dari semantik khusus transaksi ini: KIRIM <SP> DARI: <CRLF> <reverse-path> KIRIM perintah mengharuskan bahwa data akan dikirimkan ke mail pengguna terminal. tidak aktif (atau tidak accepting terminal messages) menerima pesan terminal) di host jawaban mungkin 450 kembali ke perintah RCPT. berhasil jika pesan tersebut akan disampaikan terminal. SOML <SP> DARI: <CRLF> <reverse-path> Kirim Atau perintah mail mengharuskan bahwa data mail akan dikirim ke terminal pengguna jika pengguna aktif (dan menerima pesan terminal) pada host. Jika pengguna tidak aktif (atau tidak menerima pesan terminal) maka mail data dimasukkan ke dalam kotak surat pengguna. transaksi berhasil jika pesan disampaikan baik ke terminal atau kotak surat. SAML <SP> DARI: <CRLF> <reverse-path> Kirim Dan perintah mail mensyaratkan bahwa data mail akan dikirim ke terminal pengguna jika pengguna aktif (dan menerima pesan terminal) pada host. Dalam setiap kasus mail data dimasukkan ke dalam kotak surat pengguna. transaksi berhasil jika pesan yang disampaikan kotak surat. Kode jawaban yang sama yang digunakan untuk perintah MAIL digunakan

untuk perintah ini. 3.5. 3.5. PEMBUKAAN DAN PENUTUP Pada saat saluran transmisi dibuka ada pertukaran untuk memastikan bahwa host yang berkomunikasi dengan host mereka pikir mereka. Kedua perintah berikut digunakan dalam saluran transmisi pembukaan dan penutupan: HELO <SP> <domain> <CRLF> QUIT <CRLF> Dalam perintah HELO tuan rumah mengirimkan perintah mengidentifikasi sendirinya, perintah dapat ditafsirkan sebagai mengatakan "Halo, saya <domain> ". ------------------------------------------------------------- ------------------------------------------------- ----------Contoh Koneksi Pembukaan R: 220 BBN-UNIX. ARPA Mail Wikipedia Layanan Transfer Siap S: HELO USC-ISIF.ARPA R: 250 BBN-UNIX. ARPA Contoh 5 ------------------------------------------------------------- ------------------------------------------------- ----------------------------------------------------------------------- ------------------------------------------------- ----------Contoh Koneksi Penutupan S: QUIT R: 221 BBN-UNIX Layanan ARPA. Penutupan saluran transmisi Contoh 6

------------------------------------------------------------- ------------------------------------------------- ----------3.6. 3.6. Menyampaikan Maju-jalan mungkin menjadi sumber rute dalam bentuk @ SATU, @ DUA: JOE @ TIGA", di mana SATU, DUA, dan TIGA adalah penghuni. This Ini bentuk digunakan untuk menekankan perbedaan antara alamat dan kotak surat adalah alamat absolut, dan rute informasi tentang bagaimana menuju ke sana. Dua konsep tidak harus bingung. Konseptual elemen-jalan ke depan akan dipindah ke sebagai pesan disampaikan dari satu server SMTP untuk lain. Jalan-reverse adalah sumber rute sebaliknya (yaitu, sumber rute dari lokasi saat ini pesan ke penggagas pesan). Bila server SMTP-nya menghapus pengenal dari jalan-maju dan memasukkan ke dalam itu harus menggunakan nama yang dikenal dengan dalam lingkungan itu mengirim ke, bukan lingkungan surat datang dalam kasus-SMTP server dikenal dengan nama yang berbeda di lingkungan yang berbeda. Jika saat pesan tiba pada elemen pertama dari SMTP maju-jalan bukan identifier dari elemen SMTP tidak the next dihapus dari jalan-maju dan digunakan untuk menentukan berikutnya SMTP untuk mengirim pesan. Dalam kasus apapun, SMTP menambahkan sendiri pengenal ke jalan-reverse. Menggunakan routing sumber-SMTP penerima menerima mail yang akan disampaikan SMTP penerima dapat menerima atau menolak tugas menyampaikan surat dengan cara yang sama ia menerima atau menolak mail untuk pengguna lokal. mengubah perintah dengan memindahkan pengenal sendiri dari jalan-maju untuk awal jalan-reverse. Penerima-SMTP kemudian menjadi pengirim-SMTP, menetapkan saluran transmisi ke SMTP berikutnya di jalan-maju, dan mengirimnya surat. Tuan rumah pertama di jalan-reverse seharusnya menjadi tuan rumah mengirim

perintah SMTP, dan tuan rumah pertama di jalan-maju harus tuan rumah menerima perintah SMTP. Perhatikan bahwa maju-jalan dan reverse-path muncul di SMTP perintah dan balasan, tetapi tidak harus dalam pesan. Bahwa adalah, tidak ada kebutuhan untuk jalur tersebut dan terutama ini sintaks untuk Kepada:, "Dari:", "CC:", dll bidang pesan header. Jika server-SMTP telah menerima tugas untuk menyampaikan surat dan kemudian menemukan bahwa maju-jalan tidak benar atau bahwa surat tidak dapat dikirim karena alasan apapun, maka harus membangun sebuah "Surat tidak terkirim" pemberitahuan pesan dan mengirimkannya ke penggagas mail tidak terkirim (seperti ditunjukkan oleh reverse-path). Pesan pemberitahuan ini harus dari server-SMTP pada ini Tentu saja, server-SMTPs tidak harus mengirimkan pemberitahuan pesan tentang masalah dengan pesan pemberitahuan. One way to Salah satu cara untuk mencegah loop di melaporkan kesalahan adalah untuk menentukan null reverse-path dalam perintah MAIL dari pesan pemberitahuan. When such a Ketika seperti pesan yang disampaikan itu diperbolehkan untuk meninggalkan jalan-reverse null. Sebuah perintah MAIL dengan null reverse path-muncul sebagai berikut: MAIL FROM:> < Sebuah pesan email pemberitahuan terkirim ditampilkan dalam contoh 7. pemberitahuan ini adalah tanggapan terhadap pesan berasal oleh JOE di dan dikirimkan melalui HOSTX untuk HOSTY dengan instruksi untuk relay pada Apa yang kita lihat dalam contoh adalah transaksi antara yang merupakan langkah pertama dalam pengembalian pesan pemberitahuan. Simple Mail Transfer Protocol Simple Mail Transfer Protocol ------------------------------------------------------------- ------------------------------------------------- ----------Contoh Surat Pemberitahuan Tidak dapat dikirim Pesan S: MAIL FROM:> <

R: 250 ok S: RCPT TO: <@ HOSTX.ARPA: JOE@HOSTW.ARPA > R: 250 ok S: DATA R: 354 mengirim data surat, berakhir dengan. S: Tanggal: 23 Okt 81 11:22:33 S: Dari: SMTP@HOSTY.ARPA S: Untuk: JOE@HOSTW.ARPA S: Subjek: Mail Masalah Sistem S: S: Maaf JOE, pesan Anda ke SAM@HOSTZ.ARPA hilang. S: HOSTZ.ARPA mengatakan hal ini: S: "550 Tidak ada Pengguna tersebut" S:. R: 250 ok Contoh 7 ------------------------------------------------------------- ------------------------------------------------- ----------3.7. 3.7. Domain Domains are a recently introduced concept in the ARPA Internet Domain adalah sebuah konsep baru-baru ini diperkenalkan di Internet ARPA mail system. sistem mail. The use of domains changes the address space from a Penggunaan domain perubahan ruang alamat dari flat global space of simple character string host names to a datar global ruang yang sederhana string karakter nama host ke hierarchically structured rooted tree of global addresses. pohon berakar hirarkis terstruktur alamat global. The Itu host name is replaced by a domain and host designator which is a nama host digantikan oleh host domain dan designator yang merupakan sequence of domain element strings separated by periods with the urutan string elemen domain dipisahkan oleh periode dengan understanding that the domain elements are ordered from the most pemahaman bahwa unsur domain yang dipesan dari yang paling specific to the most general. khusus untuk yang paling umum. For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and Misalnya, "USCISIF.ARPA", "Fred.Cambridge.UK", dan "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers.

"PC7.LCS.MIT.ARPA" mungkin menjadi tuan rumah-dan-domain pengidentifikasi. Setiap kali nama domain yang digunakan di SMTP hanya nama resmi digunakan, penggunaan nama panggilan atau alias tidak diperbolehkan.

3.8. 3.8. MENGUBAH PERAN Perintah MENGHIDUPKAN dapat digunakan untuk membalikkan peran dua program berkomunikasi melalui saluran transmisi. Jika program-A saat ini pengirim-SMTP dan mengirimkan MENGHIDUPKAN perintah dan menerima balasan ok (250) maka program-A menjadi receiver-SMTP. Jika program-B saat ini penerima-SMTP dan menerima MENGHIDUPKAN perintah dan mengirim balasan ok (250) maka program-B menjadi pengirim-SMTP. Untuk menolak untuk mengubah peran penerima mengirimkan jawaban 502. Harap dicatat bahwa perintah ini adalah opsional. It would not normally Ini akan tidak normal digunakan dalam situasi di mana saluran transmisi TCP. Namun, ketika biaya membangun saluran transmisi tinggi, perintah ini mungkin sangat berguna. Misalnya, perintah ini mungkin berguna dalam mendukung pertukaran mail akan menggunakan publik diaktifkan sistem telepon sebagai saluran transmisi, terutama jika beberapa jajak pendapat host lain host untuk pertukaran mail.

4. 4. SMTP ATAS SPESIFIKASI 4.1. 4.1. PERINTAH SMTP 4.1.1. 4.1.1. COMMAND SEMANTIK SMTP menentukan perintah transfer mail atau sistem mail fungsi yang diminta oleh pengguna. SMTP commands are character perintah SMTP adalah karakter string diakhiri oleh <CRLF>. Perintah kode sendiri karakter abjad diakhiri oleh <SP> jika parameter mengikuti

dan <CRLF> sebaliknya. Sintaks dari kotak surat harus sesuai dengan penerima situs konvensi. Perintah SMTP dibahas di bawah ini. SMTP jawaban dibahas dalam Bagian 4.2. Sebuah transaksi mail melibatkan beberapa objek data yang dikomunikasikan sebagai argumen untuk perintah yang berbeda. The Itu argumen perintah MAIL, yang jalan ke depan adalah argumen dari perintah RCPT, dan surat data is the argument of the DATA command. data argumen dari perintah DATA. Argumen ini atau data objects must be transmitted and held pending the objek data harus dikirim dan diselenggarakan menunggu konfirmasi dikomunikasikan pada akhir data indikasi mail yang finalizes transaksi. Model untuk ini adalah bahwa berbeda yang disediakan untuk menampung jenis data yaitu, ada buffer reverse-jalan, sebuah maju-jalan buffer, dan sebuah surat buffer data. Perintah Tertentu informasi alasan untuk ditambahkan ke buffer tertentu, atau menyebabkan satu atau lebih buffer harus dibersihkan. HELLO (HELO) Perintah ini digunakan untuk mengidentifikasi pengirim-SMTP ke receiver-SMTP. Bidang argumen berisi nama host pengirim-SMTP. Penerima-SMTP mengidentifikasi dirinya ke pengirim-SMTP di sambungan salam balasan, dan dalam penanggulangan ini perintah. Ini perintah dan jawaban OK untuk itu pastikan bahwa baik -SMTP pengirim dan penerima-SMTP dalam keadaan awal, yaitu, tidak ada transaksi dalam proses dan negara semua tabel dan buffer akan dihapus. MAIL (MAIL) Perintah ini digunakan untuk melakukan transaksi mail yang data surat dikirimkan kepada satu atau lebih kotak surat. Itu lapangan argumen berisi path-reverse. Jalan-balik terdiri dari daftar pilihan host dan

Ketika daftar host hadir, adalah "terbalik" rute sumber dan menunjukkan bahwa surat itu disampaikan melalui masing-masing host pada daftar (tuan rumah pertama di daftar adalah relay paling baru). Daftar ini digunakan sebagai Sumber rute untuk kembali non-pengiriman pemberitahuan ke pengirim. Karena setiap host relay menambahkan sendiri ke awal daftar, harus menggunakan nama sebagai IPCE dikenal di mana itu menyampaikan surat daripada IPCE dari yang surat datang (jika mereka berbeda). Dalam beberapa jenis kesalahan pelaporan pesan (misalnya mail, terkirim pemberitahuan) jalan-reverse mungkin nol (lihat Contoh 7). Perintah ini membersihkan buffer reverse-jalur, maju-jalan buffer, dan buffer data mail dan sisipan informasi reverse-path dari perintah ini ke

PENERIMA (RCPT) Perintah ini digunakan untuk mengidentifikasi suatu penerima individual data mail beberapa penerima yang ditentukan oleh beberapa penggunaan perintah ini. Maju-jalan terdiri dari daftar pilihan host dan diperlukan tujuan kotak surat. Ketika daftar host adalah sekarang, ini adalah rute sumber dan menunjukkan bahwa surat harus disampaikan ke host berikutnya dalam daftar. If the Jika receiver-SMTP tidak mengimplementasikan fungsi relay mungkin pengguna jawaban yang sama akan untuk pengguna lokal yang tidak diketahui (550). Ketika mail ini diteruskan, tuan rumah relay harus menghapus diri dari maju awal-jalan dan menempatkan dirinya di awal dari jalan-reverse. Ketika mencapai level tertinggi mail tujuan (maju-jalan hanya berisi tujuan kotak surat), yang memasukkan penerima-SMTP ke tujuan kotak surat sesuai dengan konvensi mail yang host.

Misalnya, surat yang diterima di A host relay dengan argumen DARI: < USERX@HOSTY.ARPA >

ATAS: <@ HOSTA.ARPA, @ HOSTB.ARPA: USERC@HOSTD.ARPA > akan diteruskan ke host B dengan argumen DARI: <@ HOSTA.ARPA: USERX@HOSTY.ARPA > ATAS: <@ HOSTB.ARPA: USERC@HOSTD.ARPA >. Perintah ini menyebabkan argumen-jalan ke depan untuk ditambahkan ke buffer maju-jalan. DATA (DATA) mail penerima memperlakukan baris berikut perintah sebagai mail data dari pengirim. Perintah ini menyebabkan data mail dari perintah ini untuk ditambahkan ke data buffer mail. Data mail mungkin berisi salah satu dari karakter ASCII 128 kode. Data mail ini diakhiri oleh sebuah garis hanya berisi <CRLF>" (see periode, yaitu urutan karakter "<CRLF>" (lihat Bagian 4.5.2 pada Transparansi). Ini adalah akhir surat data indikasi. Akhir mail indikasi data mensyaratkan bahwa penerima sekarang harus memproses informasi transaksi mail disimpan. pengolahan ini mengkonsumsi informasi di jalan-reverse buffer, buffer maju-jalan, dan data buffer mail, dan pada penyelesaian dari perintah ini adalah buffer dibersihkan. Jika proses ini berhasil penerima harus mengirim balasan OK. Jika pemrosesan gagal sepenuhnya penerima harus mengirimkan jawaban kegagalan. Ketika penerima-SMTP menerima pesan baik untuk menyampaikan atau untuk pengiriman akhir ini memasukkan pada awal mail data garis waktu yang tertera. Garis waktu yang tertera menunjukkan identitas host yang mengirim pesan, dan identitas host yang menerima pesan (dan memasukkan ini cap waktu), serta tanggal dan waktu pesan yang diterima. menyampaikan pesan akan memiliki beberapa time stamp lines. waktu cap baris. Ketika penerima-SMTP membuat pengiriman "akhir" dari

menyisipkan pesan itu pada awal data mail jalur jalur kembali. Jalur jalan kembali mempertahankan informasi dalam <reverse-path> dari perintah MAIL. Di sini, tujuan akhir berarti meninggalkan pesan SMTP dunia. Biasanya, ini berarti telah dikirim ke pengguna tujuan, tetapi dalam beberapa kasus mungkin lebih lanjut diproses dan dikirimkan oleh sistem email lain. Hal ini dimungkinkan untuk kotak di jalan akan kembali berbeda dari kotak surat pengirim yang sebenarnya, misalnya, jika tanggapan kesalahan harus disampaikan kesalahan khusus penanganan kotak surat daripada pengirim pesan. Kedua paragraf sebelumnya menyiratkan bahwa data mail akhir akan dimulai dengan garis jalan kembali, diikuti oleh satu atau lebih waktu cap baris. Garis-garis ini akan diikuti dengan surat header dan data [tubuh 2]. Lihat Contoh 8. perhatian khusus diperlukan dari respon dan tindakan lebih lanjut diperlukan saat memproses berikut akhir data mail indikasi sebagian berhasil. Hal ini dapat timbul apabila the setelah menerima beberapa penerima dan data surat, yang receiver-SMTP menemukan bahwa data mail dapat berhasil disampaikan kepada beberapa penerima, tetapi tidak dapat untuk lain (misalnya, karena alokasi ruang kotak surat masalah). Dalam situasi seperti itu, respon terhadap DATA perintah harus balasan OK. Tapi, penerima-SMTP harus menulis dan mengirim e "terkirim" pemberitahuan pesan ke originator pesan. Either a single Entah satu pemberitahuan yang berisi semua penerima yang gagal untuk mendapatkan pesan, atau pesan pemberitahuan harus terpisah dikirim untuk setiap penerima gagal (lihat Contoh 7). All Semua pesan terkirim mail pemberitahuan dikirim menggunakan MAIL perintah (bahkan jika mereka hasil dari pengolahan KIRIM sebuah, SOML, atau perintah SAML).

------------------------------------------------------------- ------------------------------------------------- -----------

Contoh Path Kembali dan Diterima Waktu Stamps Return-Path: <@ GHI.ARPA, @ DEF.ARPA, @ ABC.ARPA: JOE@ABC.ARPA > Received: from GHI.ARPA oleh JKL.ARPA; 27 Oktober 81 15:27:39 PST Received: from DEF.ARPA oleh GHI.ARPA; 27 Oktober 81 15:15:13 PST Received: from ABC.ARPA oleh DEF.ARPA; 27 Oktober 81 15:01:59 PST Date: 27 Oct 81 15:01:01 PST Dari: JOE@ABC.ARPA Perihal: Sistem Mailing Peningkatan Dipasang Untuk: SAM@JKL.ARPA

IMAP IMAP (Internet Message Access Protocol) adalah protokol standar untuk mengakses/mengambil e-mail dari server. IMAP memungkinkan pengguna memilih pesan e-mail yang akan ia ambil, membuat folder di server, mencari pesan e-mail tertentu, bahkan menghapus pesan e-mail yang ada. Kemampuan ini jauh lebih baik daripada POP (Post Office Protocol) yang hanya memperbolehkan kita mengambil/download semua pesan yang ada tanpa kecuali. Apakah perbedaan antara IMAP dan POP? IMAP menawarkan komunikasi dua arah antara web Anda dan klien email Gmail Anda (s). Ini berarti ketika Anda login ke Gmail menggunakan browser web, tindakan yang Anda lakukan di klien email dan perangkat mobile (ex: mail meletakkan sebuah karya 'folder) akan langsung dan secara otomatis muncul di Gmail (ex: itu sudah akan memiliki' bekerja 'label pada email tersebut pada waktu berikutnya Anda sign in). IMAP juga menyediakan metode yang lebih baik untuk mengakses email Anda dari beberapa perangkat. Jika Anda periksa email Anda di tempat kerja, di ponsel Anda, dan sekali lagi di rumah, IMAP menjamin bahwa email baru dapat diakses dari perangkat apapun pada waktu tertentu. Akhirnya, IMAP menawarkan pengalaman yang lebih stabil secara keseluruhan. Sedangkan POP rawan terhadap kehilangan pesan atau men-download pesan yang sama beberapa kali, IMAP menghindari ini melalui dua arah kemampuan sinkronisasi antara klien surat Anda dan Anda web Gmail. Jika Anda mencoba untuk memutuskan antara menggunakan POP dan IMAP dengan menggunakan Gmail, kami menyarankan IMAP.

Berapa biaya IMAP? IMAP untuk Gmail gratis. Bagaimana saya memulai? Pertama, Anda harus mengaktifkan IMAP di Gmail . Setelah IMAP diaktifkan, ikuti petunjuk konfigurasi untuk klien Anda pilihan. Saat ini, hanya klien yang terdaftar yang didukung untuk IMAP. Jika Anda ingin men-download pesan Gmail Anda dengan seorang klien yang berbeda, periksa untuk melihat apakah pada daftar klien POP didukung. Bila Anda telah mengaktifkan IMAP dan membuat klien Anda, masuk ke Gmail melalui klien dan menonton pesan Anda tiba. Anda akan melihat bahwa semua custom label Gmail Anda akan muncul di klien Anda sebagai folder, dengan label dalam pesan Anda. Sementara kami ingin membuat Anda cocok dengan pengalaman IMAP antarmuka web Gmail sebanyak mungkin, beberapa fitur Gmail-spesifik dan istilah, seperti percakapan threading dan bintang-bintang, tidak akan muncul pada klien Anda. Jangan khawatir, Anda masih bisa melakukan semua fungsi biasa Gmail, hanya dengan cara yang sedikit berbeda. Para daftar perilaku IMAP menunjukkan Anda bagaimana untuk melakukan fungsi umum pada klien IMAP Anda. Perlu diketahui bahwa setiap klien menangani IMAP dengan cara yang sedikit berbeda. Jika Anda penasaran tentang penggunaan spesifik dari klien Anda, hubungi tim dukungan klien. MIME Multipurpose Internet Mail Extension (disingkat menjadi MIME atau mime), merujuk kepada protokol yang luas digunakan di dalam dunia Internet yang memperluas protokol SMTP (Simple Mail Transfer Protocol) (RFC 822) untuk mengizinkan beberapa data selain teks dengan pengodean ASCII, seperti video, suara, dan berkas biner, agar dapat ditransfer melalui e-mail tanpa harus mentranslasikan terlebih dahulu data-data tersebut ke dalam teks berformat ASCII. MIME merupakan bagian dari protokol HTTP, dan web browser dan server HTTP akan menggunakan MIME untuk menginterpretasikan berkasberkas e-mail yang dikirimkan dan diterima. SMTP Aslinya, sebuah pesan SMTP hanya boleh mengandung berkas teks saja yang dikodekan dengan menggunakan pengodean ASCII 7-bit saja. Berkas-berkas biner, seperti halnya program, dokumen pengolah kata, dan banyak lagi format lainnya, tidak dapat dikirimkan melalui SMTP. Dengan menggunakan Multipurpose Internet Mail Extension (MIME) yang didefinisikan di dalam RFC 1521, hal tersebut bukan lagi masalah.

Meskipun demikian, protokol ini tidaklah dibuat untuk menggantikan protokol SMTP, tapi hanya memperluas pada dua bagian: "multipart message body" dan "non-ASCII message content". MIME menambahkan dua jenis header SMTP tambahan, yakni sebagai berikut: • Content-Type: menentukan jenis content yang dibawa oleh pesan-pesan SMTP. • Content-Transfer-Encoding: menentukan metode apa yang digunakan untuk mengodekan pesan-pesan SMTP. RFC 1521 menentukan tujuh buah jenis content dasar yang dapat dimasukkan ke dalam header Content-Type dalam pesan SMTP. Setiap jenis content dasar ini memiliki beberapa Content subtype yang menentukan informasi apa yang dibawa oleh pesanpesan SMTP, yakni sebagai berikut: • Text: yang menentukan bahwa pesan yang dibawa oleh protokol SMTP merupakan teks biasa saja (Text/plain), teks kaya (Text/richtext), Text/html, dan beberapa jenis lainnya. • Application: yang menentukan bahwa pesan yang dibawa oleh protokol SMTP merupakan data biner. Beberapa jenis subtype untuk type ini adalah Application/octet-stream, Application/Postscript, Application/msword (dokumen Microsoft Word 97-2003) dan masih banyak lagi. • Berkas: yang menentukan bahwa pesan yang dibawa oleh protokol SMTP adalah gambar. Beberapa jenis subtype untuk type ini adalah Image/gif, Image/jpg, Image/png, Image/tiff dan lain-lain. • Audio: yang menentukan bahwa pesan yang dibawa oleh protokol SMTP adalah berkas audio. • Video: yang menentukan bahwa pesan yang dibawa oleh protokol SMTP adalah berkas video. • Message: Beberapa jenis subtype antara lain Message/rfc822 (pesan asli teks standar RFC 822), Message/HTTP (untuk lalu lintas HTTP), dan beberapa lainnya • Multipart RFC 1521 juga mendefinisikan metode pengodean data tambahan yang dapat ditentukan pada field Content-Transfer-Encoding dalam header SMTP, yakni: • 7bit: pengodean yang digunakan adalah teks ASCII 7 bit, dengan batasan panjang hingga kurang dari 1000 karakter • 8bit • binary • quoted-printable • base64 (UUEncoded data) • x-token

REFERENCES DAFTAR PUSTAKA [1] ASCII ASCII, "USA Code for Information Interchange", United States of America Standards Institute, X3.4, 1968. Also in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for the Defense Communications Agency by SRI International, Menlo Park, California, Revised January 1978. [2] RFC 822 Crocker, D., "Standard for the Format of ARPA Internet Text Messages," RFC 822 , Department of Electrical Engineering, University of Delaware, August 1982. [3] TCP Postel, J., ed., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793 , USC/Information Sciences Institute, NTIS AD Number A111091, September 1981. Also in: Juga dalam: Feinler, E. and J. Postel, eds., "Internet Protocol Transition Workbook", SRI International, Menlo Park, California, March 1982. [4] NCP McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246, January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for the Defense Communications Agency by SRI International, Menlo Park, California, Revised January 1978. [5] Initial Connection Protocol Postel, J., "Official Initial Connection Protocol", NIC 7101, 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for the Defense Communications Agency by SRI International, Menlo Park, California, Revised January 1978.

[6] NITS PSS/SG3, "A Network Independent Transport Service", Study Group 3, The Post Office PSS Users Group, February 1980. Available from Tersedia dari the DCPU, National Physical Laboratory, Teddington, UK. August 1982 RFC 821 August 1982 RFC 821 Simple Mail Transfer Protocol Simple Mail Transfer Protocol [7] X.25 CCITT, "Recommendation X.25 - Interface Between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for Terminals Operating in the Packet Mode on Public Data Networks," CCITT Orange Book, Vol. VIII.2, International Telephone and Telegraph Consultative Committee, Geneva, 1976. Read more: http://translate.googleusercontent.com/translate_c?hl=id&sl=en&u=http://www.faqs.org/ rfcs/rfc821.html&prev=/search%3Fq%3Dsmtp%26hl%3Did&rurl=translate.google.co.i d&usg=ALkJrhiRPftrRYdwTIP5MuDTkjzjisLEdA#ixzz0pmzIVsdd

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->