¿Por qué todavía tenemos restricciones de tamaño de archivo adjunto de correo electrónico tan pequeñas? [cerrado]

¿Cuál es la limitación técnica que nos impide, en el glorioso año 2011, enviarnos correos electrónicos de 1GB?

¿O son solo las principales plataformas de correo electrónico arrastrando sus pies?

Si puedo configurar mi bandeja de entrada para tomar solo encabezados, y luego archivos adjuntos completos si los quiero, ¿cuál es el problema?

Siento que los tamaños de los archivos adjuntos de correo electrónico están atascados en 1992

El problema es este: el correo electrónico (SMTP / POP3 / IMAP / what-have-you) es un protocolo antiguo y simple originalmente destinado a enviar mensajes de texto sin formato en una red confiable. Usarlo para enviar o recibir grandes cantidades de datos binarios a través de Internet de hoy es un truco atornillado, completamente diferente del caso de uso original, y se desempeña bastante miserablemente en este rol.

Cuando adjunta un archivo al correo electrónico, se codifica en base64, lo que aumenta su tamaño en 1/3. Por lo tanto, su archivo de 1 GB se convierte en otro 300 MB más grande; Además, no hay una compresión integrada en el protocolo de descarga, por lo tanto, no hay forma de acelerar la transferencia (y en algunos casos (SMTP para enviar, POP3 para recibir), ni siquiera hay forma de reanudar una transferencia interrumpida: la conexión se rompió en 1.2 GB? Lo siento, debes volver a transmitirlo todo de nuevo). Además, SMTP es un protocolo de almacenamiento y reenvío. ¿Adivina qué? Sí, ese archivo de 1.3 GB debe copiarse en varios servidores; señala la felicidad ilimitada de los administradores del servidor de correo.

Esto fue un problema en la década de 1990, cuando no había una alternativa útil (FTP? HTTP / 1.0? Puh-leeze); pero en el glorioso año 2011, con varias formas de subir / descargar sin problemas datos a / desde la nube (por ejemplo, Dropbox, Ubuntu One, Amazon S3, por nombrar los más conocidos), la excusa de "no hay otra forma útil de hacer esto "ya no es cierto.

Tenga en cuenta también que no todos tienen un enlace de 100 Mbit a Internet, por ejemplo, dispositivos móviles y teléfonos inteligentes; No todos los clientes de correo es capaz de descargar sólo los encabezados (por ejemplo, POP3 es todavía en gran parte del uso), y no todos los usuarios está dispuesto a descargar el 20 "vistazo a este funneh 1 GB de vídeo" inevitable e-mails por semana que va a aparecer ( la gente enviará archivos tan grandes como el sistema les permita; y sí, hay algo así como FUP con la mayoría de los ISP).

TL; DR : si bien sería técnicamente posible hacer cosas como enviar por correo electrónico un archivo de 1 GB, también sería técnicamente posible clavar un clavo con un destornillador; simplemente no es una buena manera de hacerlo, ya que hay herramientas que son más adecuadas para tales tareas.

Lo mismo pero desde una vista ligeramente diferente:

El correo electrónico es correo electrónico. Usted conoce el correo como esta cosita de papel antigua en otro pequeño sobre de papel. Podría escribir mucho texto en él, pero no más de 5 o 6 páginas. Y el correo electrónico es igual pero electrónico. Está diseñado para texto (texto plano como en una máquina de escribir). Luego había una extensión MIME donde podía enviar estos elegantes correos HTML con parpadeo rojo.

Nadie en el mundo se quejaría y diría: "Oh, el correo se atascó como estaba en 1322 AD. ¿Por qué no puedo enviar un elefante en un sobre de papel?" Así es como es. Para este tipo de cosas, las personas inventaron algo como un paquete o un contenedor de transporte. Así es como se envían mercancías y elefantes. Y los chicos de Internet inventaron el FTP (protocolo de transferencia de archivos), ¿tienen el nombre?

En el mundo real, existen muchas alternativas a FTP porque FTP también es un protocolo antiguo con grandes desventajas (principalmente en seguridad y no en la transferencia de archivos). Pero HTTP es no una alternativa, ya que fue desarrollado para el almacenamiento centralizado de documentos con metadatos. Que pueda descargar y cargar archivos es una extensión brutal.

Por lo tanto, use una carta para enviar texto y un paquete para enviar productos; use el correo electrónico para enviar información y los protocolos de transporte de archivos para enviar archivos.

