Jika email hanya pengiriman "upaya terbaik", adakah protokol yang sama dengan pengiriman yang dijamin?

21

Dalam undang-undang sering ditetapkan bahwa faks adalah dokumen yang diterima karena pengirimannya 'dijamin', sedangkan e-mail bukan karena pengirimannya tidak. Bukankah ini hanya meminta protokol berbasis TCP yang menjamin pengiriman ke tingkat yang sama dengan yang dilakukan faks? Apakah protokol semacam itu ada, dan seberapa kuatnya itu?

network-protocols

— Jez
sumber

Pertanyaan menarik. Saya menemukan bahwa saya harus menjelaskan kepada pengguna akhir bahwa sistem email tidak sempurna, dan bahwa berbagai faktor dapat mempengaruhi pengiriman.

— ewwhite

3

Saya pikir Anda mencoba untuk datang dengan solusi teknologi untuk apa yang pada dasarnya masalah sosial. Anda tidak dapat menjamin penerima pesan benar-benar memperhatikan pesan itu, apakah pesan itu dikirim melalui faks atau melalui Internet.

— cjc

Masalah Dua Jenderal dijelaskan oleh Rocketboom: rocketboom.com/two-generals

— kzh

Pengiriman mana yang Anda bicarakan - dari sudut pandang teknis atau hukum? Jika Anda berbicara tentang sisi hukum, Anda harus menentukan negara juga.

— Smit Johnth

18

Pengiriman faks TIDAK dijamin - Ada banyak cara faks gagal. Untuk beberapa nama:
- Nomor salah arah
- Menerima faks dari kertas (dan tidak cukup pintar untuk menyadari)
- Menerima faks dari toner (dan tidak cukup pintar untuk menyadari)
- Kertas dimuat terbalik dalam mengirim faks
- Menerima faks adalah perangkat bersama dan faks yang diterima diambil dan dibuang oleh penerima yang tidak diinginkan
SMTP ADALAH protokol berbasis TCP. Silakan berkonsultasi dengan RFC 821 dan penggantinya RFC 2821 dan RFC 5321 .
Protokol jaringan yang mendasarinya (TCP / IP) tidak ada hubungannya dengan pengiriman yang andal (hal tingkat protokol aplikasi).
Sebagian besar server SMTP menyimpan log yang pesannya (pengirim / penerima / messageID) melewati mereka, yang dapat diterima di pengadilan jika Anda dapat menunjukkan bahwa log tidak mungkin dirusak.
Konsultasikan dengan pengacara .
Ada mekanisme yang melekat pada protokol SMTP dan program terkait untuk memastikan pengiriman (DSN, Return Receipts). Perhatikan bahwa ini sendiri adalah upaya terbaik / ekstensi kerja sama timbal balik (Sebagian besar klien email membiarkan Anda memilih untuk tidak mengirim tanda terima baca, dan beberapa klien tidak dapat mengeluarkan tanda terima baca. Beberapa MTA tidak dapat / tidak akan mengeluarkan tanda terima pengiriman.
Saya tidak yakin dengan keberterimaan ini - itu akan tergantung pada pengadilan dan preseden yang telah ditetapkan .. Sekali lagi, Konsultasikan dengan pengacara .

— voretaq7
sumber

Saya tidak mencoba menyiratkan bahwa SMTP tidak berbasis TCP.

— Jez

11

@ Josh - Saya cukup yakin Anda mengetahuinya, tetapi cara pertanyaan Anda diutarakan mengonfigurasikan dua masalah - transportasi datagram (TCP vs UDP) yang andal, dan pengiriman seluruh pesan (masalah aplikasi) yang andal. Ketika seseorang dengan sedikit petunjuk menemukan pertanyaan ini dalam setahun atau lebih, saya tidak ingin mereka mendapatkan ide yang salah :-)

— voretaq7

Dari sudut pandang hukum, pengiriman faks yang berhasil berarti pengiriman yang berhasil.

— Smit Johnth

