Parece que hay muchos casos extraños en los que un correo electrónico no debería ser rechazado, pero lo es de todos modos. Esto significa que, a veces, los usuarios envían correos de soporte que nunca recibimos.
Por ejemplo, los correos enviados a nuestra dirección de soporte desde direcciones de mac.com a menudo son rechazados por carecer de cuerpo (Error::Receiver::NoBodyDetectedError). Sin embargo, esos correos suelen tener texto en el cuerpo, por lo que podría tratarse de un problema de análisis.
Pero aparte de solucionar lo que cause estos rechazos erróneos, me gustaría que pudiéramos recibir una alerta cada vez que haya nuevos rechazos, para poder revisarlos y determinar si el rechazo fue apropiado.
Esto podría implementarse como una opción para enviar alertas al personal sobre todos los rechazos, o como una opción para simplemente poner en copia (CC) todos los correos de rechazo al personal.
De lo contrario, si no queremos perder ningún correo de soporte entrante, tendremos que consultar continuamente la lista de correos rechazados en el backend de Discourse. Esto es tedioso e innecesario.
Creo que es mejor centrarse en el ejemplo concreto. Dijiste que “suele” ser rechazado; ¿notas algún patrón en el contenido del correo? Si fuera un problema constante, esperaría que todos los correos de mac.com fallaran.
Bueno… ‘a menudo’ en el sentido de ‘con la frecuencia suficiente para resultar algo molesto’. Nuestra principal preocupación es que no queremos que la gente se enoje por lo que percibe como una falta de respuesta por parte de nuestro equipo de soporte.
He buscado patrones en los casos que he notado. Al principio pensé que podría haber un problema con la forma en que mac.com maneja los correos electrónicos, pero desde entonces he determinado que tenemos alrededor de 30 usuarios con direcciones de mac.com que no muestran ningún problema.
También pensé que si mac.com tuviera un cliente de correo web, podría estar manejando los correos HTML de una manera no estándar. Pero ni siquiera estoy seguro de que exista un cliente de correo web para mac.com.
Pensé que lo había resuelto cuando me di cuenta de que el incidente más reciente involucraba correos que solo contenían líneas citadas en su cuerpo, pero pruebas posteriores mostraron que Discourse procesa ese tipo de correos sin problemas.
Revisaré los registros para ver con qué frecuencia ha ocurrido este tipo de cosas y, por supuesto, buscaré patrones. Solo pensaba que, mientras exista la posibilidad de que Discourse ocasionalmente cometa errores como este, un correo de alerta parece una medida de seguridad bastante sencilla.
Publicaré aquí los resultados de mi investigación.
Las direcciones de correo de Mac.com son en realidad cuentas de iCloud.com. Apple migró las cuentas de Mac.com y me.com a iCloud hace cinco o seis años.
Gracias por la aclaración. Básicamente, cualquier problema con los correos electrónicos desde direcciones de mac.com también debería afectar a las direcciones de me.com y otras de iCloud.
No hay un patrón real. Hay 21 casos en los que el motivo del rechazo no está del todo claro o parece incorrecto.
1 x “No se pudo procesar el correo electrónico: El cuerpo es demasiado similar a lo que publicaste recientemente”
8 x “No se pudo procesar el correo electrónico: Email::Receiver::BadDestinationAddress” - estos son algo misteriosos; ¿por qué son incorrectas las direcciones?
3 x “No se pudo procesar el correo electrónico: Email::Receiver::NoBodyDetectedError” - dos parecen tener un texto de cuerpo que parece normal; uno solo dice ‘sin cuerpo’
1 x “No se pudo procesar el correo electrónico: Email::Receiver::TooShortPost”
6 x “No se pudo procesar el correo electrónico”
1 x “No se pudo procesar el correo electrónico: Lo sentimos, los nuevos usuarios solo pueden incluir una imagen en una publicación.”
1 x “Error no capturado: Error de sintaxis, expresión no reconocida: #xxxxxx-email:product at company dot com”
Varios de esos casos involucraron intentos legítimos de comunicación por parte de clientes. Si el correo de rechazo enviado por Discourse fue a la carpeta de spam del remitente o simplemente fue ignorado, sigue sin estar claro.
Se enviaron a una dirección que no estás gestionando, como la de soporte.
Para mí, solo lo de «nadie», donde dices que hay alguien, parece algo que podría ser un error. Una posibilidad es que tenga que ver con que estén utilizando algún cliente de correo antiguo y defectuoso.
Revisé algunos de estos (Email::Receiver::BadDestinationAddress) y muchos parecen ser respuestas legítimas de clientes, con el destinatario en este formato: replies+largoIdentificador@discourse.site.com. El correo de alerta que Discourse envía al remitente sugiere que su correo fue enviado desde una dirección diferente a la asociada con el tema mencionado, lo cual probablemente sea la explicación, pero en un caso como este, aún me gustaría que el personal recibiera una notificación.
Sí parece un error, pero aunque me gustaría que se solucionara, creo que siempre habrá casos como este, por lo que, además de investigar posibles errores en el análisis de correos, un correo de alerta al personal nos permitiría brindar soporte oportuno mientras tanto.
Eso es lo que estaba pensando. La próxima vez que vea esto, le preguntaré al cliente qué cliente de correo está utilizando.
El punto que quiero hacer es que cuando los correos electrónicos son rechazados, a veces se trata simplemente de personas que buscan soporte, no de nada malicioso.
Por supuesto, algunas veces los correos que Discourse rechaza realmente necesitan ser rechazados, pero no queremos arriesgarnos a perder ningún correo de soporte, así que nos vemos obligados a consultar la lista de rechazados.
Mientras tanto, los remitentes confundidos se ven forzados a buscar otros medios para contactarnos, como el formulario de contacto en nuestro sitio web.
Para sitios más grandes, las alertas de rechazo de correo electrónico podrían ser demasiado numerosas para manejar, pero para nosotros, sería mucho más fácil lidiar con ellas que con clientes enfadados.
Además, aunque Discourse envía correos de rechazo al remitente con información potencialmente útil, creo que esos correos a veces terminan en carpetas de spam, lo que confunde aún más a los clientes afectados.
Sin embargo, no estoy seguro de cómo solucionar el problema de responder desde el buzón incorrecto. (¡Y vaya, qué odio los formularios de contacto, independientemente de qué lado del formulario esté!)
Si un usuario responde desde una dirección diferente a la que recibió el correo, esto es esperado.
Si permitiéramos respuestas a estos correos desde otra dirección de correo, estaríamos exponiendo las cuentas a abusos por correo electrónico, con otras personas haciéndose pasar por un usuario. Nos encontramos con este problema a veces en nuestros propios mensajes de soporte aquí en meta.
Si se utilizan formularios de contacto por correo, generalmente envían desde una dirección de correo y establecen la cabecera Reply-To, lo que significa que nos enfrentamos al mismo problema mencionado anteriormente.
Personalmente no tengo una solución ideal en mente; quizás alguien más del equipo tenga alguna idea.
Sí, como ya dije, tiene sentido rechazar estos casos. Pero me gustaría recibir una alerta cuando esto ocurra.
Solo mencioné los formularios de contacto porque, cuando los clientes no pueden contactarnos a través de la dirección de correo de soporte (que Discourse procesa), se ven obligados a buscar alternativas, lo cual no es ideal.
No estoy seguro de cómo lograrlo exactamente. Puedes observar /admin/email/rejected, pero para recibir una alerta real actualmente necesitarías un plugin.
Yo tampoco, por eso publiqué esto como una solicitud de nueva funcionalidad.
Sí, lo entiendo. Pero ir a esa página y presionar actualizar cada pocos minutos parece bastante ineficiente.
Un plugin estaría bien, pero no entiendo por qué esta funcionalidad no podría simplemente agregarse a Discourse. Para mí, parece algo obvio. Discourse ya envía varias alertas a los administradores y al personal del sitio. Haz que la configuración (alerta al rechazar correos electrónicos) esté desactivada de forma predeterminada; creo que eso funcionaría para muchos sitios.
Otro ejemplo: un cliente envió un correo electrónico a la dirección de soporte para reportar un problema que está experimentando con su compra. Discourse rechazó su correo: [Email::Receiver::InactiveUserError].
Entiendo que tiene todo el sentido que Discourse rechace correos de usuarios inactivos, pero si nuestro personal de soporte fuera notificado al mismo tiempo, podrían contactar de inmediato al cliente, explicándole qué sucedió y qué se puede hacer al respecto.
En cambio, a menos que consultemos frecuentemente la lista de Rechazados, el cliente ahora se enfrenta a dos problemas, ambos resultado de sistemas automatizados, de los cuales nuestro personal de soporte permanecería al margen. La intervención humana en esta etapa es importante, pero puede haber retrasos en el tiempo de respuesta, porque, de nuevo, dependemos de revisar manualmente la lista de Rechazados.
¿Existe alguna razón técnica por la que los administradores no puedan ser notificados sobre los rechazos de correos?