Para permanecer en la imagen, debo agregar: incluso si convence a su oficina de correos local de que acepte elefantes en sobres de papel (y pague la tarifa adicional), hay más partes involucradas entregando el elefante. Hay un cartero que tiene que llevarlo a la próxima oficina de correos y probablemente no tiene la bolsa adecuada para que quepa el elefante. Pero tal vez lo tiene y quiere entregarlo a la siguiente oficina de correos que a su vez dice: "No no aceptamos elefantes ".

¿Qué hacer entonces? El buen cartero en el mundo real llevaría al elefante de regreso a la primera oficina de correos, luego al remitente. (En el mundo electrónico, este sería un mal cartero porque debería haber disparado al elefante y solo entregar el certificado de defunción al remitente).

Entonces, incluso si pudiera convencer a todos los eslabones de la cadena de entrega posterior para que acepten elefantes, se enfrentará al destinatario. Podría decir que quiere el elefante, pero el buzón es demasiado pequeño para que quepa un elefante. Lo que lleva a una entrega de elefante de regreso al remitente. (Sin mencionar lo que sucede si el elefante no cabe en el buzón del remitente ...)

Habiendo estado en una situación con Exchange 2007 donde la administración se suscribió a la filosofía "sin límite en el tamaño del correo electrónico":

Un usuario interno envió un mensaje a su dirección de hotmail con un .iso de un CD de música. Atascó la cola en un servidor de transporte mientras procesaba el mensaje, encendió la contrapresión, deteniendo el envío del mensaje. La perspectiva del usuario luego volvió a enviar el mensaje al otro servidor de transporte que estaba funcionando; contrapresión, sin envío de mensajes.

Con ambos servidores de transporte atorados en el mensaje, todo el correo saliente se detuvo durante unos 90 segundos. Hotmail, por supuesto, rechazó el mensaje. Hubo un límite de tamaño establecido muy poco después.

Aquí hay otra vista:

Dado que un correo electrónico se almacena en varias instancias a lo largo del camino, enviar un archivo de 1 GB se consumiría varias veces hasta el final.

Por lo general, será una copia en su cliente en "Elementos enviados", y si usa IMAP, también podría aparecer una copia en el servidor (en su cuenta).

Luego, el extremo receptor mantendrá una copia (el servidor), así como el cliente local en el extremo receptor. Si usa IMAP, no se eliminará en el servidor (una vez más).

Eso es un total de 4 GB para un solo archivo de 1 GB. Por supuesto, puede considerarlo una copia de seguridad, pero también hay mejores opciones para eso. Sin mencionar la lentitud que puede ocurrir en el servidor porque los buzones de los usuarios crecen indefinidamente.

Y me acabo de dar cuenta de que si el archivo está codificado en base64, será aún más grande (aproximadamente un 33% más grande, supongo).

Para complementar la respuesta de Piskvor.

Sí, las "principales plataformas de correo electrónico" están arrastrando sus pies. Lo hacen utilizando un protocolo (SMTP) que no cumple con los estándares actuales (en muchos sentidos).

En el mundo de hoy, podríamos diseñar fácilmente un protocolo para reemplazar SMTP que resolvería el problema actual de los archivos adjuntos.

El problema sería lograr que el mundo lo cambiara.

El problema mencionado son principalmente problemas logísticos con el almacenamiento y la transmisión de datos: en la abstracción de la nube moderna, un archivo ya no necesita ser físico, se puede usar una abstracción de identificador de archivo para envolver varios métodos de almacenamiento (por ejemplo, disco local, ftp , http, torrent, youtube, almacenamiento en la nube, darknet, archivo adjunto, mula, fs distribuido, extractos, revisiones): esta no es una idea nueva, simplemente no está completamente aquí o de una pieza todavía. cuándo o si llega, su archivo adjunto de correo simplemente sería un puntero de archivo que puede usarse directamente(p. ej., no un archivo .torrent ni un enlace) por reproductores de video o cualquier software. el manejo real de la descarga o el almacenamiento de contenido se realizaría de forma transparente, el contenido puede ubicarse parcialmente de múltiples fuentes definidas en un manifiesto revisable en colaboración (por ejemplo, como un archivo .torrent pero aceptado universalmente, y con disponibilidad revisable y restricciones de localidad); La descarga real y el almacenamiento / almacenamiento en caché a menudo pueden ser parciales, dependiendo de qué parte se haya visto y si incluso se ha molestado en acceder al contenido, por lo que el gran archivo adjunto de su suegra no consumiría nada de su ancho de banda interno si no eres fanático de sus correos electrónicos. Por permanencia o disponibilidad, tal vez usted '