De vez en cuando envías un correo electrónico usando tu cliente de correo convencional y, de repente, obtienes como respuesta un rebotado.
Por ejemplo, échale un vistazo a este correo rebotado que recibí hoy mismo en la bandeja de entrada de mi Outlook:
Casi todo el mundo simplemente hace caso omiso y borra este tipo de mensajes, pero no deberías hacerlo. Contienen información muy interesante sobre las causas que llevaron a obtenerlo, así que puedes saber porqué el correo rebotó y si se trata de un problema puntual o permanente, entre otras cosas. Deberías localizar la información en el cuerpo del mensaje (como en la figura anterior) o bien en un archivo adjunto de texto que a veces traen.
El código de estado está formado por tres números. Se trata de códigos SMTP estándar definidos bajo el documento RFC 1893.
Como puedes comprobar por tus medios en ese documento, por ejemplo, mi correo rebotado de antes indica un código de estado 5.1.1, que significa lo siguiente:
· 5: Fallo permanente
· 1: Estátus relacionado con la dirección
· 1: Dirección de destino errónea
Así que, obviamente, es una dirección que no existe, aunque ya lo sabíamos simplemente por haber leído la frase que viene justo a continuación. Sin embargo no todos los servidores de correo de Internet se comportan de esta forma tan correcta y acorde con los estándares.
Algunos servidores SMTP devuelven códigos que no cumplen totalmente la RFC y a veces pueden causar errores extraños que llevan a confusión. Por ejemplo, hace unos días recibí un correo rebotado con un código de estado 4.0.0. Si verificas su significado en la RFC obtienes lo siguiente:
· 4: Fallo transitorio permanente (¿como?)
· 0: Estado indefinido
· 0: Otro estado indefinido
Es decir, que no nos dice absolutamente nada acerca de lo que ha causado el rebote, y en realidad ningún servidor debería devolver un código 4.0.0., pero hay por ahí unos cuantos que lo hacen, incorrectamente. Por ejemplo, verifiqué el mensaje de estado completo para el correo rebotado y obtuve esta respuesta del servidor:
4.0.0: user over quota
¡Eh!, es sólo una bandeja de entrada llena, al menos si nos fiamos del mensaje devuelto. Pero de acuerdo con la RFC una cuenta llena se debe indicar con el código estándar 4.2.2, que significa específicamente eso.
Verifiqué otro servidor que también devolvía otro código "raro", en concreto 4.5.2, y en esta ocasión obtuve este mensaje:
4.5.2: Recipient address rejected: user over quota
Que está rematadamente mal también, pues el significado de este código es algo relacionado con el protocolo, no con problemas en la cuota:
· 4: error transitorio permanente
· 5: Estado relacionado con la entrega del correo
· 2: Error de sintaxis (?¿?)
Que es un comportamiento totalmente loco del servidor.
En general no deberías obtener nunca códigos de estado 4.0.0y similares, pero si te llegan será de servicios de correo poco profesionales, y normalmente significan en realidad que la dirección no existe. Nuestro servicio MAILCast gestiona e interpreta de manera automática los correos rebotados y te muestra una lista clasificada de ellos que incluso puedes exportar a Excel para hacer tratarlos por tu cuenta después (captura de la versión en inglés):
Aparte de la dirección de correo que rebotó y una explicación corta ofrecemos también el código de estado obtenido (cuando es un rebotado duro), para que puedas verificar su significado por tus medios si quieres. Hemos estudiado un montón de casos raros como los descritos antes para tratar de adivinar lo que realmente está pasando en este tipo de servidores "rebeldes", pero es prácticamente imposible intepretarlos todos bien ya que hay servidores que no se comportan de forma estándar. Somos bastante precisos pero, cuando tengas dudas puedes verificar tú los estados para ver el significado "oficial" de los rebotados como he descrito aquí.
Simplemente verifica el código en el enlace a la RFC que puse antes. ¡Es fácil!