Pregunta ¿Cómo impedir que la gente use mi dominio para enviar spam? [duplicar]


Esta pregunta ya tiene una respuesta aquí:

Recibo mensajes de Mailer Daemon que dicen que ciertos correos electrónicos fallan. Mi dominio es itaccess.org que es administrado por las aplicaciones de Google. ¿Hay alguna manera de identificar quién está enviando correos electrónicos desde mi dominio y cómo lo están haciendo sin que yo cree una cuenta para ellos?

Delivered-To: 7e949ba@itaccess.org
Received: by 10.142.152.34 with SMTP id z34csp12042wfd;
        Wed, 8 Aug 2012 07:12:46 -0700 (PDT)
Received: by 10.152.112.34 with SMTP id in2mr18229790lab.6.1344435165782;
        Wed, 08 Aug 2012 07:12:45 -0700 (PDT)
Return-Path: <whao@www20.aname.net>
Received: from smtp-gw.fsdata.se (smtp-gw.fsdata.se. [195.35.82.145])
        by mx.google.com with ESMTP id b9si24888989lbg.77.2012.08.08.07.12.44;
        Wed, 08 Aug 2012 07:12:45 -0700 (PDT)
Received-SPF: neutral (google.com: 195.35.82.145 is neither permitted nor denied by best guess record for domain of whao@www20.aname.net) client-ip=195.35.82.145;
Authentication-Results: mx.google.com; spf=neutral (google.com: 195.35.82.145 is neither permitted nor denied by best guess record for domain of whao@www20.aname.net) smtp.mail=whao@www20.aname.net
Received: from www20.aname.net (www20.aname.net [89.221.250.20])
    by smtp-gw.fsdata.se (8.14.3/8.13.8) with ESMTP id q78EChia020085
    for <7E949BA@itaccess.org>; Wed, 8 Aug 2012 16:12:43 +0200
Received: from www20.aname.net (localhost [127.0.0.1])
    by www20.aname.net (8.14.3/8.14.3) with ESMTP id q78ECgQ1013882
    for <7E949BA@itaccess.org>; Wed, 8 Aug 2012 16:12:42 +0200
Received: (from whao@localhost)
    by www20.aname.net (8.14.3/8.12.0/Submit) id q78ECgKn013879;
    Wed, 8 Aug 2012 16:12:42 +0200
Date: Wed, 8 Aug 2012 16:12:42 +0200
Message-Id: <201208081412.q78ECgKn013879@www20.aname.net>
To: 7E949BA@itaccess.org
References: <20120808171231.CAC5128A79D815BC08430@USER-PC>
In-Reply-To: <20120808171231.CAC5128A79D815BC08430@USER-PC>
X-Loop: whao@whao.se
From: MAILER-DAEMON@whao.se
Subject: whao.se:  kontot avstängt - account closed
X-FS-SpamAssassinScore: 1.8
X-FS-SpamAssassinRules: ALL_TRUSTED,DCC_CHECK,FRT_CONTACT,SUBJECT_NEEDS_ENCODING

    Detta är ett automatiskt svar från F S Data - http://www.fsdata.se

    Kontot för domänen whao.se är tillsvidare avstängt.
    För mer information, kontakta info@fsdata.se

    Mvh,
    /F S Data

    -----

  This is an automatic reply from F S Data - http://www.fsdata.se

  The domain account "whao.se" is closed.
  For further information, please contact info@fsdata.se

  Best regards,
  /F S Data

105
2017-08-08 14:17


origen


En caso de que desee seguir buscando en la web ese problema, se llama el término común para ese tipo de uso incorrecto del correo electrónico. Joe Job. - Oliver
El problema NO es que alguien reclame ser TÚ (tu dominio), sino que alguien (otra persona) les esté creyendo. Si le enviara un correo electrónico diciendo que es DE Barack Obama, ¿me creería? Por supuesto no. Usted está recibiendo "retrodispersión". Reclame a quienes hayan aceptado el correo electrónico falso ("joe job") y hayan aceptado que la dirección de origen era correcta. Pero haga esto SOLAMENTE si su dominio ofrece registros SPF que muestran de dónde (direcciones, hosts) puede provenir el único correo válido. - Skaperen


Respuestas:


Ya que no se ha declarado explícitamente todavía, lo diré.

Nadie está usando tu dominio para enviar spam.

Están utilizando datos falsificados del remitente para generar un correo electrónico que parece provenir de su dominio. Es tan fácil como poner una dirección de devolución falsa en un correo postal, así que no, realmente no hay forma de detenerlo. El SPF (como se sugiere) puede facilitar que otros servidores de correo identifiquen el correo electrónico que actualmente proviene de su dominio y de un correo electrónico que no lo hace, pero al igual que usted no puede evitar que ponga su dirección postal como la dirección de retorno de todas las amenazas de muerte que envío, no puede evitar que alguien ponga su dominio como respuesta. -para direccionar en su spam.

