Protokol Pindahan Mel Mudah

Protokol Pindahan Mel Mudah ("Simple Mail Transfer Protocol-SMTP") merupakan piwaian Internet bagi penghantaran surat eletronik (e-mail) melalui rangkaian Protokol Internet (IP). SMTP pertama kali ditakrifkan dalam RFC 821 (STD 15) (1982), dan terakhir dikemas kini oleh RFC 5321 (2008) yang merangkumi SMTP tambahan (ESMTP), dan dan merupakan protokol yang digunakan secara meluas hari ini. SMTP adalah khusus bagi pengangkutan mel keluar dan menggunakan Protokol Kawalan Penghantaran ("Transmission Control Protocol-TCP") port komputer 25.

Ketika pelayan mel eletronik dan agen pemindah mel lain menggunakan SMTP bagi menghantar dan menerima perutusan mel, applikasi mel tahap pengguna biasanya hanya menggunakan SMTP bagi menghantar perutusan ke pelayan mel bagi geganti mel. Bagi menerima perutusan, applikasi pelanggan biasanya menggunakan samaada Protokol Pejabat Pos (POP) atau Protokol Capaian perutusan Internet ("Internet Message Access Protocol-IMAP") atau sistem proprietari (seperti Microsoft Exchange atau Lotus Notes/Domino) untuk mencapai kotak mel pada mel pelayan.

Sejarah

Pelbagai bentuk perutusan eletronik satu-kepada-satu digunakan pada akhir 1960-an. Orang berhubung antara satu sama lain dengan sistem yang dibangunkan khusus untuk komputer kerangka utama. Apabila semakin banyak komputer saling bersambung, terutama di ARPANET kerajaan Amerika Syarikat, piwaian dibangunkan supaya pengguna dengan sistem berlainan dapat saling menghantar e-mel. SMTP muncul dari piwaian-piawaian ini yang dikembangkan semasa 1970-an.

SMTP boleh menjejak asalnya kepada dua perlaksanaan yang digambarkan pada tahun 1971, Protokol Kotak Mel ("Mail Box Protocol"), yang telah dipertikaikan sebagai telah dilaksanakan, but is discussed in RFC 196 and other RFCs, and the SNDMSG program, which, according to RFC 2235, Ray Tomlinson of BBN "invents" for TENEX computers the sending of mail across the ARPANET. Fewer than 50 hosts were connected to the ARPANET at this time.

Perlaksanaan lanjut termasuk Mel FTP and Mail Protocol, both from 1973. Kerja-kerja pembangunan berterusan sepanjang tahun 1970-an, sehingga ARPANET diubah kepada Internet moden sekitar 1980. Jon Postel kemudian mencadangkan Protokol Pemindahan Mel ("Mail Transfer Protocol") pada tahun 1980 yang mula menyingkirkan kebergantungan mel pada FTP. SMTP was published as RFC 821 in August 1982, also by Postel.

Piwaian SMTP dibangunakan sekitar masa yang sama seperti Usenet, jaringan perhubungan satu-ke-banyak dengan sedikit persamaan.

SMTP digunakan secara meluas sekitar awal 1980-an. Pada masa itu, ia melengkapi me Unix to Unix Copy Program (UUCP), yang lebih sesuai bagi mengendalikan pemindahan mel eletronik antara mesin yang bersambung sekali-sekala. Sebaliknya, SMTP paling sesuai apabila kedua mesin penghantar dan penerima bersambung pada jaringan sepanjang masa. Keduanya menggunakan mekanisma simpan dan hantar dan merupakan contoh teknologi tolak ("push technology"). Sungguhpun newsgroups Usenet masih digandakan menggunakan UUCP antara pelayan, mel UUCP hampir pupus bersama "laluan bang" yang digunakannya sebagai kepala laluan perutusan.

Rencana mengenai Skim Penulis semula Penghantar ("Sender Rewriting Scheme") mengandungi maklumat latar teknikal mengenai sejarah awal SMTP dan sumber denai sebelum RFC 1123.

Sendmail merupakan antara agen pemindah mel yang pertama (jika bukan yang pertama) yang melaksanakan SMTP. Perisian pelayan SMTP popular lain termasuk Postfix, qmail, Novell GroupWise, Exim, Novell NetMail, Microsoft Exchange Server, Sun Java System Messaging Server.

