Por mi voluntad, hay un servidor de correo a mi cuidado. Pequeño, ~ 20 usuarios. Funciona de manera estable, no es deseable cambiar el software. Y no sería necesario, pero una vez que los registros de respaldo insinuaran inequívocamente, si continúas con el mismo espíritu, toda la noche irá a un respaldo completo. Y la cosa está en el volumen de los buzones de los usuarios.
El problema está indicado, es necesario resolverlo. El camino a seguir - para comprar hierro aún más poderoso - no es mi tipo, y el presupuesto no es de goma. La opción obvia: cuotas. Pero en la práctica, esto no ayuda mucho. Los juramentos de "Limpié todo" en un examen más detallado se convierten en sellos, fotos divertidas y archivos de fotos familiares (en el correo corporativo, sí). Y el número de gritos "Tengo una luz urgente no funciona, hazlo de inmediato" aumenta en un orden de magnitud. Así que no por mucho tiempo y perder la fe en las personas.
Afortunadamente, no soy psicólogo, ni entrenador ni mentor. Mi negocio es la tecnología. Entonces vendremos desde el lado técnico.
Lo primero que pensé fueron los mensajes autodestructivos. En términos generales, todo sin la marca "importante" se elimina después de N días. Para mi gusto, debe ser "cosido" en los estándares de almacenamiento de correo eléctrico. Pero hasta ahora esto no es así, y la implementación me pareció demasiado ambiciosa.
El segundo pensamiento fueron las copias. Conozca estos mensajes donde no es el destinatario principal. Acude a usted solo para información. Algunos de estos mensajes podrían eliminarse automáticamente. Pero, de repente, aquí los usuarios se dividieron en dos campos: "todos te necesitan qué" y "qué es". No dominaba el algoritmo de clasificación automática con tales condiciones.
Bueno, no lo borres, ¡así que copia! Tome todas las copias y haga enlaces simbólicos. Un análisis rápido mostró que incluso procesar solo duplicados COMPLETOS de esta manera ahorra TRES repositorios. Pero, pero, pero. Desafortunadamente, este es un camino sin salida debido a muchas limitaciones técnicas.
Detalles para aquellos interesados bajo el spoiler- no todos los archivadores entienden los enlaces simbólicos;
- El software del servidor se está volviendo loco en algunos lugares;
- complejidad org. Carácter y derechos de acceso.
Por cierto, en la configuración de mi servidor de correo y en las copias de seguridad generales, el almacenamiento de archivos para los usuarios es muy escaso. Por lo tanto, el espacio de maniobra era pequeño.
Lo que queda Con tristeza miré las focas
y se preguntó ya una red neuronal simple que limpiaría el correo para el usuario. Y luego ... Disculpe, disculpe, pero ¿qué hacen los gatos en la carta? ¡Recuerdo que una carta con un archivo adjunto pesa casi un tercio más que un archivo adjunto! ¿Pero puedo mover el archivo adjunto? ..
Así comenzó el camino donde había "muchos descubrimientos maravillosos". Si supiera ... Bueno, entiendes. ¡Una gota de ignorancia y coraje nos llevan a la victoria!
Entonces:
almacenamos los archivos adjuntos por separado de las letras .
El principal error que puede cometer aquí es abrir el archivo eml en un editor de texto y decidir que hay texto sin formato. Entonces lo hice. Y estaba encantado. En este momento escribiré un archivo por lotes. Las utilidades de línea de comandos para extraer archivos adjuntos están llenas:
github.com/erikvdv1/eml-attachments o
github.com/maiken2051/uudeview , de forma
manual . Hay problemas con las codificaciones, pero esto no es lo más importante.
Lo más importante: sacar el archivo y crear un enlace a él es una cuestión trivial. Pero para empujar este enlace a la letra original ... Porque no hay texto. Hay
MIMEUn lector experimentado, por supuesto, ahora se ríe del desafortunado autor. El autor, sin embargo, descubrió las delicias del "estándar". Lo más importante que entendí: los hongos agáricos de mosca no son necesarios para caer en una locura.
Ejemplos y abuso - bajo el spoiler:
charset = utf-8
charset = "UTF-8"
charset = "UTF-8"
juego de caracteres = UTF-8;
charset = "UTF-8";
charset = "UTF-8";
Esta es una y la misma cosa.
Saltos de línea en el medio de una secuencia Base64. De dónde vienen sigue siendo un misterio para mí.
Y viceversa: la ausencia de \ r \ n \ r \ n después de la parte del encabezado.
En el encabezado en sí, el orden de los campos es a pedido del talón izquierdo.
Las letras más antiguas permiten una longitud de línea de no más de 80 caracteres, incluidos los de servicio.
Puede haber saltos de línea en los nombres de archivo (en el cuerpo del mensaje y no en el nombre en sí).
En general, los saltos de línea pueden estar en cualquier lugar, a pesar de que en el salto de línea estándar se declara como el final del parámetro actual.
El texto de la carta en sí está codificado. Cómo exactamente está codificado, permanece en la conciencia de un servidor en particular, hay un montón de opciones (mal olor).
Y, en la carta casi siempre hay una parte html. Es decir, si envía "Hola" y hay una etiqueta br o p, entonces en la carta siempre habrá DOS secciones: con texto simple y con etiquetas. Y el texto está duplicado. Y aquí "salvaron" la potencia informática ... Sólo una colección de animales con Frankenstein.
El nombre de los archivos que tienen es el siguiente: filename = "=? Encoding? Type?; Y sucede así: filename * 0 * = encoding '' (STA ?? !!). El segundo es un estándar más nuevo, RFC5987. El estándar establece explícitamente ese nombre de archivo * 0 * = ENC y nombre de archivo = "=? Lo mismo. En este lugar, finalmente me convencí de que se estaban burlando de mí. Cómo se puede manejar normalmente, no lo sé.
Por separado, como siempre, Apple anotó. Generalmente tienen algún tipo de estándar propio. Mirando hacia el futuro, los largos intentos de procesar su código condujeron a la única solución correcta: "Error: el correo de Apple no es compatible".
Thunderbird lo hace sin embargo. Con pena, subí a sus fuentes, pero no pude encontrar la sección necesaria en un gigabyte de código y medio para una mezcla de pitón y dialectos de Java. Ayudé en su IRC, donde amablemente me dijeron dónde buscar, pero todavía no pudieron encontrarlo.
Pero no se desanimó. No lea la documentación @ escriba el código, y ya está. No, en serio, tuve que hacer algo para acercar el final de MIME.
El script por lotes no fue suficiente. El resultado fue
una utilidad de línea de comandos en C # y dotNet .
La utilidad tiene dos modos de operación:
Primero: solo extrae los archivos adjuntos. Al mismo tiempo, funciona correctamente con codificaciones para Windows.
Segundo: y aquí la diversión principal. ¡Ahora aún podemos almacenar archivos adjuntos de correo por separado del correo! La utilidad
crea una nueva letra en lugar de la anterior : el
archivo adjunto se corta, la letra se formatea en HTML sin formato con codificación UTF sin limitar la longitud de la línea. La sección de texto / sin formato se toma como base. Si hay tablas en la sección html, las transfiere mientras mantiene el formato dentro de la tabla, pero esta funcionalidad funciona de manera regular. Al final del texto de la carta actual (si es una respuesta o un reenvío), los enlaces a los recursos de red se insertan con la ruta a los archivos extraídos, en los formatos de archivo: /// y ftp: //.
El sistema se prueba en más de 10000 letras y se implementa en la infraestructura existente.
Ventajas identificadas:+ fue:
Copia de seguridad
Se inició a las 01:00:08
y completado con éxito 03:26:32
se convirtió en:
Copia de seguridad
Comenzó a las 01:00:09
y completado con éxito 01:40:36
+ Se guardó más del 30% del almacenamiento: los archivos pasan de Base64 pesado y otros similares al formato normal del sistema de archivos, además se encontraron muchos duplicados incluso dentro de los buzones individuales.
+ Se aumenta la velocidad de procesamiento de los buzones por el servidor y los programas de correo.
+ Desaparece "Abrí una carta de la oficina de correos, la edité durante 10 horas y no sobrevivió"
+ Puede rechazar cuotas.
+ Sigue siendo posible encontrar un archivo adjunto en el correo, en lugar de simplemente transferirlo al almacenamiento de archivos.
+ Cerca del final de MIME. ¡Arrepiéntanse, autores!
Contras de la decisión:- algunas letras (pero no los archivos adjuntos) aún superan. Básicamente no internamente, pero cuando se ve en algunos clientes;
- en ftp algunos demonios se rompen constantemente;
- no todos los clientes de correo electrónico admiten la apertura a través del archivo: ///
Cuestiones controvertidas:? El correo de Apple no es compatible. Para mí, y el Buda está con él;
? Batir letras con formato complejo. Por lo general, estos son volantes de Reservas o publicidad;
? Si el servidor ftp está en un puerto no estándar, puede haber problemas de acceso. Decidido por un bot de correo.
De una manera tan espinosa se resolvió el problema.
Gracias por su atencion!