SMTP simplemente no fue diseñado para ser seguro, y no lo es.


137
2017-08-08 15:10



+1 por la analogía del correo postal. Ese es el que siempre uso con personas no técnicas. Nadie tiene que irrumpir en su casa para enviar un correo saliente con su dirección de retorno. Solo necesitan poder colocarlo en un buzón. - Evan Anderson
Es posible que desee vincular explícitamente a las respuestas en lugar de simplemente decir "como se sugiere" - Thorbjørn Ravn Andersen
De Verdad? ¿¡Tú eres el que envía todas esas amenazas de muerte? :) - John Robertson
Es gracioso que todos con los que trabajo, más todos aquí, siempre usen el verdadero ejemplo de barakobama@whitehouse.gov. - Captain Hypertext
Para ser más correctos, debe decir: Nadie está usando su servidor (de dominio) para enviar spam. Porque usan el dominio, es decir, como la dirección FROM. Por supuesto, el SPF no es una barrera en absoluto, porque el remitente utilizará un servidor Hop que no realiza comprobaciones de SPF. La solución sería simple: el servidor responsable de la dirección TO debe rechazar con 450 al servidor donde se origina el correo, no enviar un DSN al servidor que es responsable de la dirección FROM - roothahn


Es la naturaleza de SMTP (el protocolo utilizado para transferir correo) que no se realiza ninguna validación en la dirección del remitente que figura en un correo electrónico. Si desea enviar un correo electrónico que parece provenir de president@whitehouse.gov... puedes seguir adelante y hacer eso, y en muchos casos no hay nada que alguien pueda hacer para detenerte.

Dicho esto, si se establece Registros SPF para su dominio, existe una mayor posibilidad de que los sistemas receptores reconozcan el correo electrónico falsificado como spam. Un registro SPF identifica los sistemas que pueden originar correo para su dominio. No todos los sistemas receptores prestan atención a los registros SPF, pero los proveedores de correo electrónico más grandes utilizarán esta información.


100
2017-08-08 14:23