@SmitJohnth Memiliki kesenangan tersendiri karena terlibat dalam litigasi di sekitar masalah itu, saya dapat memberi tahu Anda dengan pasti bahwa ada lebih dari itu daripada "Stasiun faks saya mengatakan bahwa pengirimannya berhasil" (khususnya titik peluru pertama yang saya catat akan mendapatkan pengiriman faks. keluar dengan andal, sama seperti Anda tidak dapat melayani pemberitahuan ke alamat yang salah dan mengklaim itu valid, juga poin terakhir adalah area pertikaian dalam ruang kerja bersama dengan mesin faks bersama - tidak yakin apakah preseden telah ditetapkan untuk itu , tapi sudah siap untuk argumen).

— voretaq7

@ voretaq7 Nah, Anda harus menentukan tanah yang Anda bicarakan. Berlawanan dengan lagu Rammstein, tidak ada orang yang tinggal di Amerrika :) AFAIK untuk tanah saya yang berhasil mengirim faks ke nomor yang benar berarti pengiriman yang sukses dari sudut pandang hukum.

— Smit Johnth

9

Sudah sering ditetapkan dalam undang-undang bahwa faks adalah dokumen yang diterima karena pengirimannya 'dijamin'

Log server email dari pengirim dan penerima mungkin lebih dapat diandalkan daripada konfirmasi penerimaan faks.

Konfirmasi hanya menyiratkan bahwa "a" faks menjawab dan menerima dokumen.

Log server dapat mengonfirmasi bahwa kotak surat "spesifik" itu menerima email dan masuk ke server A, B dan C sebelum masuk ke kotak surat "spesifik" itu.

Saya tahu bahwa di Kanada email diterima di pengadilan. Dalam kasus besar, gugatan hukum perdata dapat meminta Anton Piller Order dieksekusi untuk merebut log server dan konten kotak surat.

— Alex
sumber

3

Anda mendapatkan konfirmasi faks pada sisi pengiriman. Sedangkan konfirmasi pengiriman email yang berhasil hanya dapat dilihat di sisi penerima. Pengirim hanya tahu bahwa surat dikirim ke hop berikutnya (tetapi tidak ke tujuan).

— mailq

@mailq, saya setuju dengan Anda. Tetapi sekali lagi, konfirmasi faks tidak mengkonfirmasi bahwa itu berakhir di tujuan yang tepat juga. Itu sebabnya saya mengatakan bahwa log server pengirim dan penerima sama baiknya, jika tidak lebih baik daripada konfirmasi penerimaan dari faks.

— Alex

1

konfirmasi faks mengonfirmasi bahwa faks telah dikirim ke tujuan yang salah. Anda melihat nomor penerima. Bahwa itu angka yang salah bukanlah kesalahan teknologi tetapi merupakan kesalahan manusia.

— mailq

"Anda melihat nomor penerima" ... seperti yang diatur oleh penerima , bukan seperti yang diterima dari Caller-ID - dan karenanya tidak selalu nomor yang sebenarnya Anda panggil.

— Piskvor

@Piskvor: Sebagian besar mesin faks yang saya gunakan memasukkan nomor yang dihubungi di halaman konfirmasi pengiriman.

— jepret

4

Satu-satunya cara untuk memiliki pengiriman yang dijamin adalah pengiriman peer-to-peer langsung. Pengirim harus membuat koneksi langsung ke penerima dan penerima harus mengonfirmasi penerimaan. Email bukan protokol peer-to-peer tetapi protokol store-and-forward. Jadi tidak ada jaminan seperti itu yang diterima di pengadilan. Tetapi tentu protokol mencoba untuk dapat diandalkan dan jika semua server dalam rantai bermain dengan baik maka itu dapat diandalkan.

Namun jaminan pengiriman teknologi (dalam kehidupan nyata dan dalam surat / faks elektronik) tidak memberikan jaminan pada konten pesan. Log atau amplop hanya menunjukkan bahwa ada pengiriman tetapi tidak dapat menampilkan konten pesan. Bahkan jika Anda menandatangani pesan maka itu hanya dijamin tidak dimanipulasi di jalan. Tetapi konten yang ditandatangani asli masih bisa "Halo dunia!" bukannya "Kamu dipecat!" dan Anda hanya memiliki konfirmasi bahwa sebuah pesan telah dikirim.

