stringtranslate.com

Denuncia de spam

El reporte de spam , más propiamente llamado reporte de abuso , es la acción de designar mensajes electrónicos como abusivos para reportarlos a una autoridad (por ejemplo, un administrador de correo electrónico) para que puedan ser tratados. Los mensajes reportados pueden ser mensajes de correo electrónico, comentarios de blogs o cualquier tipo de spam .

Marcar contenido generado por el usuario en sitios web

Los informes de abuso son un tipo particular de respuesta mediante la cual los usuarios pueden marcar las publicaciones de otros usuarios como contenido abusivo. La mayoría de los sitios web que permiten contenido generado por el usuario aplican algún tipo de moderación basada en los informes de abuso, como ocultar o eliminar el contenido ofensivo en un umbral definido, o implementan una variedad de roles de usuario que permiten a los usuarios administrar los contenidos del sitio de manera cooperativa. [1]

Denuncia de correo no deseado

El comportamiento de los spammers varía desde obligar de algún modo a los usuarios a optar por participar , hasta ofrecer cooperativamente la posibilidad de optar por no participar, hasta ocultar de forma descontrolada la identidad del remitente (incluido el phishing ). Los casos más intratables se pueden resolver informando del mensaje abusivo a sistemas de intercambio de hash [2] como, por ejemplo, Razor de Vipul para el beneficio de otras víctimas. En algunos casos, puede haber un componente cooperativo del lado del remitente que utilizará los informes de spam para solucionar o mitigar el problema en su origen; por ejemplo, puede usarlos para detectar botnets , [3] educar al remitente o simplemente cancelar la suscripción del originador del informe. La legislación sobre spam de correo electrónico varía según el país, prohibiendo el comportamiento abusivo hasta cierto punto, y en algunos otros casos puede valer la pena procesar a los spammers y reclamar daños y perjuicios.

RFC 6650 recomienda que los destinatarios de mensajes abusivos lo comuniquen a sus proveedores de correo electrónico . El equipo de abuso del proveedor debe determinar la mejor manera de proceder, posiblemente considerando compartir hash y tomar medidas legales. Si el remitente se ha suscrito a un bucle de retroalimentación (FBL) , el proveedor de correo electrónico reenviará la queja como un informe de retroalimentación de acuerdo con el acuerdo FBL existente. [4] De lo contrario, los proveedores de correo electrónico deben determinar quién es responsable del abuso y reenviarle la queja. Aquellos destinatarios de informes de abuso no solicitados son en realidad posibles suscriptores de FBL, ya que el proveedor de correo electrónico debe ofrecerles algún medio para gestionar el flujo de informes. Por otro lado, los proveedores de correo electrónico pueden evitar futuros mensajes de remitentes no cooperativos de contenido abusivo. [5]

Los informes de abuso se envían por correo electrónico utilizando el formato de informe de abuso (ARF), excepto la notificación inicial por parte del destinatario en los casos en que la implementación de un buzón de correo proporciona medios más directos. La dirección de destino de un informe de abuso depende de la autoridad a la que se va a informar del mensaje abusivo. Las opciones incluyen las siguientes: [6]

  1. Un centro de informes públicos o un rastreador de reputación global, como SpamCop o blackhole.mx de Abusix. Se requieren distintos niveles de habilidad para interactuar adecuadamente con diferentes centros.
  2. El centro de informes específico del dominio es la opción recomendada para los usuarios finales. [7] Si se proporciona, debe ser accesible mediante un botón visible o un elemento de menú en el cliente de correo .
  3. Un proveedor de buzón puede seleccionar como destinatario a un suscriptor de un bucle de retroalimentación después de recibir un informe de usuario final. Los usuarios deben conocer la política de su proveedor.
  4. El POC de abuso de un dominio autenticado que gestionó el mensaje denunciado. DomainKeys Identified Mail (DKIM) es el protocolo de autenticación habitual, [8] pero Sender Policy Framework (SPF) se puede utilizar de la misma manera. Una elección del proveedor de buzón.
  5. El POC de abuso para la dirección IP del último retransmisor . Se requiere cierta habilidad para localizar correctamente dichos datos. Esta es la opción predeterminada para un proveedor de buzón cuyo servidor recibió el mensaje abusivo (antes de que el destinatario lo informara) y anotó la dirección IP relevante. Hay varios sitios que mantienen bases de datos de POC, como Network Abuse Clearinghouse (por nombre), Abusix (por dirección IP (número)) y más. También hay una jerarquía de delegaciones en el registro regional de Internet (RIR) relevante, y cada registro Whois correspondiente puede incluir un POC, ya sea como una observación o como un objeto de base de datos más específico, por ejemplo, un equipo de respuesta a incidentes .

