Desafío – respuesta filtrado antispam

Ir a: navegación, búsqueda de
Este artículo es sobre el correo electrónico. Para otras aplicaciones, vea Autenticación mediante desafío y respuesta.

A desafío – respuesta (o C/R) el sistema es un tipo de filtro anti-spam envía automáticamente una respuesta a un desafío al (presunto) remitente de correo electrónico entrante. En esta respuesta, el remitente se le pide que realice alguna acción para asegurar la entrega del mensaje original, que de lo contrario no entregaría. La acción a realizar es típicamente uno que

  • puede realizarse una vez relativamente sin esfuerzo, pero
  • necesita gran esfuerzo si se realiza en grandes cantidades, de esta manera efectiva filtrando los spammers.

Sistemas de desafío – respuesta sólo necesitan enviar retos a remitentes desconocidos. Los remitentes que previamente han realizado la acción desafiante, o que previamente se han enviado mensajes de correo electrónico, sería automáticamente lista blanca.

Contenido

  • 1 El reto en los sistemas de desafío – respuesta
  • 2 Recomendaciones para los sistemas C/R
  • 3 Críticas
    • 3.1 Retos enviados a direcciones de correo electrónico falsificados
    • 3.2 Temas sociales
    • 3.3 Interacción con las listas de correo u otros automatizado sobres
    • 3.4 Falsos positivos
  • 4 Implementaciones
  • 5 Referencias
  • 6 Enlaces externos

El reto en los sistemas de desafío – respuesta

C/R sistemas intentan proporcionar retos que pueden llevarse a cabo fácilmente por los remitentes legítimos y no fácilmente por los spammers. Dos características que difieren entre los remitentes legítimos y los spammers son explotadas para lograr este objetivo:

  • Los remitentes legítimos tienen un válido Dirección del remitente, mientras que los spammers suelen forjar una dirección de retorno. Esto significa que la mayoría de los spammers no tendrás el reto, haciéndoles fallar automáticamente cualquier acción necesaria.
  • Los spammers envían correo electrónico en grande cantidades y tienen que realizar acciones desafiantes en grandes cantidades, mientras que los remitentes legítimos realizarlo en más de una vez para cada nuevo contacto de correo electrónico.

A continuación son ejemplos de los desafíos que son o podrían utilizarse para explotar estas diferencias:

  • Simplemente enviando una respuesta al mensaje desafiante (no modificada).
  • Un desafío que incluye una dirección URL de la web, que puede ser cargada en una herramienta para responder al desafío de navegación de la web apropiada, así que simplemente haciendo clic en el enlace es suficiente para responder al desafío.
  • Un reto que requiere lectura lenguaje natural las instrucciones sobre cómo responder, con la inclusión de una cadena especial o un código en la respuesta. Por ejemplo, convertir una cadena de fecha (tales como ' Jue 12 de ene 8:45:44 2012') en su correspondiente timestamp (1326379544). Otros Prueba de Turing enfoques incluyen un simple problema o contestar una pregunta sobre el texto o el destinatario.
  • Los sistemas pueden intentar producir desafíos para que respuesta automática es muy difícil, o incluso una sin resolver Inteligencia artificial problema. Un ejemplo (también encontrado en muchos sitios web) es un "CAPTCHA"prueba en la que el remitente es necesaria para ver una imagen que contiene una palabra o frase y responder con esa palabra o frase en el texto.

Hoy en día los sistemas C/R no se utilizan ampliamente suficiente para hacer los spammers se molestó en responder a los desafíos (automáticamente). Por lo tanto C/R sistemas generalmente sólo se basan en un simple desafío que se haría más complicado si los spammers siempre construcción tales respondedores automáticos.

Recomendaciones para los sistemas C/R

Sistemas C/R deben idealmente:

  • Permiten a los usuarios ver y actuar sobre los mensajes en la cola de espera.
  • Cumplir con los requisitos y recomendaciones de RFC 3834.[1]
  • Obedecer a una lista detallada de los principios mantenidos por Brad Templeton,[2] incluyendo lo que permite la creación de direcciones "etiquetados" o permitir códigos colocados ya sea en el Asunto: encabezado o el cuerpo del mensaje — cualquiera de las cuales permiten mensajes debe ser aceptado sin ser desafiado. Por ejemplo el TMDA sistema puede crear direcciones "etiquetas" que permitan:
    • correo enviado desde una dirección particular
    • correo que contiene una cierta "palabra clave"
    • correo que se envía dentro de un periodo pre – conjunto de tiempo, para permitir la correspondencia relacionada con un pedido en línea, pero que luego expira a no permitir futuro e-mail marketing.

