De correo y Correo

En breve, linux ajusco se murió, una optiplex que ya tenia rato, se habían cambiado los capacitores de la motherboard y que también requirió cambio de fuente.  No ese fue sagan que se cambio por un HP que sera en 2014, entonces este linux debe se la maquina de nuestro colectivo que mas tiempo tenia en el site sin fallar una optiplex no recuerdo el modelo ahora… pero funcionando con un disco IDE de 200GB porque en su momento se le cambio el de 150 SATA que venia de fabrica y no se podían usar los dos ya que el BIOS no entendía como iniciar del SATA si el IDE estaba presente.

En todo caso esta maquina ha sido nuestro gestor de listas de correo y también del correo mismo de los integrantes del colectivo CL, eventualmente fue fácil implementar en el mismo una especie de relay para el correo que teníamos en Azure, antes de que nos resolvieran lo de como colocar una zona de DNS y una resolución inversa, hoy ya se ofrece como servicio, con costo, pero cuando empezamos con ese proyecto en 2014 esperamos un año la propuesta del asociado de MS y nunca nos dio solución.

En fin que tenemos por ahí un proyecto que tiene como trece mil usuarios, contados al lunes de la semana pasada, que supongo no habían recibido correo en tres semanas, si muy triste, el tiempo más largo que me he tomado en negociar que no hay refacciones, ver que se hace y terminar bajando una maquina que tenia para dar de baja, dicho sea de paso un par de meses antes la maquina donde corría sagan, con una fuente hechiza, que no permitía cerrar bien el gabinete y los capacitores de la motherboard remplazados un par de años antes, se dio de baja puesto que ya tenia muchos remiendos… no se me ocurrió, ni tenia espacio para tenerla como refacción.

Decia que por ahí debía haber muchos usuarios sin recibir correo las tres semanas que linux estuvo fuera, un tanto mis listas académicas que no tienen tanto trafico y que con un BCC largo y feo se solucionan, el lunes de la semana pasada recuperé el disco de la maquina dañada y originalmente mi idea era sólo pasarlo a la nueva i686 a amd64, pero después de ver los errores y la cantidad de memoria 2GB vs 4GB, me decidí a instalar, revisar y pasar las configuraciones, para arreglar varios vicios y un montón de paquetes ya obsoletos y que estoy casi seguro nadie usa, el lunes lo pase instalando y pasando las configuraciones, el martes se bajo a informática y se puso en línea, ese mismo día me enfrente a varias cosas que no había modificado cuando actualice la primera vez y que tenia pendientes, como el idioma de mailman, algunas configuraciones de mariadb y especialmente postgrey, postfix y la autentificación con saslauthd [0].

Pero el gran problema vino con postfix o más bien con las tres semanas que no estuvo funcionando y el arranque de un proyecto grande el 7, bueno el gran problema para mi en realidad porque por como estaba por la configuración por defecto tan sólo habríamos quedado bloqueados de manera temporal de gmail, hotmail y yahoo por el ritmo al que estábamos entregando.

El viernes 7 de septiembre

El viernes 7 después de haber dejado como yo quería la maquina el miércoles, hice la revisión de rutina y me encontré con la imagen que esta arriba, estaba llegando mucho correo, entre el que estaba atrasado y la actividad propia del proyecto, vi que empezaba a rechazar algunos y que en realidad estaba mandando advertencias de la cantidad de correo que estábamos enviando y añadí unas sugerencias que se hacen para limitar el envió o al menos la velocidad con que se hace [1] y por supuesto debí retomar la configuración que nos ha funcionado en nuevos servidores en producción, pero como este tenia configuración nueva y tenia algo de fiaca me encontré que por acá los habían resumido sin la discusión [2] (que no es tan malo, pero no mencionan los valores por defecto de cada configuración) mi gran error fue añadir:

smtp_destination_concurrency_limit = 2
smtp_destination_rate_delay = 1s
smtp_extra_recipient_limit = 10

