{"id":39575,"date":"2018-12-17T07:59:34","date_gmt":"2018-12-17T07:59:34","guid":{"rendered":"https:\/\/wp.lvh.me\/blog\/2018\/12\/17\/cuentas-fallidas-en-la-base-de-datos-de-emails-la-importancia-de-eliminarlas\/"},"modified":"2024-05-22T07:41:35","modified_gmt":"2024-05-22T07:41:35","slug":"cuentas-fallidas-en-la-base-de-datos-de-emails-la-importancia-de-eliminarlas","status":"publish","type":"post","link":"https:\/\/mailrelay.com\/es\/blog\/2018\/12\/17\/cuentas-fallidas-en-la-base-de-datos-de-emails-la-importancia-de-eliminarlas\/","title":{"rendered":"Cuentas fallidas en la base de datos de emails, la importancia de eliminarlas"},"content":{"rendered":"

Muchos clientes se sorprenden cuando tienen problemas de entregabilidad en B2C y han sido muy cuidadosos en cumplir con la normativa legal de protecci\u00f3n de datos, han recabado sus suscriptores de forma inequ\u00edvoca, ellos quieren recibir los boletines y cursan las bajas con celeridad.<\/p>\n

Por desgracia, a veces, se han olvidado de un detalle muy importante, eliminar de su BBDD las cuentas de los ISP que han dado un rebote indicativo de que la cuenta ya no existe o no est\u00e1 operativa<\/strong> (normalmente por enviar con sistemas internos artesanales que no gestionan los bounces\/rebotes).<\/em><\/p>\n

Por ejemplo cuando un env\u00edo devuelve cualquiera de estos c\u00f3digos de respuesta SMTP:<\/strong><\/p>\n

    \n
  1. 5.0.0 Address does not exist – La direcci\u00f3n no existe.<\/li>\n
  2. 5.1.1 Bad destination mailbox address – Direcci\u00f3n de buz\u00f3n de destino incorrecta.<\/li>\n
  3. 5.1.2 Bad destination system address – Direcci\u00f3n del sistema de destino incorrecta.<\/li>\n
  4. 5.1.3 Bad destination mailbox address syntax – Sintaxis de direcci\u00f3n de buz\u00f3n de destino incorrecta.<\/li>\n
  5. 5.1.4 Destination mailbox address ambiguous – Direcci\u00f3n del buz\u00f3n de destino ambigua.<\/li>\n
  6. 5.1.6 Mailbox has moved – El buz\u00f3n se ha movido.<\/li>\n
  7. 5.1.7 Bad sender\u2019s mailbox address syntax – Sintaxis de la direcci\u00f3n del buz\u00f3n del remitente incorrecto.<\/li>\n
  8. 5.1.8 Bad sender\u2019s system address – Direcci\u00f3n del sistema del remitente err\u00f3neo.<\/li>\n
  9. 5.2.0 Other or undefined mailbox status – Otro estado de buz\u00f3n o indefinido.<\/li>\n
  10. 5.2.1 Mailbox disabled, not accepting messages – Buz\u00f3n deshabilitado, no acepta mensajes.<\/li>\n<\/ol>\n

    Aunque en general hay que descartar y no volver a enviar cualquier rebote\/bounce hard con un c\u00f3digo 5.x.x.<\/p>\n

    Cuando esto no se hace el problema es el siguiente:<\/p>\n

    \u25ba Si superamos el n\u00famero m\u00e1ximo por hora a env\u00edos que ya se han indicado como rebotados con anterioridad el ISP de destino puede bloquear o encolar los siguientes mensajes.<\/p>\n

    \n
    Veamos este log de ejemplo en el que hotmail lo indica de forma inequ\u00edvoca:<\/div>\n
    queue #rcpt kbytes conn st retry last error———————————————- —— ———- —- — ——– ———-<\/p>\n

    hotmail.queue\/cliente_ip-zone_com-6 500997 15929377.0 9 Maximum of 20 recipient errors detected; disconnecting while connected from smtp.consultorpc.com (93.159.xxx.xx) to hotmail-com.olc.protection.outlook.com (104.47.5.33)<\/p>\n<\/div>\n<\/div>\n

    \u00b7 Soluciones a este problema<\/h2>\n

    Lo primero si se utilizan sistemas locales de env\u00edo hay que atender los rebotes e irlos limpiando de la BBDD.<\/p>\n

    A veces es complejo ya que requiere cierta programaci\u00f3n o dedicar recursos humanos pero nos podemos ayudar con alg\u00fan software que existe en el mercado que puede gestionarlos por pop3.<\/p>\n

    No obstante lo mejor es hacer los env\u00edos con una plataforma de email masivo como Mailrelay<\/a> que nos de esta prestaci\u00f3n incluida.<\/p>\n

    Para las BBDD que ya tenemos \u201csucias<\/em>\u201d sin haber mantenido podr\u00eda parece ser f\u00e1cil de solucionar<\/strong> ya que se tratar\u00eda de atender a partir de ahora la indicaci\u00f3n de las cuentas fallidas, pero no<\/strong>.<\/p>\n

    Es cierto que cuando se detecten nuevas cuantas err\u00f3neas o que ya no est\u00e1n operativas Mailrelay ya las marcar\u00e1 como rebotados, pero las antiguas algunas seguir\u00e1n dando rebote pero otras no.<\/p>\n

    La raz\u00f3n es que los ISP convierten algunas en spamtraps<\/strong><\/a> o podr\u00edamos denominar mejor bouncetraps<\/strong> que vuelven a dejar operativas sin dar rebote varios meses despu\u00e9s precisamente para detectar que remitentes cumplen con su exigencia de limpiar los rebotados y fallidos y cuales no.<\/p>\n