Sobre a questão da construção de bicicletas no campo do armazenamento de correio elétrico

Por minha vontade, há um servidor de correio sob meus cuidados. Pequenos, ~ 20 usuários. Funciona de forma estável, é indesejável alterar o software. E isso não seria necessário, mas depois que os logs de backup sugerirem inequivocamente - se você continuar com o mesmo espírito, a noite inteira passará para um backup completo. E o problema está no volume de caixas de correio dos usuários.


O problema é indicado, é necessário resolver. O caminho a seguir - comprar ferro ainda mais poderoso - não é do meu tipo, e o orçamento não é de borracha. A opção óbvia: cotas. Mas, na prática, isso não ajuda muito. Os juramentos de “eu limpei tudo”, após um exame mais detalhado, se transformam em selos, fotos engraçadas e arquivos de fotos de família (no correio corporativo, sim). E o número de gritos "Eu tenho uma luz urgente não funciona, faça imediatamente" aumenta em uma ordem de magnitude. Portanto, não por muito tempo e perca a fé nas pessoas.

Felizmente, não sou psicóloga, não sou coach ou mentora. Meu negócio é tecnologia. Então, nós vamos do lado técnico.

A primeira coisa que pensei foi em mensagens autodestrutivas. Grosso modo, tudo sem a marca "importante" é excluído após N dias. Para o meu gosto, deve ser "costurado" nos padrões de armazenamento de correio elétrico. Mas até agora isso não é, e a implementação me pareceu ambiciosa demais.

O segundo pensamento foram cópias. Conheça estas mensagens em que você não é o destinatário principal. Vem com você apenas para obter informações. Algumas dessas mensagens podem ser excluídas automaticamente. Mas, de repente, aqui os usuários foram divididos em dois campos: "todos precisam de você o que" e "o que é isso". Não dominei o algoritmo de classificação automática com tais condições.

Bem, não exclua, então copie! Pegue todas as cópias e faça links simbólicos. Uma análise rápida mostrou que mesmo o processamento de duplicatas COMPLETAS dessa maneira salva TRÊS repositórios. Mas, mas, mas. Infelizmente, este é um caminho sem saída devido a muitas limitações técnicas.

Detalhes para os interessados ​​no spoiler
- nem todos os arquivadores entendem links simbólicos;
- O software do servidor está ficando louco em alguns lugares;
- complexidade org. caráter e direitos de acesso.

A propósito, nas configurações do meu servidor de email, backups gerais e armazenamento de arquivos para os usuários são muito escassos. Portanto, o espaço para manobra era pequeno.

O que resta? Com tristeza, olhei para as focas


e já se perguntava uma rede neural simples que limparia o correio para o usuário. E então ... Com licença, com licença, mas o que os gatos fazem na carta? Lembro que uma carta com um anexo pesa quase um terço a mais do que um anexo! Mas posso mover o anexo?

Assim começou o caminho onde havia "muitas descobertas maravilhosas". Se eu soubesse ... Bem, você entende. Uma gota de ignorância e coragem nos leva à vitória!

Portanto: fazemos o armazenamento de anexos separadamente das cartas .

O principal erro que você pode cometer aqui é abrir o arquivo eml em um editor de texto e decidir se há texto sem formatação. Então eu fiz. E ficou encantado. No momento, escreverei um arquivo em lotes. Os utilitários de linha de comando para extrair anexos estão cheios: github.com/erikvdv1/eml-attachments ou github.com/maiken2051/uudeview , de imediato . Há problemas com codificações, mas isso não é a coisa mais importante.

O mais importante: retirar o arquivo e criar um link para ele é uma questão insignificante. Mas, para inserir este link na carta original ... Porque não há texto. Existe MIME .

Um leitor experiente, é claro, ri agora do infeliz autor. O autor, no entanto, descobriu as delícias do "padrão". A coisa mais importante que eu entendi: os cogumelos agáricos não são necessários para cair em um furioso.

Exemplos e abuso - sob o spoiler:

charset = utf-8
charset = "UTF-8"
charset = "UTF-8"
conjunto de caracteres = UTF-8;
conjunto de caracteres = "UTF-8";
conjunto de caracteres = "UTF-8";
Esta é a mesma coisa.

Quebras de linha no meio de um fluxo Base64. De onde eles vêm ainda é um mistério para mim.

E vice-versa: a ausência de \ r \ n \ r \ n após a parte do cabeçalho.

No próprio cabeçalho, a ordem dos campos é a pedido do calcanhar esquerdo.