Penghantar Perutusan (RFC 2476) dan SMTP-AUTH (RFC 2554) diperkenalkan pada tahun 1998 dan 1999, kedua-duanya menggambarkan trend baru dalan penghantaran mel eletronik. Pada asalnya, pelayan SMTP biasanya dalaman bagi organisasi, menerima mel bagi organisasi dari luar, dan hantar perutusan dari organisasi ke luar. Tetapi dengan perubahan masa, pelayan SMTP (agen pemindah mel), dalam amalan, mengembangkan peranan mereka dan menjadi agen penghantar perutusan ("message submission agent") bagi agen mel pengguna, sesetengah yang kini bergantung kepada mel dari luar organisasi. (contoh. esekutif syarikat yang ingin menghantar surat eletronik semasa keluar dengan menggunakan pelayan SMTP syarikat.) Isu ini, akibat dari perkembangan pantas dan popular World Wide Web, bererti protokol SMTP terpaksa memasukkan arahan khusus dan kaedah bagi menyampaikan mel dan mengesahkan pengguna bagi menghalang salah guna seperti menghantar surat eletronik yang tidak dipohon (spam surat eletronik).

Oleh kerana protokol ini bermula sebagai berasaskan teks ASCII sepenuhnya, ia tidak begitu sesuai bagi fail binari. Piwaian seperti Multipurpose Internet Mail Extensions (MIME) dibangunkan bagi mengkod fail binari melalui SMTP. Agen penghantar mel ("Mail transfer agents (MTAs)") yang dibangunkan selepas Sendmail turut cenderung melaksanakan 8-bit-bersih, dengan itu strategi sampingan "hanya hantar lapan" boleh digunakan bagi menghantar data teks rawak (dalam sebarang pengkod seperti huruf 8-bit ASCII) melalui SMTP. MTA 8-bit-bersih semasa cenderung menyokong tambahan 8BITMIME, membenarkan fail binari dihantar semudah teks biasa.

Ramai orang yang menyumbang kepada teras spesifikasi SMTP, antara mereka adalah Jon Postel, Eric Allman, Dave Crocker, Ned Freed, Randall Gellens, John Klensin, dan Keith Moore.

Protokol ini secara sendirian tidak mengendalikan fail perduaan dengan baik oleh kerana ia sepenuhnya berasaskan teks ASCII. Piwaian seperti Multipurpose Internet Mail Extensions (MIME) dibangunkan bagi mengekod fail perduaan supaya dapat dihantar melalui SMTP. Mail transfer agent (MTA) yang dibangunkan selepas Sendmail juga cenderung dilaksanakan 8-bit bersih, agar strategi pilihan "hantar lapan sahaja" boleh digunakan bagi menghantar data teks arbitari (dalam sebarang pengekodan aksara ala-ASCII 8-bit) melalui SMTP. MTA 8-bit bersih hari ini cenderung menyokong sambungan 8BITMIME yang membolehkan fail perduaan dihantar semudah teks biasa.

Ramai yang telah menyumbang kepada spesifikasi teras SMTP, antaranya termasuklah Jon Postel, Eric Allman, Dave Crocker, Ned Freed, Randall Gellens, John Klensin, dan Keith Moore.

Model pemprosesan mel

Panah Biru boleh dilaksanakan menggunakan variasi SMTP.

Aliran keseluruhan bagi ciptaan perutusan, pengangkutan mel, dan penghantaran digambarkan sebagaimana ditunjukkan.

Contoh pengangkutan SMTP

Contoh biasa bagi menghantar perutusan SMTP kepada dua peti mel (alice dan theboss) terletak di domain mel yang sama (example.com) diulang dalam pertukaran sesi berikut.

Untuk gambaran di sini (bukan sebahagian protokol), pertukaran protokol di awalkan bagi pelayan (S:) dan pelanggan (C:).

Selepas penghantar perutusan (pelanggan SMTP ) menubuhkan saluran komunikasi yang baik kepada penerima perutusan (pelayan SMTP), sesi dibuka dengan aluan oleh pelayan, biasanya mengandungi nama domain layak penuh ("fully qualified domain name-FQDN"), dalm kes ini smtp.example.com. Pelanggan memulakan dialognya dengan perintah HELO mengenali diri dalam parameter perintah dengan FQDNnya (atau pada alamat sekiranya tiada).

S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM:<bob@example.org>
S: 250 Ok
C: RCPT TO:<alice@example.com>
S: 250 Ok
C: RCPT TO:<theboss@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "Bob Example" <bob@example.org>
C: To: "Alice Example" <alice@example.com>
C: Cc: theboss@example.com
C: Date: Tue, 15 Jan 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 5 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
{Pelayan memutuskan sambungan}

Tambahan pilihan

Sungguhpun pilihan dan tidak ditunjukkan dalam contoh ini, banyak pelanggan meminta pelayan bagi sambungan SMTP yang disokong oleh pelayan, dengan menggunakan kod ucapan EHLO bagi spesifikasi SMTP tambahan (RFC 1870). Pelanggan balik kepada kod HELO hanya jika pelayan tidak bertindak balas kepada kod EHLO.

