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

52

¿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

Dibujó
fuente
23
¿Tamaños de accesorios atascados en 1992? Puh-leeze. Me gustaría verte transferir un archivo de 50 MB en 1992, por cualquier método disponible, y mucho menos adjuntarlo a un correo electrónico (sí, tengo varios correos electrónicos de este mes actual en 2011, no, yo No estoy muy feliz por eso). Sugerencia: el método preferido, en 1992, podría haber incluido copiar a la cinta y conducir al destino, o tal vez una conexión telefónica y una uucpsesión durante toda la noche .
Piskvor
44
@Piskvor: Alternativamente, una bolsa de supermercado llena de discos que contienen archivos arj de varios volúmenes. Sin relación alguna
sum1stolemyname
17
El ancho de banda tiene poco o nada que ver con eso; Si lo que tiene que comunicar con otra persona es mayor de 20 megabytes, el correo electrónico no es la forma de enviarlo .
Shadur
2
@Shadur: lo hace, en caso de correo no deseado: un enlace en un correo electrónico (que el destinatario elige hacer clic o no) toma miles de bytes en el extremo; un archivo adjunto en un correo electrónico, en la mayoría de los casos, se descarga sin preguntar (conozco las capacidades de IMAP a este respecto, pero la mayoría de los usuarios tienen este conjunto para "descargar todo", lo que afectaría un poco el ancho de banda, también se usa para otros fines además del correo: la queja habitual de los usuarios que no son de TI antes de la banda ancha: "¿Por qué mi web es tan lenta? Sí, envié un correo electrónico de 10 MB con cerdos bailando con 100 personas en BCC, ¿cómo es eso relevante? ")
Piskvor
44
@Piskvo "Nunca subestimes el ancho de banda de un camión lleno de cintas"; tan cierto hoy como siempre: puede obtener> 1 TB en una cinta ...
Richard

Respuestas:

163

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.

Piskvor
fuente
10
+1 Esa es una muy, muy buena respuesta :)
Antoine Benkemoun
1
Enlace de 100Mb? A menos que sea una corporación, nadie tiene un enlace de 100Mb aquí en Australia.
Matthew Scharley el
15
+1 para la versión TLDR :-)
Mónica
2
A mi cliente de correo electrónico le encantaría un archivo de 1GB codificado en base64.
Prisionero el
3
+1 no hay forma de reanudar una transferencia rota.
mr_eclair
32

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.


Editar:

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 ...)

mailq
fuente
18
Ven en ! Mientras exista el Content-Type: application/x-pachydermencabezado, HTTP es perfectamente capaz de transmitir elefantes;) Buenos puntos, aunque mi protocolo de elección sería rsync: razonablemente bien disponible, permite la compresión, las sincronizaciones delta, la transferencia continua, además funciona bien con SSH (para auth + cifrado).
Piskvor
1
Incluso un enfoque P2P es razonable. Depende de la audiencia. La multidifusión de un archivo a través del correo electrónico debe hacer sonar la alarma de todos. Y como dijiste en otras palabras, uno no debería seguir este enfoque: "Si solo tienes un martillo, entonces cada problema parece un clavo".
mailq
Hmm, sí, para múltiples destinatarios, por ejemplo, los torrents tienen mucho sentido; pero en mi experiencia, todavía necesita un respaldo (¿FTP? ¿HTTP?) para aquellos usuarios que no conocen todos estos protocolos de transferencia novedosos. Depende de la audiencia, como dijiste.
Piskvor
17

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.

Shane Madden
fuente
En algún momento de los años 90 recibí un correo electrónico de 20 MB. el correo electrónico se entregó realmente a mi buzón, pero el servidor devolvió un error de tamaño 4.5.1. en ese momento el servidor remitente vuelve a enviar el mensaje. creando un bucle que se repitió hasta que mi buzón o nuestro servidor estaba lleno y el administrador tuvo que arreglarlo manualmente eliminando el correo de la cola.
eMBee
5

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).

jishi
fuente
4

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.

usuario606723
fuente
-2

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 '

Alife Toy
fuente
2
Por mucho que odie la terminología de "nube", su descripción es medio cierta; pero todavía hay requisitos de transferencia (ancho de banda), almacenamiento incluso si es solo intermedio, y la falta de presencia en un servidor "local" podría inducir un retraso significativo. Incluso si el destinatario nunca accede al archivo, el remitente original todavía tiene que transmitir el archivo completo "a la nube", la "nube" debe contener todo el archivo (tal vez indefinidamente), y las estructuras para comunicar todo esto tiene que ser puesto en su lugar. Si reinventamos la rueda, se podría hacer mejor que esto.
Chris S
1
"un archivo ya no necesita ser físico" - espera mientras me deshago de mis discos, ya que ya no son necesarios para esos archivos espirituales ;) Tienes un buen punto de que el almacenamiento y la transferencia se pueden extraer , pero están simplemente escondidos en algún lugar por la abstracción, no se han ido. Necesitaría una tubería realmente gruesa para aliviar la latencia de acceso a los archivos, por ejemplo, comience a reproducir un video HD, busque en el medio, gire los pulgares durante minutos mientras se transmiten los datos solicitados (en lugar de meros milisegundos para el almacenamiento local) . Y también está la molesta velocidad de la luz de un pie por nanosegundo.
Piskvor
cierto: todo esto podría ser bastante lento si la localidad o la disponibilidad no se definen o implementan bien. pero el usuario puede definirlos y asumir cierta responsabilidad por varias compensaciones de velocidad, ancho de banda, disponibilidad, etc., utilizando políticas preempaquetadas, reglas de filtro, atributos, etiquetas, reglas de inferencia. cuando envío un correo electrónico con un archivo adjunto, no necesito 'cargarlos', ya que los datos simplemente están disponibles para el receptor, luego los datos se mueven o se replican en discos y / o almacenamiento en la nube según el comportamiento de dos partes reglas de inferencia configuradas por el usuario de 'administradores de almacenamiento'.
Alife Toy
"el usuario puede definirlos y asumir cierta responsabilidad" - Debe ser un administrador.
Chris S
no gerente pero algo mucho peor - un futurista roto
Alife Toy