Por que ainda temos restrições tão pequenas quanto ao tamanho do arquivo de anexos de e-mail? [fechadas]

Question

Qual é a limitação técnica que nos impede, no glorioso ano de 2011, de enviar um para o outro arquivos de 1GB?

Ou são apenas as principais plataformas de email que arrastam os pés?

Se eu puder definir minha caixa de entrada para pegar apenas cabeçalhos e, em seguida, anexos completos, se eu quiser, qual é o problema?

Sinto que os tamanhos dos anexos de e-mail estão comprometidos em 1992 ...

    

Answer 1

O problema é o seguinte: o e-mail (SMTP / POP3 / IMAP / what-have-you) é um protocolo antigo e simples, originalmente destinado ao envio de mensagens em texto simples em uma rede confiável. Usá-lo para enviar ou receber grandes quantidades de dados binários através da Internet de hoje é um hack aparafusado, completamente diferente do caso de uso original, e desempenha um papel miserável nessa função.

Quando você anexa um arquivo ao e-mail, ele recebe o código base64, que aumenta seu tamanho em 1/3. Assim, o seu arquivo de 1 GB se torna mais 300 MB maior; Além disso, não há compressão interna para o protocolo de download, portanto, não há maneira de acelerar a transferência (e, em alguns casos (SMTP para envio, POP3 para receber), até mesmo nenhuma maneira de retomar um transferência quebrada - a conexão quebrou em 1,2 GB? Desculpe, você precisa retransmitir tudo novamente). Além disso, o SMTP é um protocolo de armazenamento e encaminhamento. Adivinha? Sim, esse arquivo de 1,3 GB precisa ser copiado em vários servidores; citar a felicidade ilimitada dos administradores do servidor de e-mail.

Este foi um problema na década de 1990, quando não havia alternativa útil (FTP? HTTP / 1.0? Puh-leeze); mas no glorioso ano 2011, com várias maneiras de fazer o download / download de dados para / da nuvem (por exemplo, Dropbox, Ubuntu One, Amazon S3, para nomear os mais conhecidos), a desculpa de "não há outra maneira útil de fazer isso "não é mais verdade.

Note também que nem todos estão em um link de 100 Mbits para a Internet - por exemplo, celular e smartphone; nem todo cliente de e-mail é capaz de baixar apenas os cabeçalhos (por exemplo, o POP3 ainda é muito usado), e nem todo usuário está disposto a baixar os 20 inevitáveis "olhar para este vídeo de 1 GB de funneh" por semana que will aparecerá (as pessoas enviarão arquivos grandes como o sistema permitirá; e, sim, há algo como o FUP com a maioria dos ISPs).

TL; DR : embora seja tecnicamente possível fazer coisas como enviar por e-mail um arquivo de 1GB, também seria tecnicamente possível bater em um prego usando uma chave de fenda - não é uma boa maneira de fazer isso, pois há ferramentas mais adequadas para essas tarefas.

    

Answer 2

O mesmo, mas de uma perspectiva ligeiramente diferente:

Email é correio eletrônico. Você sabe o correio como este papel antigo em outro pequeno envelope de papel. Você pode escrever muito texto, mas não mais que 5 ou 6 páginas. E e-mail é o mesmo, mas eletrônico. Ele é projetado para texto (texto simples como em uma máquina de escrever). Em seguida, havia uma extensão MIME onde você poderia enviar esses e-mails HTML vermelhos piscando.

Ninguém no mundo se queixaria e diria "O correio ficou preso como estava em 1322 DC. Por que não posso enviar um elefante em um envelope de papel?" É assim que é. Para esse tipo de coisa, as pessoas inventaram algo como um pacote ou um contêiner de transporte. Isto é como enviar mercadorias e elefantes. E os caras da Internet inventaram o FTP (protocolo de transferência de arquivos), conseguiram o nome?

No mundo real, existem muitas alternativas ao FTP, porque o FTP também é um protocolo antigo com grandes desvantagens (principalmente na segurança e não na transferência de arquivos). Mas o HTTP não é uma alternativa, pois foi desenvolvido para armazenamento centralizado de documentos com metadados. Que você pode baixar e enviar arquivos é uma extensão brutal para ele.

Portanto, use uma carta para enviar texto e um pacote para enviar mercadorias; use e-mail para enviar informações e protocolos de transporte de arquivos para enviar arquivos.

Editar:

Para ficar na foto, tenho que acrescentar: Mesmo se você convencer seus correios locais a aceitar elefantes em envelopes de papel (e pagar a taxa adicional), haverá mais partes envolvidas entregando o elefante. Existe o carteiro que tem que levá-lo para o próximo posto de correios e provavelmente ele não tem a mala certa para o elefante se encaixar. Mas talvez ele tenha e queira entregá-lo ao próximo posto de correios que diz: "Não nós não aceitamos elefantes ".