Pelanggan moden mungkin menggunakan kata kunci sambungan ESMTP extension SIZE bagi menanya pelayan bagi saiz maksima perutusan yang diterima. Pelanggan dan pelayan lebih tua mungkin cuba menghantar perutusan bersaiz melampau yang akan ditolak selepas memakan sumber jaringan, termasuk masa sambungan kepada sambungan jaringan yang dibayar mengikut minit.

Pengguna boleh menentukan awal lagi secara manual saiz yang diterima oleh pelayan ESMTP. Pelanggan menggantikan perintah HELO dengan perintah EHLO.

S: 220 smtp2.example.com ESMTP Postfix
C: EHLO bob.example.org
S: 250-smtp2.example.com Hello bob.example.org [192.0.2.201]
S: 250-SIZE 14680064
S: 250-PIPELINING
S: 250 HELP

Dengan itu smtp2.example.com mengistiharkan bahawa ia akan menerima saiz perutusan maksima tetap tidak melebihi 14,680,064 Octet (8-bit bite). Bergantung kepada kegunaan sumber pelayan sebenar, ia mungkin tidak mampu menerima perutusan sebesar ini. Dalam kes mudah, pelayan ESMTP akan mengistiharkan SAIZ maksima hanya dengan campur tangan pengguna EHLO.

Perlaksanaan

Rencana utama: List of mail servers

Mohon Komen Brkait

• RFC 1123 – Requirements for Internet Hosts—Application and Support (STD 3)
• RFC 1870 – SMTP Service Extension for Message Size Declaration (îbsoletes: RFC 1653)
• RFC 2505 – Anti-Spam Recommendations for SMTP MTAs (BCP 30)
• RFC 2920 – SMTP Service Extension for Command Pipelining (STD 60)
• RFC 3030 – SMTP Service Extensions for Transmission of Large and Binary MIME Messages
• RFC 3207 – SMTP Service Extension for Secure SMTP over Transport Layer Security (obsoletes RFC 2487)
• RFC 3461 – SMTP Service Extension for Delivery Status Notifications (obsoletes RFC 1891)
• RFC 3462 – The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (obsoletes RFC 1892)
• RFC 3463 – Enhanced Status Codes for SMTP (obsoletes RFC 1893 )
• RFC 3464 – An Extensible Message Format for Delivery Status Notifications (obsoletes RFC 1894)
• RFC 3834 – Recommendations for Automatic Responses to Electronic Mail
• RFC 4409 – Message Submission for Mail (obsoletes RFC 2476)
• RFC 4952 – Overview and Framework for Internationalized E-mail
• RFC 4954 – SMTP Service Extension for Authentication (obsoletes RFC 2554)
• RFC 5068 – E-mail Submission Operations: Access and Accountability Requirements (BCP 134)
• RFC 5321 – The Simple Mail Transfer Protocol (obsoletes RFC 821 aka STD 10, RFC 974, RFC 1869, RFC 2821)
• RFC 5322 – Internet Message Format (obsoletes RFC 822 aka STD 11, and RFC 2822)
• RFC 5336 - SMTP Extension for Internationalized Email Addresses (updates RFC 2821, RFC 2822, and RFC 4952)
• RFC 5504 - Downgrading Mechanism for Email Address Internationalization

Bacaan lanjut

• Hughes, L (1998). Internet e-mail Protocols, Standards and Implementation. Artech House Publishers. ISBN 0890069395.
• Hunt, C (2003). sendmail Cookbook. O'Reilly Media. ISBN 0596004710.
• Johnson, K (2000). Internet Email Protocols: A Developer's Guide. Addison-Wesley Professional. ISBN 0201432889.
• Loshin, P (1999). Essential Email Standards: RFCs and Protocols Made Practical. John Wiley & Sons. ISBN 0471345970.
• Rhoton, J (1999). Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP. Elsevier. ISBN 1555582125.
• Wood, D (1999). Programming Internet Mail. O'Reilly. ISBN 1565924797.

Pautan luar

• Essential Internet Protocols - SMTP Diarkibkan 2008-11-21 di Wayback Machine
• SMTP Sequence Diagram Diarkibkan 2010-12-15 di Wayback Machine (PDF)
• Diagram of e-mail flow Diarkibkan 2008-10-06 di Wayback Machine (PDF, PNG Diarkibkan 2006-10-13 di Wayback Machine )
• The Case For E-mail Security - Security and Insecurity in SMTP, POP and IMAP.
• Picture of the first computers to send and receive a network email, 2 PDP-10s Diarkibkan 2010-08-24 di Wayback Machine
• Email Address Internationalization IETF Working Group
• SMTP TLS Transport real-time test - Live version of above example, mostly for TLS (i.e. secure) email but useful for non-TLS too