— surat
sumber

3

Bukankah ini hanya meminta protokol berbasis TCP yang menjamin pengiriman ke tingkat yang sama dengan yang dilakukan faks? Apakah protokol semacam itu ada, dan seberapa kuatnya itu?

Untuk secara khusus menjawab pertanyaan - tidak ada protokol [jaringan] yang ada. Demikian juga tidak ada penguburan protokol tersebut.

Namun, terkait dengan topik ini, ada beberapa poin penting tentang apa yang orang maksudkan tentang apa artinya "jaminan" [pengiriman] atau mungkin:

Harus ada sarana untuk mengotentikasi pengirim. Namun, tidak ada fasilitas seperti itu di FAX atau proses hand-shaking email. Nomor "dari" FAX bisa dipalsukan karena alamat email "dari" ada dalam begitu banyak pesan spam / phishing.
Harus ada beberapa cara untuk memastikan tidak adanya penolakan pesan itu sendiri sehingga tidak dimodifikasi dalam perjalanan untuk bahkan membuktikan apa yang dikirim. Sekali lagi, protokol yang mendasarinya tidak membuat jaminan seperti itu. PKI (menggunakan teknologi tanda tangan digital dalam email, yang didukung dengan baik meskipun seringkali tidak digunakan karena kerumitan, sertifikat yang kedaluwarsa, dll.), Ditambah dengan enkripsi simetris dan hashing pesan sangat membantu memberikan penolakan pada email. Ini adalah metode yang tertanam baik tetapi tidak secara langsung di ruang komunikasi email pada umumnya.
Harus ada beberapa cara untuk menjamin pesan itu benar-benar dikirim ke penerima (yang dituju). Log sebenarnya tidak cukup karena mereka tidak membuat jaminan seperti di atas dan kemudian hanya dengan lemah menjelaskan pengiriman yang mungkin ditender ke kotak surat (bukan penerima). Ini bahkan lebih lemah dari pengiriman pos. Menurut Uniform Commercial Code (UCC) dalam hukum perdagangan komersial: selain pengiriman ke alamat yang disepakati, komunikasi pengiriman ke penerima yang dituju bahwa [barang / pesan] tersedia diperlukan. Email hanya menyimpan pesan di kotak surat target tetapi ini tidak menjamin penerima telah diberitahu tentang kedatangannya. Merupakan tanggung jawab penerima untuk terus-menerus 'memeriksa' jika pesannya tiba.

Terakhir, ada protokol email opsional (dan sebagian besar tidak didukung lintas platform) untuk meminta (pengirim) dan mengirim (penerima) konfirmasi pengiriman / tanda terima. Namun, ini jarang digunakan, tidak dijamin dan yang terakhir tidak menyangkal penerimaan pesan oleh penerima ... melainkan bahwa mereka mungkin telah memilih untuk tidak mengkonfirmasi tanda terima, tanda terima itu tidak diterima oleh pengirim atau pengiriman konfirmasi gagal antara sistem email yang tidak kompatibel yang tidak mendukung / versi yang sama dari fitur opsional ini.

— Darrell Teague
sumber

2

Banyak tempat yang membutuhkan pengiriman terjamin menggunakan IBM MQ Series atau produk Sterling Software (baru-baru ini dibeli oleh IBM)

— Wudang
sumber

Saya telah mengimplementasikan IBM MQ Series dan sistem pengiriman pesan yang lebih baru (TIBCO, Sterling Commerce, dkk) di beberapa perusahaan. Produk-produk ini memang memiliki fitur 'pengiriman terjamin' tetapi jika Anda membaca cetak-halus, definisi tersebut tidak terlalu berbalut besi. Memang ada beberapa kasus tepi di mana disposisi pesan dapat 'tidak diketahui' sehingga penerima MUNGKIN telah menerima pesan dan mungkin tidak. Biasanya ini terjadi ketika pesan sebenarnya dikirim, penerima merespons tetapi responsnya hilang sebelum / pada titik pengirim.

— Darrell Teague