Específicamente para Google Apps puedes seguir estos pasos. - MichaelHouse
También tengo este problema en este momento, y mis registros SPF son correctos. Desafortunadamente, muchos de los grandes proveedores de correo ignoran los registros SPF. Incluyendo luminarias como Yahoo. :-( - staticsan
No te olvides de DomainKeys. DKIM. - desbest


Respaldo las respuestas ya dadas con respecto al SPF (¡+1, cada uno de ustedes!) Pero tenga en cuenta que si decide ir por este camino, y es un buen camino, hay No tiene sentido en hacerlo a menos que te identifiques y anuncies todos hosts que están aprobados para enviar correos electrónicos para su dominio, y no permiten todos los demás con -all.

No solo lo hará ?all y ~all no tiene el efecto deseado, pero algunos administradores de correo en SF los consideran un signo de dominio de remitente de spam positivo.


35
2017-08-08 14:48



La guía de Google sobre la creación de una entrada SPF para dominios que usan Google Apps para enviar correo: "La publicación de un registro SPF que use" todo en lugar de ~ todo "puede ocasionar problemas de entrega". - Ariel
Si puede ese es el punto central de esto. Siempre y cuando haya enumerado de forma exhaustiva a aquellos hosts que pueden enviar legítimamente su correo, quieres que todos los otros hosts tengan problemas de entrega; Los problemas solo te afectarán si has ha fallado para enumerar todos sus servidores de envío válidos, y eso es a lo que se refiere Google. Ver el comentario de Chris S en serverfault.com/questions/374452/… para un ejemplo de un administrador que toma en contra inútil (que carece de un -all) Registros SPF. - MadHatter
Pero si usas -all, cualquier persona que utilice reenvío de correo No recibirá el correo. Creo que la gente todavía usa el reenvío de correo (si deberían usarlo es otra pregunta) - netvope
Tienes toda la razón, pero para eso sirve SRS (Sender Rewriting System). Yo diría que debería entenderse que el SPF y el reenvío simple (no SRS) se excluyen mutuamente y que los administradores deben elegir solo uno, no es que aún se pueda usar SPF junto con el simple reenvío si solo cambia -all a por ejemplo ~all. Eso es esencialmente no usar SPF en absoluto. - MadHatter
Los administradores de correo pueden estar usando -all, pero cada host compartido incluye correo electrónico en estos días. Una falla total se considera una mala configuración que no debe tomarse en serio mientras que una falla suave es. Es por eso que después de analizar toneladas de spam y uso de SPF, la puntuación SPF_SOFTFAIL predeterminada de SpamAssassins es más alta que la SPF_FAIL predeterminada. ¿Cuál es exactamente el problema con DMARC? Si sus listas de correo se ven afectadas por una política de DMARC, sus envíos masivos de correo no están configurados correctamente. Proporciona más control sobre su SPF y proporciona informes de retroalimentación. ¿Le dice a todos los usuarios de Yahoo que no van a recibir su correo masivo? - J.Money


Marco de política del remitente (SPF) puede ayudar. Es un sistema de validación de correo electrónico diseñado para evitar el spam de correo electrónico mediante la verificación de las direcciones IP del remitente. SPF permite a los administradores especificar qué hosts pueden enviar correo desde un dominio determinado mediante la creación de un registro SPF específico (o registro TXT) en el Sistema de nombres de dominio (DNS). Los intercambiadores de correo usan el DNS para verificar que el correo de un dominio dado está siendo enviado por un host autorizado por los administradores de ese dominio.


20
2017-08-08 14:22





No parece que un SPF hubiera ayudado en este ejemplo en particular. Es poco probable que una máquina que se molestó en verificar los registros de SPF para rechazar el correo esté tan dañada como para aceptar correo para un dominio inexistente, luego decide que no puede entregarlo y genera el mensaje de rebote. Si mail-gw01.fsdata.se, la máquina que acepta el correo para whao.se, lo ha rechazado correctamente, su mensaje de devolución procederá de un servidor SMTP de Google.

Lamentablemente, este tipo de comportamiento roto (aceptar y luego generar un rebote) no es tan infrecuente. No hay nada que pueda hacer para evitar que alguna máquina aleatoria simule que tiene un mensaje para entregar desde su dominio. Tampoco hay nada que puedas hacer sobre los rebotes retrasados.

Sin embargo, puedes tener menos de estos rebotes para leer. Si 7E949BA no es un usuario real en itaccess.org, como sospecho que no lo es, está recibiendo el mensaje de rebote porque tiene su dirección de captura de datos habilitada. Un catch-all significa que su dominio aceptará un correo electrónico para cualquier usuario inexistente y se lo entregará. Esta es principalmente una buena manera de aumentar su colección de mensajes de spam y de rebote. En Google Apps, para configurar su alcance, está en "Administrar este dominio" -> Configuración -> Correo electrónico, aproximadamente a la mitad.


5
2017-08-09 01:22





Una idea aún no mencionada es rechazar la retrodispersión. Todo lo que he visto llega a través de retransmisiones de correo abierto, y hay dos listas negras que pueden ser útiles para reducir la cantidad de retrodispersión que recibe.

  • Backscatterer es un DNSBL que enumera explícitamente los servidores SMTP que envían llamadas de retrodifusión y remitente.

  • RFC-Ignorante es un DNSBL que enumera servidores SMTP que no obedecen a varios RFC importantes.

Al agregar estos (junto con otros BL más enfocados tradicionalmente) se redujo la cantidad de retrodispersión que recibí en más del 90%.


3
2017-08-09 16:31





A lo que te refieres se le llama en realidad un ataque BACKSCATTER. Ahora lo que es en realidad ya está explicado muy arriba.

Cómo resolverlo ?

Backscatter se puede evitar con soluciones auto hospedadas como Postfix, qmail y exim, etc., pero no con googleapps, ya que es popular por no tener protección presente para tratar con backscatter, Excepto solo los registros SPF.


3
2017-08-08 20:53





Como las otras respuestas han mencionado, está recibiendo rebotes de los correos electrónicos de otra persona. SpamCop anteriormente no ha llamado a este spam, pero en estos días acepta informes para esto. P.ej. Copié el mensaje que citó (y he incluido mi cuenta de Gmail para determinar mis servidores de correo) y obtuve este resultado (que cancelé).

En resumen, puede utilizar SpamCop para informar a los remitentes de estos reembolsos. No detiene (directamente) a los iniciadores del problema, pero puede reducir estos rebotes.


0
2017-08-09 05:10





El sistema de correo se basa en From: encabezados, que son muy fáciles de falsificar.

Por ejemplo, este código PHP:

mail('someone@live.com', 'Your new Outlook alias is ready to go', 'Ha ha! This is spoofed!', "From: Outlook Team<member_services@live.com>\r\n");

enviará un correo electrónico a someone@live.com pretendiendo ser el equipo de Outlook.


-1
2017-08-08 22:19



No, se basa en el remitente del "sobre" SMTP (y también en los destinatarios) (los enviados en el MAIL FROM comando), que puede ser completamente diferente al encabezado De :. - derobert
@derobert De acuerdo, no lo sabía. ¡Gracias! - uınbɐɥs
Continúa y edita tu publicación para corregirla ... esa es una de las muchas razones recomendadas para usar el enlace de edición. - derobert