Neden hala bu kadar küçük e-posta eki dosya boyutu kısıtlamaları var? [kapalı]

2011 yılının görkemli yılında, birbirimize 1GB'lık dosyaları e-postayla göndermemizi engelleyen teknik sınırlama nedir?

Yoksa sadece ayaklarını sürükleyen ana e-posta platformları mı?

Gelen kutumu yalnızca başlıkları ve daha sonra tam ekleri tutacak şekilde ayarlayabilirsem sorun nedir?

1992'de e-posta eki boyutlarının sıkıştığını hissediyorum ...

Sorun şudur: e-posta (SMTP / POP3 / IMAP / neyin var), aslen güvenilir bir ağa düz metin mesajları göndermek için tasarlanmış eski, basit bir protokoldür. Bugünün interneti üzerinden büyük miktarlarda ikili veri göndermek veya almak için kullanmak, orijinal kullanım durumundan tamamen farklı olan cıvatalı bir kesmektir ve bu rolde oldukça sefil bir şekilde çalışır.

E-postaya bir dosya eklediğinizde, base64 kodlu olur, bu da boyutunu 1/3 oranında artırır. Böylece, 1 GB dosyanız 300 MB daha büyür; ayrıca indirme protokolünde dahili bir sıkıştırma yoktur, bu nedenle aktarımı hızlandırmanın bir yolu yoktur (ve bazı durumlarda (göndermek için SMTP, almak için POP3), hatta kırık bir aktarımı sürdürmenin bir yolu yoktur - bağlantı 1.2'de koptu Maalesef hepsini tekrar iletmeniz gerekiyor). Dahası, SMTP bir ileri-geri protokolüdür. Bil bakalım ne oldu? Evet, bu 1.3 GB dosyanın birden fazla sunucuya kopyalanması gerekiyor; posta sunucusu yöneticilerinden sınırsız mutluluğu işaretlemek.

Bu 1990'lı yıllarda yararlı bir alternatifin olmadığı bir problemdi (FTP? HTTP / 1.0? Puh-leeze); ancak, 2011 yılının görkemli yılında, bulut / veriyi sorunsuz bir şekilde / indiren çeşitli yöntemlerle (örneğin, Dropbox, Ubuntu One, Amazon S3, en bilinenleri isimlendirmek için), "bahanesi" "artık doğru değil.

Ayrıca herkesin İnternete 100 Mbit bağlantısı olmadığına da dikkat edin - örneğin mobil ve akıllı telefon; değil her posta istemcisi (örn POP3 çok hala kullanımda) sadece başlıklarını yükleme kapasitesine sahip olmasına değil, her kullanıcının 20 kaçınılmaz "Bu funneh 1 GB video göz" indirmek için istekli olduğunu Haftada e-postalar bu olacak (görünür insanlar sistemin izin verdiği kadar büyük dosyalar gönderecek ve evet, çoğu ISS'de FUP gibi bir şey var).

TL; DR : 1GB'lik bir dosyayı e-postayla göndermek gibi teknik olarak mümkün olsa da, bir tornavida kullanarak bir çiviye vurmak teknik olarak da mümkün olabilirdi - olduğu gibi, bunu yapmak için iyi bir yol değil. Bu tür görevler için daha uygun araçlar.

Aynı ancak biraz farklı bir bakış açısıyla:

E-posta elektronik postadır. Postayı başka bir küçük kağıt zarfın içindeki bu eski kağıt meselesi olarak biliyorsunuz. Üzerine çok fazla metin yazabilirsiniz ancak 5 veya 6 sayfadan fazla olamaz. Ve e-posta aynı ama elektroniktir. Metin (daktilodaki gibi düz metin) için tasarlanmıştır. Sonra bu süslü kırmızı yanıp sönen HTML postalarını gönderebileceğiniz bir MIME uzantısı vardı.

Dünyadaki hiç kimse şikayet edemez ve "Ah posta MS 1322’de olduğu gibi sıkışmış. Neden bir kağıt zarf içinde bir fil gönderemiyorum?" Bu nasıl. Bu tür şeyler için insanlar bir paket veya nakliye kabı gibi bir şey icat etti. Bu, mal ve fillerin nasıl gönderileceğidir. İnternet adamları FTP'yi (dosya aktarım protokolü) icat ettiler, adı aldınız mı?

Gerçek dünyada FTP'nin birçok alternatifi var çünkü FTP aynı zamanda büyük dezavantajları olan eski bir protokoldür (çoğunlukla güvenlikte ve dosya aktarmada değil). Ancak HTTP, meta verilerle merkezi bir belge depolama için geliştirildiği için bir alternatif değildir . Dosyaları indirip yükleyebilmeniz bunun acımasız bir uzantısıdır.

Yani metin göndermek için bir mektup ve mal göndermek için bir paket kullanın; bilgi göndermek için e-posta, dosya göndermek için dosya taşıma protokolleri kullanın.

Resimde kalmak için eklemeliyim: Yerel postanenizi filleri kağıt zarflar içinde kabul etmeye (ve ek ücreti ödemenize) ikna etseniz bile, filin teslim edilmesinde daha fazla taraf var. Onu bir sonraki postaneye taşıması gereken postacı var ve muhtemelen filin sığabileceği bir çantaya sahip değil. Belki de sırayla şöyle yazıyor: "Hayır. Filleri kabul etmiyoruz ".

Ne yapmalı o zaman? Gerçek dünyadaki iyi postacı fili ilk postaneye geri gönderir - daha sonra gönderene geri. (Elektronik dünyasında bu kötü bir postacı olurdu, çünkü fili vurup yalnızca ölüm belgesini gönderene geri vermesi gerekiyordu).

Böylece, gönderi zincirindeki tüm bağlantıları, filleri kabul etmeye ikna edebilseniz bile, alıcıyla karşı karşıya kalırsınız. Fili istediğini söyleyebilir ancak posta kutusu bir filin sığmayacağı kadar küçüktür. Göndericiye bir fil teslimatına yol açmıştır. (Fil gönderenin posta kutusuna sığmazsa ne olacağından bahsetmiyorum bile ...)

Yönetimin “e-posta boyutunda sınırsız” felsefesine abone olduğu Exchange 2007 ile ilgili bir durumda olmak:

Dahili bir kullanıcı hotmail adreslerine bir .iso müzik CD'si ile mesaj gönderdi. İletiyi işlerken bir taşıma sunucusunda kuyruğu sıkıştı, geri iletiyi aydınlatarak ileti gönderimini durdurdu. Kullanıcının görünüşü daha sonra, mesajı çalışmakta olan diğer taşıma sunucusuna usulca yeniden göndermiştir; geri baskı, mesaj gönderilmez.

Her iki aktarım sunucusu da iletiyi boğarken, tüm giden e-posta yaklaşık 90 saniye durdu. Hotmail, elbette, mesajı reddetti. Çok yakında bir boyut sınırı vardı.

İşte başka bir görünüm:

Bir e-posta, yol boyunca birden fazla durumda depolandığından, 1 GB'lik bir dosyayı göndermek, birkaç kez kullanmaya devam eder.

Genellikle "Gönderilen öğeler" deki müşterinizin bir kopyası olur ve IMAP kullanıyorsanız, sunucudaki bir kopya da (hesabınızda) görünebilir.

Daha sonra alıcı uç, alıcı uçtaki yerel istemcide olduğu gibi bir kopyayı da (sunucu) tutacaktır. IMAP kullanıyorsanız, sunucuda silinmez (bir kez daha).

Bu tek bir 1GB dosya için toplam 4 GB'dir. Tabii ki, bunun bir yedek olduğunu düşünebilirsiniz, ancak bunun için daha iyi seçenekler var. Kullanıcıların posta kutuları belirsiz bir şekilde büyüdüğü için sunucuda oluşabilecek yavaşlıktan bahsetmiyorum bile.

Ve ben sadece base64 kodlu bir dosya daha büyük olacağını farkettim (yaklaşık% 33 daha büyük sanırım).

Piskvor'un cevabını arttırmak için.

Evet, "ana e-posta platformları" ayaklarını sürüklüyor. Bunu, bugünün standartlarına uymayan bir protokol (SMTP) kullanarak yaparlar (birçok yönden).

Günümüz dünyasında, mevcut bağlantı sorununu çözecek SMTP'nin yerini alacak bir protokolü kolayca tasarlayabiliriz.

Sorun, dünyanın değişmesine neden olmaktı.

Bahsedilen sorun çoğunlukla verilerin depolanması ve iletilmesi ile ilgili lojistik sorunlardır - modern bulut soyutlamada, artık fiziksel olmanız gerekmeyen bir dosya - çeşitli depolama yöntemlerinin (örneğin yerel disk, ftp) etrafını sarmak için bir dosya tanıtıcısı soyutlaması kullanılabilir. , http, torrent, youtube, cloud storage, darknet, eklenti, katır, dağıtılmış fs, alıntılar, revizyonlar) - bu yeni bir fikir değil, henüz tam olarak burada ya da tek parça halinde değil. ulaştığında veya geldiğinde, posta ekiniz doğrudan kullanılabilecek bir dosya işaretçisi olacaktır.(örneğin .torrent dosyası veya bağlantı değil) video oynatıcılar veya herhangi bir yazılım tarafından. içerik indirme veya depolamanın fiili olarak ele alınması şeffaf bir şekilde gerçekleşecektir, içerik kısmen işbirliğine dayalı olarak yeniden gözden geçirilebilir bildirimlerde tanımlanan (örneğin bir .torrent dosyası gibi ancak evrensel olarak kabul edilen ve revize edilebilir mevcudiyet ve yer kısıtlamalarıyla) çoklu kaynaklardan yerleştirilebilir; hangi parçanın görüntülendiğine ve içeriğe erişmek için bile sorun yaşamanıza bağlı olarak gerçek indirme ve depolama / önbellekleme genellikle kısmi olabilir - bu nedenle kayınvalidenizin büyük eki kurum içi bant genişliğinizden hiçbirini yemez e-postalarının hayranı değilseniz. Kalıcılık veya kullanılabilirlik için belki siz