Hoy nos hemos encontrado con una sorpresa que nos ha parecido relevante documentar. Uno de nuestros proveedores de tráfico saliente de correo nos ha bloqueado una cuenta al parecer por contar con un número elevado de hard bounces. Los hard bounces son errores permanentes, tipo “buzón ya no existe” o “dominio no responde a DNS”, etc.

Es vital mantener las listas de correo al día a este respecto y para eso se usa la cabecera Bounce-to en los emails que se envíen (de otro modo irán al remitente (from)).  El objetivo es centralizar en una cuenta todos los rebotes y procesarlos con frecuencia para desactivar los emails que en teoría no deben volver a estar activos para evitar tráfico basura a la hora de enviar emails. Esto también tiene su efecto en la entrega y en los servidores de destino, pues un número elevado de intentos a buzones de un dominio que no funcionen, probablemente harán que el resto de buzones válidos de ese mismo dominio, se entreguen directamente como spam.

Con este fin hemos mantenido algunas cuentas de Google Apps (gmail) como destino de esos bounces que después procesamos con phplist. El problema ha surgido porque phplist no era capaz de acceder a la cuenta y no estaba alertando por ello. Google está endureciendo sus criterios de seguridad de acceso a buzones y eso afecta a scripts que acceden de forma automática a buzones que en algunos caso exigen un “acceso via web” para acceder, como era este caso.

La solución ha venido modificando el parametro de acceso de phplist al buzón pop a:

$bounce_mailbox_port = "110/pop3/SSL

Pero sobretodo, activando la opción de “permitir aplicaciones menos seguras” en la configuración de la cuenta de Google asociada al buzón en cuestión.