Какие технические ограничения мешают нам в славном 2011 году пересылать друг другу по электронной почте файлы размером 1 ГБ?
Или это просто основные почтовые платформы затягивают?
Если я могу настроить свой почтовый ящик для захвата только заголовков, а затем полных вложений, если они мне нужны, в чем проблема?
Мне кажется, что размеры вложений электронной почты застряли в 1992 году ...
Проблема в следующем: электронная почта (SMTP / POP3 / IMAP / what-have-you) - это древний простой протокол, изначально предназначенный для отправки текстовых сообщений в доверенной сети. Использование его для отправки или получения больших объемов двоичных данных через современный Интернет - это надуманный хакер, полностью отличный от первоначального варианта использования, и в этой роли он работает довольно плохо.
Когда вы прикрепляете файл к электронному письму, он кодируется в кодировке base64, что увеличивает его размер на 1/3. Таким образом, ваш файл размером 1 ГБ станет больше на 300 МБ; Кроме того, в протоколе загрузки нет встроенного сжатия, поэтому нет способа ускорить передачу (а в некоторых случаях (SMTP для отправки, POP3 для получения), даже нет возможности продолжить сорванная передача - оборвалась связь на 1,2 гб? Извините, вам нужно все это повторно передать). Более того, SMTP - это протокол с промежуточным хранением. Угадай, что? Да, этот файл размером 1,3 ГБ необходимо скопировать на несколько серверов; реплика безграничного счастья от админов почтового сервера.
Это было проблемой в 1990-х годах, когда не было полезной альтернативы (FTP? HTTP / 1.0? Puh-leeze); но в славном 2011 году с различными способами беспрепятственной загрузки / загрузки данных в / из облака (например, Dropbox, Ubuntu One, Amazon S3, чтобы назвать наиболее известные), оправдание «нет другого полезного способа сделать это "больше не соответствует действительности.
Также обратите внимание, что не все подключены к Интернету на 100 Мбит - например, мобильный и смартфон; не каждый почтовый клиент способен загружать только заголовки (например, POP3 все еще широко используется), и не каждый пользователь готов загружать 20 неизбежных электронных писем «посмотрите на это видео размером 1 ГБ» в неделю, которые воля появляются (люди будут отправлять файлы настолько большого размера, насколько позволяет им система; и да, у большинства интернет-провайдеров есть что-то вроде FUP).
TL; DR: хотя было бы технически возможно делать такие вещи, как отправка файла размером 1 ГБ по электронной почте, технически также можно было бы забить гвоздь с помощью отвертки - это просто не лучший способ сделать это, поскольку есть инструменты, которые больше подходит для таких задач.
То же, но с немного другой точки зрения:
Электронная почта - это электронная почта. Вы знаете почту как эту древнюю бумажную штуковину в другом маленьком бумажном конверте. На нем можно было написать много текста, но не более 5-6 страниц. И электронная почта такая же, но электронная. Он предназначен для текста (обычный текст, как на пишущей машинке). Затем было расширение MIME, с помощью которого можно было отправлять эти причудливые мигающие красным HTML-сообщения.
Никто в мире не станет жаловаться и говорить: «О, почта застряла так же, как в 1322 году нашей эры. Почему я не могу отправить слона в бумажном конверте?» Так оно и есть. Для такого рода вещей люди изобрели что-то вроде пакета или транспортного контейнера. Это как отправить товар и слонов. И ребята из Интернета изобрели FTP (протокол передачи файлов), получил название?
В реальном мире существует множество альтернатив FTP, потому что FTP также является древним протоколом с большими недостатками (в основном с точки зрения безопасности, а не с передачей файлов). Но HTTP - это не альтернатива, поскольку она была разработана для централизованного хранения документов с метаданными. То, что вы можете скачивать и выгружать файлы, является жестоким расширением этого.
Поэтому используйте письмо для отправки текста и пакет для отправки товаров; использовать электронную почту для отправки информации и протоколы передачи файлов для отправки файлов.
Чтобы оставаться в курсе, я должен добавить: даже если вы убедите местное почтовое отделение принять слонов в бумажных конвертах (и заплатить дополнительную плату), доставка слона будет вовлечена в большее количество сторон. Есть почтальон, который должен отнести его в следующее почтовое отделение, и, вероятно, у него нет подходящей сумки для слона. Но, возможно, он имеет и хочет доставить его в следующее почтовое отделение, которое, в свою очередь, говорит: «Нет. мы не принимаем слонов ».
Что тогда делать? Хороший почтальон в реальном мире отнесет слона обратно в первое почтовое отделение, а потом обратно отправителю. (В электронном мире это было бы плохой почтальон, потому что он должен был застрелить слона и доставить только свидетельство о смерти отправителю).
Таким образом, даже если вам удастся убедить все звенья в цепочке почтовой доставки принять слонов, вы столкнетесь с получателем. Он мог бы сказать, что хочет слона, но почтовый ящик слишком мал для слона. Это приведет к доставке слона обратно отправителю. (Не говоря уже о том, что происходит, если слон не помещается в почтовый ящик отправителя ...)
Попав в ситуацию с Exchange 2007, когда руководство придерживалось философии «без ограничений на размер электронной почты»:
Внутренний пользователь отправил на свой адрес hotmail сообщение с .iso музыкального компакт-диска. Заклинило очередь на одном транспортном сервере при обработке сообщения, загорелось противодавление, остановка отправки сообщения. Затем внешний вид пользователя послушно повторно отправил сообщение на другой работающий транспортный сервер; противодавление, без отправки сообщения.
Поскольку оба транспортных сервера блокируют сообщение, вся исходящая электронная почта останавливается примерно на 90 секунд. Hotmail, конечно же, отклонил это сообщение. Вскоре после этого было введено ограничение на размер.
Вот еще одна точка зрения:
Поскольку электронное письмо хранится в нескольких экземплярах, отправка файла размером 1 ГБ будет израсходована в несколько раз.
Обычно это копия на вашем клиенте в разделе «Отправленные», а при использовании IMAP копия на сервере также может отображаться (в вашей учетной записи).
Тогда принимающая сторона будет хранить копию (сервер), а также у локального клиента на принимающей стороне. Если используется IMAP, то он не будет удален на сервере (еще раз).
Это всего 4 ГБ для одного файла размером 1 ГБ. Конечно, вы можете считать это резервной копией, но есть и лучшие варианты для этого. Не говоря уже о медлительности, которая может возникнуть на сервере, потому что почтовые ящики пользователей бесконечно растут.
И я только что понял, что если файл закодирован в base64, он будет еще больше (примерно на 33% больше, я думаю).
В дополнение к ответу Писквора.
Да, «основные почтовые платформы» медлят. Они делают это, используя протокол (SMTP), который не соответствует сегодняшним стандартам (во многих отношениях).
В современном мире мы могли бы легко разработать протокол, заменяющий SMTP, который решал бы текущую проблему с подключением.
Проблема будет в том, чтобы заставить мир переключиться на это.
Упомянутая проблема в основном связана с логистическими проблемами с хранением и передачей данных - в современной облачной абстракции файл больше не должен быть физическим - абстракция дескриптора файла может использоваться для обертывания различных методов хранения (например, локальный диск, ftp , http, torrent, youtube, облачное хранилище, даркнет, вложение, mule, распределенная файловая система, выдержки, версии) - это не новая идея, просто она еще не полностью здесь и не целиком. когда или если он придет, ваше почтовое вложение будет просто указателем на файл, который можно использовать прямо (например, не файл .torrent и не ссылка) с помощью видеоплееров или другого программного обеспечения. фактическая обработка загрузки или хранения контента будет происходить прозрачно, контент может быть частично расположен из нескольких источников, определенных в совместно редактируемом манифесте (например, как файл .torrent, но общепринятый, и с изменяемыми ограничениями доступности и местоположения); фактическая загрузка и хранение / кеширование часто могут быть частичными, в зависимости от того, какая часть просматривалась, и если вы даже потрудились получить доступ к контенту - чтобы огромное вложение вашей тещи не съело ни одну из ваших домашних пропускных способностей если вы не поклонник ее писем. Для постоянства или доступности, возможно, у вас будет почтовый клиент, который сможет фильтровать и пересматривать манифест хранилища, что затем приведет к перемещению определенного неоткрытого вложения из его источников в ваше облачное хранилище, например, когда его доступность уменьшается.