Почему у нас все еще есть такие маленькие ограничения на размер вложений электронной почты? [закрыто]

Какие технические ограничения мешают нам в славном 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, где руководство подписалось на философию «без ограничений по размеру электронной почты»:

Внутренний пользователь отправил сообщение на свой адрес электронной почты с .iso музыкального компакт-диска. Заклинило очередь на одном транспортном сервере при обработке сообщения, загорелось обратное давление, остановка отправки сообщения. Затем пользователь покорно повторно отправил сообщение другому работающему транспортному серверу; обратное давление, нет сообщений.

Поскольку оба транспортных сервера захлебнулись сообщением, вся исходящая электронная почта остановилась примерно на 90 секунд. Hotmail, конечно, отклонил сообщение. Вскоре после этого было установлено ограничение по размеру.

Вот еще один вид:

Поскольку электронное письмо хранится в нескольких экземплярах, отправка файла размером 1 ГБ израсходуется в несколько раз.

Обычно это будет копия на вашем клиенте в разделе «Отправленные», и при использовании IMAP копия на сервере также может отображаться (в вашей учетной записи).

Затем принимающая сторона будет хранить копию (сервер), а также на локальном клиенте на принимающей стороне. При использовании IMAP он не будет удален на сервере (еще раз).

Это в общей сложности 4 ГБ для одного файла 1 ГБ. Конечно, вы можете считать это резервной копией, но есть и лучшие варианты для этого. Не говоря уже о медлительности, которая может возникнуть на сервере, поскольку почтовые ящики пользователей увеличиваются до бесконечности.

И я только что понял, что если файл закодирован в base64, он будет еще больше (примерно на 33% больше, я думаю).

Дополнить ответ Писквора.

Да, «основные почтовые платформы» затягивают. Они делают это с помощью протокола (SMTP), который не соответствует современным стандартам (во многих отношениях).

В современном мире мы могли бы легко разработать протокол для замены SMTP, который бы решал текущую проблему с вложениями.

Проблема состоит в том, чтобы заставить мир переключиться на него.

Упомянутые проблемы - это в основном проблемы логистики с хранением и передачей данных - в современной облачной абстракции файл больше не должен быть физическим - абстракция дескриптора файла может использоваться для обертывания различных методов хранения (например, локальный диск, ftp , http, torrent, youtube, облачное хранилище, darknet, вложение, мул, распределенные фс, выдержки, ревизии) - это не новая идея, просто она пока не полностью или не в целости и сохранности. когда или если он прибудет, ваше почтовое вложение будет просто указателем файла, который можно использовать напрямую(например, не файл .torrent и не ссылка) от проигрывателей видео или любого другого программного обеспечения. фактическая обработка загрузки или хранения контента будет происходить прозрачно, контент может быть частично расположен из нескольких источников, определенных в совместном редактируемом манифесте (например, как файл .torrent, но общепринятый и с возможностью проверки доступности и ограничениями на локальность); фактическая загрузка и хранение / кэширование часто могут быть частичными, в зависимости от того, какая часть была просмотрена, и если вы даже не пытались получить доступ к контенту, поэтому огромная привязанность вашей свекрови не будет поглощать вашу пропускную способность в доме. если вы не фанат ее писем. Для постоянства или доступности, может быть, вы