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

52

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

Desenhou
fonte
23
Tamanhos de acessórios presos em 1992? Puh-leeze. Gostaria que você transferisse um arquivo de 50 MB em 1992, por qualquer método disponível, e muito menos anexá-lo a um e-mail (sim, eu tenho vários e-mails desse mês atual em 2011, não, eu não estou muito feliz com isso). Dica: o método preferido, em 1992, poderia incluir copiar em fita e dirigir até o destino, ou talvez uma discagem e uucpsessão a noite toda .
Piskvor
4
@Piskvor: Como alternativa, uma sacola cheia de discos contendo arquivos arj de vários volumes. Tipo não relacionado: cs-exhibitions.uni-klu.ac.at/index.php?id=187
sum1stolemyname
17
A largura de banda tem pouco ou nada a ver com isso; se o que você precisa para se comunicar com outra pessoa for maior que 20 megabytes, o email não é o caminho para enviá-lo .
Shadur
2
@Shadur: no caso de mensagens indesejadas - um link em um email (no qual o destinatário escolhe clicar ou não) leva milhares de bytes no extremo; um arquivo anexado em um email é, na maioria dos casos, baixado sem aviso prévio (estou ciente dos recursos do IMAP a esse respeito, mas a maioria dos usuários tem esse conjunto para "baixar tudo", o que afetaria um pouco a largura de banda - também é usado para outros fins além do correio: a reclamação usual dos usuários que não são de TI antes da banda larga: "Por que minha web é tão lenta? Sim, enviei um email de 10 MB com porcos dançarinos com 100 pessoas no BCC, como isso é relevante? ")
Piskvor 24/08
4
@Piskvo "Nunca subestime a largura de banda de um caminhão cheio de fitas"; tão verdadeiro hoje como sempre: você pode obter> 1TB em uma fita ....
Richard

Respostas:

163

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.

Piskvor
fonte
10
+1 Essa é uma muito boa resposta :)
Antoine Benkemoun
11
Link de 100Mb? A menos que você seja uma empresa, ninguém tem um link de 100Mb aqui na Austrália.
Matthew Scharley
15
+1 para a versão TLDR :-)
Restabelece Monica
2
Meu cliente de email adoraria um arquivo de 1 GB codificado em base64.
Prisoner
3
Marcar com +1 nenhuma maneira de retomar uma transferência interrompida.
Mr_eclair
32

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.


Editar:

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

mailq
fonte
18
Vamos ! Enquanto houver o Content-Type: application/x-pachydermcabeçalho, o HTTP é perfeitamente capaz de transmitir elefantes;) Bons pontos, embora meu protocolo de escolha seja rsync- razoavelmente bem disponível, permite compactação, sincronização delta, transferência contínua, além de funcionar bem com SSH (para auth + criptografia).
Piskvor
11
Mesmo uma abordagem P2P é razoável. Depende da audiência. A transmissão múltipla de um arquivo por email deve tocar a campainha de alarme de todos. E, como você disse em outras palavras, não se deve seguir esta abordagem: "Se você tem um martelo, todo problema parece um prego".
mailq
Hmm, sim - para vários destinatários, por exemplo, torrents fazem muito sentido; mas, na minha experiência, você ainda precisa de um fallback (FTP? HTTP?) para os usuários que não têm conhecimento de todos esses novos protocolos de transferência. Depende da audiência, como você disse.
Piskvor
17

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.

Shane Madden
fonte
em algum momento dos anos 90, recebi um email de 20 MB. o email foi realmente entregue na minha caixa de correio, mas o servidor retornou um erro de tamanho 4.5.1. Nesse ponto, o servidor de envio reenvia a mensagem. criando um loop que se repetia até que minha caixa de correio ou nosso servidor estivesse cheio e tivesse que ser corrigido manualmente pelo administrador, removendo o correio da fila.
eMBee 27/08
5

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

jishi
fonte
4

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.

user606723
fonte
-2

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ê

Alife Toy
fonte
2
Por mais que eu odeie a terminologia "nuvem", sua descrição é meio verdadeira; mas ainda existem requisitos de transferência (largura de banda), armazenamento, mesmo que seja apenas intermediário, e um atraso significativo pode ser induzido pela falta de presença em um servidor "local". Mesmo que o arquivo nunca seja acessado pelo destinatário, o remetente original ainda precisa transmitir o arquivo inteiro "para a nuvem", a "nuvem" deve conter o arquivo inteiro (talvez indefinidamente), e as estruturas para comunicar tudo isso tem que ser colocado no lugar. Se estamos reinventando a roda, isso poderia ser feito melhor do que isso.
Chris S
11
"um arquivo não precisa mais ser físico" - aguarde enquanto eu me livre dos meus discos, pois eles não são mais necessários para esses arquivos espirituais ;) Você tem um bom argumento de que o armazenamento e a transferência podem ser abstraídos , mas eles estão apenas ocultos em algum lugar pela abstração, não se foram. Você precisaria de um canal realmente grande para aliviar a latência de acesso a arquivos - por exemplo, comece a reproduzir um vídeo em HD, procure no meio, mexa os polegares por minutos enquanto os dados solicitados são transmitidos para você (em vez de meros milissegundos para armazenamento local) . E também há a incômoda velocidade da luz de um pé por nanossegundo.
Piskvor
true - tudo isso pode ficar bem lento se a localidade ou a disponibilidade não forem bem definidas ou implementadas. mas o usuário pode defini-los e assumir alguma responsabilidade por várias compensações de velocidade, largura de banda, disponibilidade, etc., usando políticas pré-empacotadas, regras de filtro, atributos, tags e regras inferenciais. quando envio um email com anexo, não preciso 'enviá-lo', pois os dados são simplesmente disponibilizados ao destinatário e, em seguida, os dados são movidos ou replicados para discos e / ou armazenamento em nuvem com base no comportamento de duas partes regras de inferência configuradas pelo usuário dos 'gerenciadores de armazenamento'.
Alife Toy
"O usuário começa a defini-los e assumir alguma responsabilidade" - Você deve ser um gerente.
Chris S
Não gerente, mas algo muito pior - um futurista quebrado
Alife Toy