Problemas con el envío de los desafíos a direcciones de correo electrónico falsificados pueden reducirse si los desafíos sólo cuando se envían:

  • el encabezado del mensaje está formado correctamente
  • el mensaje es enviado desde una dirección IP con un dominio asociado
  • el servidor ha pasado un greetpause prueba
  • el servidor ha pasado un Greylisting prueba
  • la dirección IP originaria no se encuentra en confianza listas negras
  • Dirección de correo electrónico del remitente no ha fallado una Autenticación de correo electrónico prueba, usando técnicas tales como SPF y DKIM.

Críticas

Los críticos de los sistemas C/R han planteado varias cuestiones acerca de su utilidad como una defensa de correo electrónico. Muchas de estas cuestiones se refieren a todos los programas que auto-responder al correo electrónico, incluidos los administradores de la lista de correo, programas de vacaciones y mensajes de despedida de los servidores de correo.

Retos enviados a direcciones de correo electrónico falsificados

Los spammers pueden utilizar una dirección falsa, inexistente como dirección de remitente (en el De: campo) en el encabezado del correo electrónico, sino que también puede usar un forjado, existente del remitente (válido, pero la dirección de una persona arbitraria sin consentimiento de la persona). Este último se convertiría cada vez más común si por ejemplo verificación de devolución de llamada sería más popular para detectar spam. Sistemas C/R desafiando un mensaje con una dirección de remitente forjadas enviaría su desafío como un nuevo mensaje a la persona cuya dirección fue forjado. Esto crearía correo electrónico retrodispersión, que efectivamente podría recaer la carga de la persona que habría recibido el spam a la persona cuya dirección fue forjado. Además, si el remitente falso decidió validar el desafío, el usuario C/R de todos modos iba a recibir el spam y la dirección del remitente falso sería lista blanca.

Aunque sin duda un efecto secundario indeseable, esta cuestión sería inexistente si gente, cuya dirección de correo electrónico fue utilizado como una dirección falsificada en spam, pasará a dirigir un sistema C/R se. En este caso, uno de los usuarios C/R tendría que implementar algún tipo de dirección de retorno (tales como firma Validación de etiquetas de dirección de rebote) con el fin de asegurar que el desafío pasa por. Además, si los sistemas como SPF y DKIM se convertiría en direcciones de remitente común, forjado sería reconocidos por estos sistemas antes de llegar a un sistema de C/R.

En algunos casos, sistemas C/R pueden ser engañados para convertirse en relés de spam. Para ser útil, una parte del mensaje bajo desafío generalmente está incluida en el mensaje de desafío. Un spammer, sabiendo que está enviando a un C/R usando el sistema, podría diseñar su mensaje para que su carga"spam" es en la parte del mensaje que incluye el mensaje de desafío. En este caso, el remitente falso es el destinatario real del spam y el sistema C/R es involuntariamente el relé.

Temas sociales

Difusión de una dirección de correo ordinario que está protegida por un sistema de C/R se traducirá en quienes envían correo a esa dirección que desafió a sus mensajes. Algunos críticos C/R considera grosero para darles tu dirección de correo electrónico, entonces exigirles (a menos que previamente en lista blanca, que tal vez no siempre es posible) para responder al desafío antes de que pueden enviar por correo.[3]

Los defensores de sistemas C/R sostienen que los beneficios superan por mucho la "carga" de un desafío incidental y que probablemente nunca será una solución definitiva contra el spam sin poner algún tipo de carga sobre el remitente de correo electrónico. Razonan más amplio será el uso de sistemas C/R, más entendidos, aceptados y apreciados estarán. En una analogía con el correo, el emisor está dispuesto a pagar para el sello, en analogía con llamadas telefónicas, el llamador está dispuesto a pagar por la llamada saliente.

Interacción con las listas de correo u otros automatizado sobres