As letras mais antigas permitem um comprimento de linha não superior a 80 caracteres, incluindo os de serviço.

Pode haver quebras de linha nos nomes dos arquivos (no corpo da mensagem e não no próprio nome).

Em geral, as quebras de linha podem estar em qualquer lugar, apesar do fato de que na quebra de linha padrão é declarada como o final do parâmetro atual.

O texto da carta em si é codificado. Como exatamente ele é codificado, permanece na consciência de um servidor específico, há várias opções (fedor).

E, na carta, quase sempre há uma parte em html. Ou seja, se você enviar "Hello" e houver uma tag br ou p, na carta sempre haverá DUAS seções: com texto simples e com tags. E o texto é duplicado. E aqui eles "economizaram" o poder da computação ... Apenas uma mistura variada de Frankenstein.

O nome dos arquivos que eles têm é assim: filename = "=? Encoding? Type?; E acontece assim: filename * 0 * = encoding '' (STA ?? !!). O segundo é um padrão mais recente, RFC5987. O padrão declara explicitamente esse nome de arquivo * 0 * = ENC e nome de arquivo = "=? mesma coisa Nesse lugar, finalmente me convenci de que eles estavam zombando de mim. Como ele pode ser tratado normalmente, eu não sei.

Separadamente, como sempre, a Apple marcou. Eles geralmente têm algum tipo de padrão próprio. No futuro, longas tentativas de processar seu código levaram à única solução correta: "Erro: o correio da Apple não é suportado".

O Thunderbird faz isso. Com pesar, entrei em suas fontes, mas não consegui encontrar a seção necessária em um gigabyte e meio de código para uma mistura de python e dialetos de Java. Ajudaram no IRC, onde eles gentilmente me disseram onde procurar, mas ainda não conseguiram encontrá-lo.

Mas ele não desanimou. Não leia a documentação @, escreva o código e pronto. Não, sério, eu tive que fazer algo para aproximar o fim do MIME.

Script em lote não foi suficiente. O resultado foi um utilitário de linha de comando em C # e dotNet .

O utilitário possui dois modos de operação:
Primeiro: apenas extrai os anexos. Ao mesmo tempo, funciona corretamente com codificações para Windows.

Segundo: e aqui a diversão principal. Agora ainda podemos armazenar anexos de correio separadamente do correio! O utilitário cria uma nova letra em vez da antiga : o anexo é cortado, a letra é reformatada em HTML simples com codificação UTF sem limitar o comprimento da linha. A seção de texto / planície é tomada como base. Se houver tabelas na seção html, elas serão transferidas, mantendo a formatação dentro da tabela, mas essa funcionalidade funciona mais ou menos. No final do texto da carta atual (se for uma resposta ou um encaminhamento), os links para os recursos de rede são inseridos com o caminho para os arquivos extraídos, nos formatos arquivo /// e ftp: //.

imagem

O sistema é testado em mais de 10000 letras e é implantado na infraestrutura existente.

Vantagens identificadas:
+ foi:
Backup
Foi iniciado às 01:00:08
e concluída com êxito 03:26:32

tornou-se:
Backup
Foi iniciado às 01:00:09
e concluído com êxito 01:40:36

+ Economizou 30 +% de armazenamento: os arquivos vão do pesado Base64 e outros para o formato normal do sistema de arquivos, além de muitas duplicatas, mesmo dentro de caixas de correio individuais.

+ A velocidade de processamento de caixas de correio pelos programas de servidor e correio é aumentada.

+ Desaparece "Abri uma carta dos correios, editei-a por 10 horas e ela não sobreviveu"

+ Você pode recusar cotas.

+ Ainda é possível encontrar um anexo no correio, em vez de simplesmente transferi-lo para o armazenamento de arquivos.

+ Próximo ao final do MIME. Arrependam-se, autores!

Contras da decisão:

- algumas letras (mas não anexos) ainda batem. Basicamente, não internamente, mas quando visto em alguns clientes;
- em ftp alguns demônios estão constantemente quebrando;
- nem todos os clientes de email suportam a abertura por meio do arquivo: ///

Questões controversas:

? Correio da Apple não suportado. Para mim - e o Buda está com ele;
? Bata letras com formatação complexa. Geralmente, esses são folhetos de reservas ou publicidade;
? Se o servidor ftp estiver em uma porta não padrão, pode haver problemas de acesso. Decidido por um bot de correio.

De uma maneira tão espinhosa, o problema foi resolvido.

Obrigado pela atenção!

Source: https://habr.com/ru/post/pt420371/


All Articles