Por que ainda temos restrições de tamanho de arquivo de anexo de email tão pequenas? [fechadas]

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

Ou são apenas as principais plataformas de e-mail se arrastando?

Se eu posso configurar minha caixa de entrada para pegar apenas cabeçalhos e anexos completos, se eu quiser, qual é o problema?

Sinto que os tamanhos de anexo de e-mail estão bloqueados em 1992 ...

O problema é o seguinte: o email (SMTP / POP3 / IMAP / what-have-you) é um protocolo antigo e simples, originalmente destinado a enviar mensagens de texto sem formatação em uma rede confiável. Usá-lo para enviar ou receber grandes quantidades de dados binários pela Internet de hoje é um hack de acesso direto, completamente diferente do caso de uso original, e desempenha de maneira bastante miserável nessa função.

Quando você anexa um arquivo ao email, ele é codificado em base64, o que aumenta seu tamanho em 1/3. Assim, seu arquivo de 1 GB se torna outro 300 MB maior; Além disso, não há compactação embutida no protocolo de download, portanto, não há maneira de acelerar a transferência (e, em alguns casos (SMTP para envio, POP3 para recebimento), nem maneira de retomar uma transferência interrompida - a conexão foi interrompida em 1,2 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; sugestão felicidade ilimitada dos administradores do servidor de correio.

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

Observe também que nem todos estão em um link de 100 Mbit à Internet - por exemplo, celular e smartphone; nem todo cliente de email é capaz de baixar apenas os cabeçalhos (por exemplo, POP3 ainda está em muito uso), e não a cada usuário está disposto a baixar o "olhar para esta Funneh 1 GB de vídeo" 20 inevitável e-mails por semana, que irá aparecer ( as pessoas enviarão arquivos tão grandes quanto o sistema permitir; e sim, existe algo como o FUP com a maioria dos ISPs).

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

O mesmo, mas de uma visão um pouco diferente:

E-mail é correio eletrônico. Você conhece o correio como esse papel antigo em outro pequeno envelope de papel. Você pode escrever muito texto, mas não muito mais que 5 ou 6 páginas. E o email é o mesmo, mas eletrônico. Ele foi projetado para texto (texto sem formatação, como em uma máquina de escrever). Havia uma extensão MIME na qual você podia enviar esses e-mails em HTML piscantes em vermelho.

Ninguém no mundo iria reclamar e dizer: "Ah, as cartas ficaram do jeito que estavam em 1322 dC. Por que não consigo enviar um elefante em um envelope de papel?" É assim que é. Para esse tipo de coisa, as pessoas inventavam algo como um pacote ou um contêiner de transporte. É assim que se envia mercadorias e elefantes. E o pessoal da Internet inventou o FTP (protocolo de transferência de arquivos), entendeu o nome?

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

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

Para ficar na foto, devo acrescentar: Mesmo que você convença a agência de correios local a aceitar elefantes em envelopes de papel (e pague a taxa adicional), há mais pessoas envolvidas na entrega do elefante. Há o carteiro que precisa carregá-lo para a próxima agência postal e provavelmente ele não tem a bolsa certa para o elefante caber. Mas talvez ele tenha e queira entregá-la na próxima agência postal que, por sua vez, diz: "Não nós não aceitamos elefantes ".

O que fazer então? O bom carteiro do mundo real levaria o elefante de volta aos primeiros correios - de volta ao remetente depois. (No mundo eletrônico, isso seria um carteiro ruim, porque ele deveria ter matado o elefante e apenas entregar o certificado de morte ao remetente).

Portanto, mesmo se você conseguir convencer todos os links da cadeia de entrega pós-aceitação a aceitar elefantes, será confrontado com o destinatário. Ele poderia dizer que quer o elefante, mas a caixa de correio é muito pequena para caber um elefante. (Sem mencionar o que acontece se o elefante não couber na caixa de correio do remetente ...)

Tendo estado em uma situação no Exchange 2007 em que o gerenciamento se inscreveu na filosofia "sem limite de tamanho de email":

Um usuário interno enviou uma mensagem para o endereço do hotmail com um .iso de um CD de música. Atolou a fila em um servidor de transporte durante o processamento da mensagem, aumentou a pressão, interrompendo o envio da mensagem. A perspectiva do usuário reenviou a mensagem de forma respeitosa para o outro servidor de transporte que estava funcionando; contrapressão, sem envio de mensagem.

Com os dois servidores de transporte bloqueando a mensagem, todos os emails de saída são interrompidos por cerca de 90 segundos. O Hotmail, é claro, rejeitou a mensagem. Havia um limite de tamanho em vigor logo depois.

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 consumiria várias vezes o tempo todo.

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

Em seguida, a extremidade receptora manterá uma cópia (o servidor), assim como o cliente local na extremidade receptora. Se você usar o IMAP, ele não será excluído no servidor (mais uma vez).

Isso significa um total de 4 GB para um único arquivo de 1 GB. Obviamente, você pode considerá-lo um backup, mas também existem opções melhores. Sem mencionar a lentidão que pode ocorrer no servidor porque as caixas de correio dos usuários aumentam indefinidamente.

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

Para complementar a resposta de Piskvor.

Sim, as "principais plataformas de email" estão se arrastando. Eles fazem isso usando um protocolo (SMTP) que não está de acordo com os padrões atuais (de várias maneiras).

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

O problema seria levar o mundo a mudar para ele.

O problema mencionado são principalmente questões de logística com armazenamento e transmissão de dados - na abstração moderna da nuvem, um arquivo não precisa mais ser físico - uma abstração de manipulação de arquivo pode ser usada para contornar vários métodos de armazenamento (por exemplo, disco local, ftp , http, torrent, youtube, armazenamento em nuvem, darknet, anexo, mula, fs distribuídos, trechos, revisões) - essa não é uma idéia nova, mas ainda não está totalmente aqui ou em uma única peça. quando ou se 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 reprodutores 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 a partir de várias fontes definidas no manifesto revisável de forma colaborativa (por exemplo, como um arquivo .torrent, mas universalmente aceito e com restrições de disponibilidade e localidade revisáveis); o download e o armazenamento / armazenamento em cache reais geralmente podem ser parciais, dependendo de qual parte foi visualizada e se você sequer se preocupou em acessar o conteúdo - para que o enorme anexo da sua sogra não consuma nenhuma largura de banda da sua casa se você não é fã dos e-mails dela. Para permanência ou disponibilidade, talvez você