O que fazer então? O bom carteiro no mundo real levaria o elefante de volta ao primeiro correio - de volta ao remetente depois. (No mundo eletrônico, isso seria um carteiro ruim porque ele deveria ter atirado no elefante e só entregar o certificado de morte ao remetente).

Assim, mesmo que você consiga convencer todos os elos da cadeia de entrega posterior a aceitar elefantes, você se depara com o destinatário. Ele poderia dizer que quer o elefante, mas a caixa de correio é pequena demais para um elefante se encaixar. Levando a uma entrega de elefante do retorno ao remetente. (Sem mencionar o que acontece se o elefante não couber na caixa de correio do remetente ...)

    

Answer 3

Tendo estado em uma situação com o Exchange 2007, onde o gerenciamento se inscreveu na filosofia "sem limite de tamanho do email":

Um usuário interno enviou uma mensagem para o endereço de hotmail com um CD de áudio .iso. Congestionou a fila em um servidor de transporte durante o processamento da mensagem, diminuiu a pressão de retorno, parando o envio da mensagem. A perspectiva do usuário então submetia novamente a mensagem ao outro servidor de transporte que estava funcionando; contrapressão, sem envio de mensagens.

Com os dois servidores de transporte sufocando na mensagem, todo o email de saída foi interrompido por cerca de 90 segundos. O Hotmail, é claro, rejeitou a mensagem. Houve um limite de tamanho em breve.

    

Answer 4

Aqui está outra visão:

Como um email é armazenado em várias instâncias ao longo do caminho, o envio de um arquivo de 1 GB é usado várias vezes até o fim.

Geralmente, será uma cópia do seu cliente em "Itens enviados" e, se você usar o IMAP, uma cópia no servidor também poderá ser exibida (na sua conta).

Em seguida, o terminal de recebimento manterá uma cópia (o servidor), bem como o cliente local no terminal de recebimento. Se estiver usando o IMAP, ele não será excluído no servidor (mais uma vez).

Esse é um total de 4 GB para um único arquivo de 1 GB. Claro, você pode considerar um backup, mas também há opções melhores para isso. Sem mencionar a lentidão que pode ocorrer no servidor porque as caixas de correio dos usuários crescem indefinidamente.

E eu acabei de perceber que, se o arquivo for codificado em base64, ele será ainda maior (aproximadamente 33% maior, eu acho).

    

Answer 5

Para suplementar a resposta de Piskvor.

Sim, as "principais plataformas de email" estão a arrastar os pés. Eles fazem isso usando um protocolo (SMTP) que não está de acordo com os padrões atuais (em muitos aspectos).

No mundo de hoje, poderíamos criar facilmente um protocolo para substituir o SMTP que resolveria o problema atual de anexo.

O problema seria fazer o mundo mudar para ele.

    

Answer 6

O problema mencionado é principalmente problemas logísticos com armazenamento e transmissão de dados - na abstração moderna de nuvem, um arquivo não precisa mais ser físico - uma abstração de identificador de arquivo pode ser usada para envolver vários métodos de armazenamento (por exemplo, local disco, ftp, http, torrent, youtube, armazenamento em nuvem, darknet, anexo, mula, fs distribuído, trechos, revisões) - isso não é uma idéia nova, não é apenas totalmente aqui ou em um pedaço ainda. quando ou se ele chegar, seu anexo de e-mail seria simplesmente um ponteiro de arquivo que pode ser usado diretamente (por exemplo, não um arquivo .torrent nem um link) por players de vídeo ou qualquer outro software. o manuseio real do download ou armazenamento de conteúdo aconteceria de forma transparente, o conteúdo pode ser parcialmente localizado de várias fontes definidas no manifesto de revisibilidade colaborativa (por exemplo, como um arquivo .torrent, mas universalmente aceito e com restrições de disponibilidade e localidade revisíveis); o download / armazenamento / armazenamento em cache reais podem ser parciais, dependendo de qual parte foi visualizada e se você se incomodou em acessar o conteúdo - assim, a grande ligação da sua sogra não consumiria nada da sua largura de banda interna. se você não é fã de seus e-mails. Para permanência ou disponibilidade, talvez você tenha um cliente de e-mail que possa filtrar e revisar o manifesto de armazenamento que resultará na realocação de certos anexos não abertos de suas fontes para o armazenamento em nuvem quando a disponibilidade diminuir, por exemplo