Sin recordar demasiado que hacían…

Y que sus valores por defecto son, 20, 0 y 20.

11 de septiembreAyer por la tarde se me ocurrió revisar la salud de la maquina, especialmente del correo, en la gráfica imagínense, a las 14 horas la cola estaba muy lenta y grande y tuve que revisar una sección que nunca había requerido de postfix [3] aprender a usar qshape [4] y probar todo lo que si sabia de postfix y por supuesto quitar la pequeña configuración del bloque de arriba que simplemente alentaba la entrega global y la que necesito más lenta, es sólo para quienes tengo mucho correo y lo requieren para no bloquearnos.

Ya hoy con más calma qshape reporta esto (no hice captura de cuando andábamos sobre los 200):

                             T   5  10  20  40  80  160  320   640  1280  1280+
                   TOTAL 156865 123 103 221 480 927 1801 3354 12324 10775 126757
             hotmail.com  93809  97 102  27 239 292 1012 2596  4115  6004  79325
               gmail.com  40951   4   0 174  70 485  614  385  1647  2851  34721
   www.upnvirtual.upn.mx   5888  16   1  17  57  72  131  207  4594   792      1
             outlook.com   3453   1   0   1   4   1    3  131   239   194   2879
            yahoo.com.mx   2826   0   0   0   3   2    1    0   283   106   2431
             live.com.mx   2029   0   0   0 100   1    0    0   232    34   1662
              outlook.es   1206   0   0   0   0   1    0    0    90    37   1078
              iea.edu.mx   1030   0   0   0   0   0    0    0    93    91    846
                  upn.mx    957   4   0   2   5  10   24   26   603   201     82
                edubc.mx    907   0   0   0   0   0    0    0    11    87    809
              hotmail.es    770   0   0   0   0  21   11    0    15    19    704
               yahoo.com    625   1   0   0   0   0    0    1   133    23    467
                 msn.com    428   0   0   0   0   0    0    0     3     6    419
                live.com    300   0   0   0   0  31    0    0     3    71    195
             uabc.edu.mx    238   0   0   0   0   0    0    0   123     4    111
          prodigy.net.mx    190   0   0   0   0   0    0    0     2    71    117
     linux.ajusco.upn.mx    146   0   0   0   1   0    4    5    10    30     96
                 ucol.mx    108   0   0   0   0   0    0    0    86     0     22
           upn211.edu.mx    107   0   0   0   0  10    0    0     5    16     76
           sepbcs.gob.mx    102   0   0   0   0   0    0    0     0     0    102
 colegiomakarenko.edu.mx    102   0   0   0   0   0    0    0     0     0    102
              icloud.com    100   0   0   0   0   0    0    0     0     0    100
               ymail.com     99   0   0   0   0   0    0    0     0    66     33
                itesm.mx     72   0   0   0   0   0    0    0     0     0     72
+ronterizatijuana.edu.mx     71   0   0   0   0   0    0    0     0     0     71
             seph.gob.mx     45   0   0   0   0   0    0    0     0     1     44
              cmn.edu.mx     26   0   0   0   0   0    0    0     0     5     21

[PS. De haber prestado mayor atención habría notado que www.upnvirtual.upn.mx era el culpable de todo este desaguisado… por cierto también he obviado mencionar que para revisar mis configuraciones de correo hace rato que uso swaks, si bien me lo sé de memoria por telnet ahorra bastante tiempo cuando son combinaciones diferentes, gracias a Gunnar que hace mucho tiempo lo menciono.]

Pero tuve que pensar en que cosa estaba mal, por supuesto la configuración global estaba mal, pensé en limitar también lo que llegaba externo y que reenviamos, que es casi todo el correo, pero en realidad la cosa había estado funcionando bien y necesitamos que siga presente.

Por lo tanto basándome en los documentos arriba añadí colas aún mas lentas para los dominios que lo requieren ademas de polite y turtle añadí snail y estoy tentado a añadir una intermedia nada más para gmail, pero esta semana lo dirá, con todo y que sigue sin ser la cola de correo más que haya gestionado, la cosa parece mejorar.

