Чому у нас все ще існують такі невеликі обмеження розміру файлів вкладень? [зачинено]

Що технічне обмеження заважає нам у славному 2011 році надсилати один одному файли 1 Гб?

Або це лише основні платформи електронної пошти, що тягнуть ноги?

Якщо я можу налаштувати свою папку "Вхідні" лише на заголовки, а потім на повне вкладення, якщо я хочу їх, у чому проблема?

Я відчуваю, що розміри вкладень електронної пошти застрягли в 1992 році ...

Проблема полягає в наступному: електронна пошта (SMTP / POP3 / IMAP / що-у вас є) - це стародавній, простий протокол, який спочатку призначений для надсилання очевидних повідомлень у надійну мережу. Використовувати його для надсилання або отримання великої кількості бінарних даних по сьогоднішньому Інтернету є злому, що повністю відрізняється від оригінального випадку використання, і він виконує досить жалюгідну роль у цій ролі.

Коли ви додаєте файл до електронної пошти, він кодується base64, що збільшує його розмір на 1/3. Таким чином, ваш 1 Гб файл стає ще на 300 Мб; також немає вбудованого стиснення до протоколу завантаження, таким чином, немає способу пришвидшити передачу (а в деяких випадках (SMTP для відправки, POP3 для отримання), навіть ніякого способу відновити порушену передачу - з'єднання розірвано на рівні 1,2 GB? Вибачте, вам потрібно все це знову передати). Більше того, SMTP - це протокол зберігання та передачі. Вгадай що? Так, файл 1,3 ГБ потрібно скопіювати на декілька серверів; кий безмежне щастя від адміністраторів поштового сервера.

Ця проблема була в 1990-х, коли не було корисної альтернативи (FTP? HTTP / 1.0? Puh-leeze); але у славному 2011 році, з різними способами безперебійного завантаження / завантаження даних до / з хмари (наприклад, Dropbox, Ubuntu One, Amazon S3, щоб назвати найвідоміші), виправдання "немає іншого корисного способу зробити це "вже не відповідає дійсності.

Зауважте також, що не кожен користується 100-Мбітним посиланням на Інтернет - наприклад, мобільний телефон та смартфон; не кожен поштовий клієнт може завантажувати тільки заголовки (наприклад , POP3 все ще багато користі), а не кожен користувач готовий завантажити 20 неминучі «Подивися на цьому GB відео funneh 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, торрент, youtube, хмарне сховище, darknet, вкладення, мул, розповсюджені файли, витримки, редакції) - це не нова ідея, вона просто ще не повністю тут або в одному творі. коли або якщо він надійде, ваш вкладення пошти буде просто вказівником на файл, який можна використовувати безпосередньо(наприклад, не файл .torrent, ані посилання) відеоплеєрами чи будь-яким іншим програмним забезпеченням. фактична обробка завантаження або зберігання контенту відбуватиметься прозоро, вміст може бути частково розташований з декількох джерел, визначених у маніфесті, який можна спільно ревізувати (наприклад, як .torrent-файл, але загальновизнаний і з обмеженою доступністю та обмеженнями локальності); фактичне завантаження та зберігання / кешування часто може бути частковим, залежно від того, яка частина була переглянута, і якщо ви навіть намагаєтеся отримати доступ до вмісту - так величезна прихильність вашої тещі не з'їсть жодної вашої пропускної здатності до дому якщо ви не шанувальник її електронних листів. Для постійності чи доступності, можливо, ви '