Algunos sistemas C/R interactuarcon mal con el software de la lista de correo. Si una persona suscrita a una lista de correo empieza a utilizar el software de C/R, carteles a la lista de correo pueden ser enfrentados por los mensajes de desafío. Confirmaciones de pedidos, facturación, declaraciones y avisos de entrega de sistemas de compras online suelen ser enviadas mediante sistemas automatizados. Desafíos de correo electrónico enviados a tales sistemas se perderán, y correo legítimo enviado por estos sistemas no alcanzará el usuario del sistema C/R.

Los defensores de sistemas C/R argumentan que, aunque les tomará un esfuerzo extra, soluciones para estos problemas existen si el usuario final del sistema C/R hará estas cosas sencillas:

  • Whitelisting una lista de correo dirección manualmente en cuanto uno se suscribe a él. Nota: para muchos grupos de correo electrónico, el nuevo miembro no sabrá la dirección del grupo hasta que después de recibir el email de "bienvenida", lo que hace inviable esta recomendación.
  • usando 'etiquetas de direcciones de correo electrónico' para listas de correo o automáticos anuncios publicitarios como el de arriba que pueden ser reconocidos y borra automáticamente por el sistema C/R.
  • manualmente la cola de mensajes de inspeccionar y reemplazar la C/R procesan en caso de que un mensaje esperado de un envío automatizado es sostenido por el sistema C/R.

Falsos positivos

C/R los partidarios argumentan que tales sistemas tienen una menor tasa de falsos positivos que otros sistemas de filtrado de correo electrónico masivo no solicitado automáticamente.[citación necesitada]

Los críticos sostienen que los usuarios habituales de los sistemas C/R todavía necesitan revisar su correo desafiado regularmente, buscando correo masivo no o solicitado de correo electrónico a granel para que el remitente no ha respondido al reto.[citación necesitada] Esta cuestión es particularmente notable con boletines de noticias, mensajes transaccionales y otro correo solicitada, como remitentes no generalmente comprueba retos a su correo. Sin embargo, si el correo en cuestión fue solicitado, entonces el usuario C/R podría esperarse que haya agregado a la lista blanca. Si el correo no fue solicitado, entonces por definición es spam[citación necesitada]y se filtrarán correctamente por el sistema C/R.

Implementaciones

  • Agente de entrega de mensajes etiquetados
  • Correo electrónico de canal <-sólo quiere una respuesta, en realidad no trata de determinar si el usuario es humano (así deshacerse de los spammers que no usan emails legítimos y no requieren tratamiento costoso).
  • FairUCE[1] ("Justo uso de correo electrónico comercial no solicitado"), desarrollado por IBM, trató de encontrar una relación de conexión del remitente envolventees nombre de dominio y el Dirección IP entregando el correo del cliente, utilizando una serie de caché DNS búsquedas. Si pudiera encontrar una relación, FairUCE comprobado del destinatario lista blanca y lista negra, así como la reputación del dominio, para determinar si se debe aceptar, rechazar, desafío de reputación o presentar al usuario un conjunto de opciones de la lista blanca/negra. A partir de 2010, el proyecto está catalogado como tecnología "jubilada".

Referencias

  1. ^ RFC 3834:: Recomendaciones para las respuestas automáticas de correo electrónico
  2. ^ Templeton, Brad. "Principios adecuadas para sistemas de desafío/respuesta de anti-spam". 13 de junio 2014.
  3. ^ Schryver, Vernon. "Sistemas de desafío/respuesta considerados dañinos". 13 de junio 2014.

Enlaces externos

  • Servicios de desafío/respuesta de SpamHelp Una lista de proveedores de servicios de filtrado de desafío/respuesta
  • Cuando los filtros de Spam no son suficientes, Walt Mossberg del Wall Street Journal, 22 de marzo de 2007
  • ¿Por qué desafío y respuesta es una mala Idea Julio de 2006
  • Sistemas de desafío-respuesta empeorar Febrero de 2006
  • Desafío-respuesta antispam sistemas considerados dañinos 29 de diciembre de 2003
  • John Levine: Sistemas de desafío y respuesta son tan dañinos como spam Mayo de 2003
  • Una respuesta al desafío y respuesta desafiante Mayo de 2003
  • Lo que necesitas saber sobre desafío – respuesta los filtros de Spam 2003

Otras Páginas

Obtenido de"https://en.copro.org/w/index.php?title=Challenge – response_spam_filtering & oldid = 648297949"