gráfica de uso semanal, generada el 11 de septiembre

Por supuesto han aumentado los deferred pero con la cantidad de coreo que tenemos que gestionar no me parece tan terrible y pasamos de ayer de tener más de 10 mil correos de hotmail usando la mayor parte de la cola a ahora tener una cantidad importante de gmail.

Sep 11 10:00:02 linux postfix/qmgr[7747]: warning: mail for gmail.com is using up 9688 of 20000 active queue entries
Sep 11 10:00:02 linux postfix/qmgr[7747]: warning: this may slow down other mail deliveries
Sep 11 10:00:02 linux postfix/qmgr[7747]: warning: you may need to increase the main.cf polite_destination_concurrency_limit from 1
Sep 11 10:00:02 linux postfix/qmgr[7747]: warning: please avoid flushing the whole queue when you have
Sep 11 10:00:02 linux postfix/qmgr[7747]: warning: lots of deferred mail, that is bad for performance

Una cosa que no había tomado en cuenta es que no había configurado el bind local, lo había instalado, pero en la lectura de como mejorar el desempeño [5] por supuesto viene que si se corre un DNS local se use (dah!, cosa que no estaba haciendo).

Cosa que vale mencionar es que ayer en el peor momento de la congestión un correo para un usuario local, estaba tomando tres horas para entregarse, estoy viendo como limitar las conexiones por saslauthd para evitar eso.

Es pronto para cantar victoria, pero estoy muy confiado que después de todo lo que probe la tarde de ayer, tengo una configuración solida, que no había necesitado en esa maquina, ya que por su propia memoria y CPU al parecer se gestionaba sola muy bien. El viernes pienso actualizar la entrada.

17/9/2018 Y se paso el viernes y el fin de semana y se me paso escribir la actualización, pero si escribí una entrada con otras cosas que que me fui encontrando, que en efecto resolvió la cosa y que al final no necesite herramientas externas, ¿cómo esta hoy la maquina?, bueno todavía con bastante trabajo, pero no como estaba al principio.

Por ahí habían dos pares de decenas de miles que aún no llegaban a su timeout de siete o más dias para ser eliminados, así que hice:

mailq | grep "upnvirtual.upn.mx" -F | cut -d " " -f 1 | cut -c 1-10 | postsuper -d -

Y creo necesita explicación, mailq lista la cola de correo, grep -F hace que busque y encuentre lo que esta separado por puntos, el primer cut de los campos separados por espacios presenta sólo el primero, el segundo cut muestra sólo los caracteres 1 al 10 y el postsuper borra los identificadores de correo con el numero que pasa el cut.

Claro lo tuve que realizar dos veces porque tenia colas de 11 y 12 caracteres y las que están en hold con * me estorbaron,  imagino que awk se puede de un jalón pero me pareció más fácil así.

Por cierto ya el día de hoy qshape reporta:

                     T  5  10  20  40  80  160  320 640 1280 1280+
                         TOTAL 13694  9 101 251 342 849 4820 7322   0    0     0
                   hotmail.com 11325  6  60 157 212 648 3920 6322   0    0     0
                     gmail.com  1739  3  40  81 112 124  592  787   0    0     0
                   live.com.mx   335  0   0   7   7  33  155  133   0    0     0
                   outlook.com   295  0   1   6  11  44  153   80   0    0     0

Que ya se ve mas «normal».

[0] https://wiki.debian.org/PostfixAndSASL
[1] http://steam.io/2013/04/01/postfix-rate-limiting/
[2] https://wiki.deimos.fr/Postfix:_limit_outgoing_mail_throttling
[3] http://www.postfix.org/QSHAPE_README.html
[4] http://www.postfix.org/QSHAPE_README.html#trouble_shooting
[5] http://www.postfix.org/TUNING_README.html