Los tres primeros métodos proporcionan direcciones de correo electrónico completas a las que enviar informes. De lo contrario, se puede suponer que los buzones de correo de abuso de destino tienen el formato definido por RFC 2142 ( [email protected] ), o se pueden determinar consultando las bases de datos whois del RIR (que pueden tener límites de resultados de consulta [9] ) u otras bases de datos creadas específicamente para este propósito. Existe una tendencia a exigir la publicación de POC de abuso exactos. [10] [11]

Los receptores que han sufrido abusos pueden automatizar la notificación de spam en distintos grados: pueden pulsar un botón cuando ven el mensaje o pueden ejecutar una herramienta que ponga en cuarentena y notifique automáticamente los mensajes que reconoce como spam. Cuando no hay herramientas específicas disponibles, los receptores tienen que informar de los abusos manualmente ; es decir, reenvían el mensaje spam como archivo adjunto (para incluir el encabezado completo) y lo envían a la autoridad elegida. Los proveedores de buzones de correo también pueden utilizar herramientas para procesar automáticamente las notificaciones de incidentes. [12]

Véase también

Referencias

  1. ^ Félix Schwagereit; Ansgar Scherp; Steffen Staab (14 al 17 de junio de 2011). Encuesta sobre gobernanza del contenido generado por usuarios en comunidades web (PDF) . WebSci'11. ACM . Consultado el 4 de enero de 2012 .
  2. ^ "Sistemas de compartición de hash". wiki . Apache Foundation . Consultado el 15 de agosto de 2012 .
  3. ^ Jason Livingood; Nirmal Mody; Mike O'Reirdan (marzo de 2012). Recomendaciones para la remediación de bots en redes de ISP. IETF . doi : 10.17487/RFC6561 . RFC 6561 . Consultado el 15 de agosto de 2012 .
  4. ^ "Bucle de retroalimentación del correo electrónico: qué es y por qué es importante [2023]". mailtrap.io . 2023-03-01 . Consultado el 2023-04-18 .
  5. ^ Murray Kucherawy , ed. (junio de 2012). Creación y uso de informes de comentarios por correo electrónico: una declaración de aplicabilidad para el formato de informe de abuso (ARF). IETF . doi : 10.17487/RFC6650 . RFC 6650. Consultado el 28 de junio de 2012. En lugar de generar informes de comentarios por sí mismos, los MUA DEBERÍAN crear informes de abuso y enviar estos informes a sus proveedores de buzones de correo para que puedan generar y enviar mensajes ARF en nombre de los usuarios finales (consulte la Sección 3.2 de [RFC6449]). Esto permite el procesamiento y seguimiento centralizados de los informes, y proporciona información de capacitación para los sistemas de filtrado.
  6. ^ Theo Clarke (10 de octubre de 2005). «Finding network abuse contacts» (Encontrar contactos de abuso en la red). Wikimedia Foundation . Consultado el 22 de abril de 2011 .
  7. ^ John R. Levine (9 de diciembre de 2009). "Añadir un botón de spam a los MUA". Lista de correo de ASRG (Mailing list) . Consultado el 22 de abril de 2011 . Véase también el resumen wiki de ese hilo de correo.
  8. ^ JD Falk, ed. (noviembre de 2011). Recomendaciones operativas del bucle de retroalimentación de quejas. IETF . doi : 10.17487/RFC6449 . RFC 6449 . Consultado el 18 de noviembre de 2011 . Apéndice B. Uso de DKIM para enrutar la retroalimentación
  9. ^ "Consulta comunitaria en curso: eliminación del límite de resultados de consultas WHOIS". ARIN . 12 de marzo de 2007 . Consultado el 28 de septiembre de 2009 . [E]l límite de consultas WHOIS de ARIN de 256 resultados [...] ha estado vigente desde el inicio de ARIN como un medio para limitar la extracción de datos.
  10. ^ Leslie Nobile (18 de julio de 2011). "El contacto por abuso será obligatorio según la política 2010-14". anuncios . Registro Americano de Números de Internet . Consultado el 24 de agosto de 2011 .
  11. ^ Tobias Knecht (8 de noviembre de 2010). «Información de contacto sobre abuso». Centro de Información de la Red Asia-Pacífico . Consultado el 22 de abril de 2011 .
  12. ^ Uno es Abusehelper