Autenticación de correo electrónico

Ir a: navegación, búsqueda de

Autenticación de correo electrónico es un conjunto de técnicas destinadas a dotar a los mensajes de la Correo electrónico sistema de transporte con información verificable. Es un grano grueso autenticación, generalmente en el administrativo gestión de dominio (ADMD)[1] nivel,[2] e implica una especie de no autorización. Es decir, el propósito de autenticación de correo electrónico es validar la identidad de las partes que participaron en la transferencia de un mensaje, como puede modificar el mensaje. Los resultados de dicha validación pueden utilizarse en las decisiones de la entrega, que quedan fuera del ámbito de autenticación de correo electrónico correcta y son muy diferentes en la naturaleza de filtrado de contenido.

Contenido

  • 1 Análisis razonado
  • 2 Naturaleza del problema
    • 2.1 Envío desde dentro de la red de ADMD (MUA 1)
    • 2.2 Vagando por usuario (MUA 2)
    • 2.3 Usuario desconectado
    • 2.4 Notas al pie
  • 3 Métodos de autenticación
    • 3.1 SPF
    • 3.2 DKIM
    • 3.3 ADSP
    • 3.4 DMARC
    • 3.5 VBR
    • 3.6 iprev
  • 4 Autenticación-resultados
  • 5 Crítica
  • 6 Véase también
  • 7 Notas
  • 8 Referencias

Análisis razonado

Asegurando un identidad válido en un correo electrónico se ha convertido en un paso vital para detener spam (como puede filtrar correo electrónico basado en una identidad tan), falsificación, fraude y delitos aún más graves. El Simple Mail Transfer Protocol (SMTP) está evolucionando continuamente, pero cuando se diseñó, en la década de 1980, fue el ámbito de la academia y las agencias gubernamentales, y como tal, no había ningún motivo para considerar la seguridad. Previo sin verificación formal del remitente.

Firmar mensajes de correo electrónico es un buen primer paso para identificar el origen del mensaje, pero no establece si esa identidad tiene una buena reputación o si debería ser confiable.

Este artículo explica cómo se forjan identidades de correo electrónico y los pasos que se están tomando ahora para prevenirlo.

Naturaleza del problema

Autenticación de correo electrónico se puede complicar por la presencia de un relevo intermedio. A y B claramente pertenece al autor ADMD, mientras D y E forman parte de la red receptora. ¿Qué papel tiene C ¿jugar?

El camino representado a la izquierda puede ser reconstruido en el terreno de la rastrear los campos de encabezado que cada host agrega a la parte superior de la cabecera cuando recibe el mensaje:[3]

Es importante tener en cuenta que las primeras líneas en la parte superior de la cabecera son generalmente de confianza por parte del receptor. De hecho, esas líneas están escritas por máquinas en ADMD del destinatario, que actúan sobre su mandato explícito. Por el contrario, las líneas prueban la participación de A y B, así como de presunto autor MUA podría ser una falsificación creada por C. El Recibido: campo que se muestra arriba es una pieza transcendentales de la cabecera. El Return-Path: escrito por E, la MDA, basado en el mensaje envolvente. Campos de rastro adicional, diseñados para la autenticación de correo electrónico, pueden rellenar la parte superior de la cabecera.

Normalmente, los mensajes enviados por ADMD un autor ir directamente al destino MX (eso es B → D en las figuras). ADMD del remitente puede agregar tokens de autenticación sólo si el mensaje va a través de sus cajas. Los casos más comunes pueden esquematizarse de la siguiente manera:

Una representación esquemática de las formas más comunes que un mensaje de correo electrónico puede ser transferido de su autor a su destinatario.

Envío desde dentro de la red de ADMD (MUA 1)

  • La ADMD MSA autentica al usuario, ya sea basado en su Dirección IP o algún otro Autenticación SMTP significa. Dependiendo de la dirección del destinatario, el mensaje puede seguir el camino normal o pasar a través de una lista de correo o un servicio de reenvío.[Nota 1] B puede ser una salida Proxy SMTP o un smarthost.[Nota 2]
  • Si la red local no bloquea salida puerto 25 conexiones,[Nota 3] el usuario puede implementar algún software "directo-a-mx".[Nota 4] Por lo general, zombies y otros hosts maliciosos comportan de esa forma.
  • Si el MUA está mal configurado, también puede utilizar un relé diferente, tales como un anticuado abierto relé, que a menudo no autenticar al usuario.

Vagando por usuario (MUA 2)

  • Mayoría de las veces es posible utilizar uno es propio ADMD MSA.[Nota 5]
  • Conexiones salientes a puerto 25 pueden ser interceptadas y un túnel a un proxy transparente.[Nota 4]
  • Un MUA puede configurarse para utilizar un relé SMTP que ofrece el proveedor de red local como un bono.[Nota 4]

Usuario desconectado

  • Una máquina de tarjetas puede enviar correo en nombre de un cliente que escribe direcciones de correo electrónico en el teclado local; algunas formas de web pueden ser considerados para trabajar de manera similar.[Nota 4]

Notas al pie

  1. ^ Por ejemplo, un usuario puede indicar Gmail para reenviar mensajes a una dirección de correo electrónico diferente. El remitente no es necesariamente consciente de eso.
  2. ^ Servidores proxy configurado correctamente aparece como parte de la autora ADMD.
  3. ^ Algunos ADMDs bloquean de conexión saliente al puerto 25 (SMTP) para evitar esto. Esta técnica proactiva se describe en RFC 5068. Además, algunos bloquean las conexiones SMTP entrantes de IPs catalogado como acceso telefónico a redes/ DSL/cable.
  4. ^ a b c d En este caso ADMD del autor no está implicado en absoluto.
  5. ^ Algunos grueso ISP bloquea puerto 587, aunque RFC 5068 claramente dice:

    Acceso proveedores no debe bloquear usuarios accedan a Internet externo mediante el envío de puerto 587.

Métodos de autenticación

SPF

SPF autentica la dirección IP del remitente.
Artículo principal: Sender Policy Framework

Comprobaciones SPF si del remitente Dirección IP está autorizado por uno de los ADMDs identificados.

La dirección IP de la MTA envía está garantizada para ser válida por la Transmission Control Protocol, como establece la conexión comprobando que el host remoto es accesible.[4] El MX recibe el HELO SMTP comando justo después de la conexión se establece y recibe un Dirección de rebote al principio de cada mensaje. Ambos pueden contener un nombre de dominio. Las consultas de verificador SPF el Sistema de nombres de dominio (DNS) para un registro SPF etiquetados con ese nombre. Un ADMD compatible con SPF debe publicar que registro de antemano, declarando que direcciones IP es o no es autorizados a utilizar el nombre de dominio en la etiqueta. El verificador encuentra entonces Directiva del registro que coincida con la dirección IP del remitente MTA y devuelve el resultado asociado. Se puede "pasar", "fracaso" o un resultado intermedio. Cuando el resultado es "pasar", el correspondiente nombre de dominio es la identidad autenticada.

Generalmente, ADMDs autorizar a las direcciones IP utilizadas por sus propios MTAs salientes, incluyendo cualquier proxy o pasarela. De esa manera, los mensajes enviados por las cajas de un ADMD conseguir autenticados si fluyen a través de la ruta normal. De lo contrario, a menos que el relevo intermedio (a veces llamado mediador) toma medidas concretas, autenticación SPF no tiene éxito.[5] Las medidas específicas consisten en alterar la dirección de rebote, que frecuentemente lo hacen listas de correo y servicios en general no.[6]

Un MX puede rechazar "FAIL", pero es exigente hacerlo aún evitando falsos positivos, porque eso implica mantener una lista de servicios legítimos.[7]

DKIM

DKIM autentica partes del contenido del mensaje.
Artículo principal: Correo identificado DomainKeys

DKIM cheques el contenido del mensaje, desplegando firmas digitales. En lugar de usar certificados digitales, las claves para verificación de firma se distribuyen mediante el DNS. De esa manera, un mensaje consigue asociado a un nombre de dominio.[8]

Un ADMD compatible con DKIM genera uno o más pares de llaves asimétricas, entonces las manos privadas las llaves a la MTA firma y publica las claves públicas en el DNS. Las etiquetas DNS están estructuradas como Selector. _domainkey.example.com, donde Selector identifica el par de claves, y _domainkey es una palabra clave fija, seguida por el nombre de dominio de la firma para que la publicación se produce bajo la autoridad de ADMD de ese dominio. Justo antes de inyectar un mensaje en el sistema de transporte SMTP, el MTA firma crea una firma digital que cubre los campos seleccionados de la cabecera y el cuerpo (o sólo su comienzo). La firma debe cubrir los campos de encabezado sustantivos tales como De:, Para:, Fecha:, y Asunto:, que pueden ser elegidos sobre una base por cada mensaje y luego se añade el encabezado del mensaje, como un campo de rastro. Cualquier número de relés puede recibir y reenviar el mensaje. En cualquier salto, la firma puede ser verificada por la recuperación de la clave pública en el DNS. Si la firma se verifica con éxito, el nombre de dominio es la identidad autenticada.

El propósito de una firma DKIM no es asegurar la integridad del mensaje. A menudo, no ni siquiera garantiza que un mensaje de datos del autor, según una firma De: del campo, tiene un nombre real o un buzón de correo válido. Las partes a firmar son elegidos con el fin de identificar inequívocamente el mensaje. Una firma válida sólo indica que el mensaje en realidad fluir a través de una caja operada por esa ADMD.[9]

Mientras relés intermedios no modifican partes firmadas de un mensaje, su firma DKIM siguen siendo válida. Cualquier relé que participa en la transferencia del mensaje puede firmarlo alternadamente. Mientras intermedios relés normalmente pueden agregar campos de encabezado sin romperse existentes firmas DKIM, cambio de conjunto de caracteres, añadiendo una etiqueta con el tema, agregando un pie de página, o "fijación" del MIME estructura de un mensaje son propensos a romperlas. Muchas listas hacer esos cambios. El protocolo no puede garantizar la supervivencia de la firma después de su tránsito, incluso en la ausencia de malicia y no prescribe en ese caso ninguna acción en particular.

ADSP

Artículo principal: Autor dominio firma prácticas

ADSP permite para especificar una política para los mensajes firmados por dominio del autor. Un mensaje tiene que ir primero a través de la autenticación DKIM, luego ADSP puede exigir un tratamiento castigar si el mensaje no está firmado por los dominios de autor — según la De: campo de encabezado.[10]

El récord ADSP Example.com, si los hubiere, se publica en el DNS bajo el sello _adsp._domainkey.example.com.

ADSP está diseñado para dominios muy maltratados por "phishing" y fraude similar. Quieren renunciar a las instalaciones tales como listas de correo y informes de no entrega, que puede suceder a permanecer sin firma, a cambio de un corte en el abuso.[11]

ADSP fue degradado a histórico en noviembre de 2013.

DMARC

Artículo principal: Autenticación de mensajes basado en dominios, Reporting & conformidad

DMARC permite para especificar una política para mensajes autenticados. Considera como un método de autenticación combinada tanto SPF y DKIM.

La "R" de DMARC, informes, consiste en el suministro de retroalimentación para el dominio del autor sobre cómo hacen sus métodos de autenticación, proporcionando así para la elaboración de políticas informadas.

VBR

Artículo principal: Respondo por referencia

VBR agrega un voucher para una identidad ya autenticada. Este método requiere algunas autoridades reconocidos a nivel mundial que certifican la reputación de los dominios.

Un remitente puede aplicar para obtener una referencia a una autoridad que atestigua. La referencia, si acepta, se publica en el ramal de DNS gestionado por dicha autoridad. Un remitente acreditado debe agregar un VBR-Info: campo de encabezado a los mensajes que envía. También debería añadir una firma DKIM, o utilizar algún otro método de autenticación, como SPF. Un receptor, después de validar la identidad del remitente, puede verificar el atestigua afirmado en VBR-Info: por buscar la referencia.[12]

iprev

Artículo principal: DNS inverso hacia adelante-confirmado

Las aplicaciones deben evitar usar este método como medio de autenticación.[13] Sin embargo, a menudo es llevada hacia fuera y sus resultados, si los hubiere, escrito en el Recibido: campo de encabezado además de la información de TCP requerida por la especificación SMTP.

La IP inversa, confirmada por buscar la dirección IP del nombre encontrado, es sólo una indicación de que la dirección IP fue configurada correctamente en el DNS. El resolución inversa de un rango de IP direcciones pueden delegarse a la ADMD que las utiliza,[14] o puede seguir siendo manejado por el proveedor de la red. En este último caso, no puede obtenerse identidad útil relacionada con el mensaje.

Autenticación-resultados

Autenticación-resultados: es un campo de cabecera del rastro donde un receptor registra los resultados de controles de autenticación de correo electrónico que se llevaron a cabo.[13] Resultados múltiples para múltiples métodos pueden ser registrados en el mismo campo, separados por punto y coma y envuelto en su caso. Por ejemplo, el siguiente campo es supuestamente escrito por ejemplo.org e informes SPF y DKIM Resultados:

El primer token después el nombre del campo, Receiver.example.org, es el identificador del servidor de autenticación, denominado AuthServ-id. Un receptor de apoyo RFC 7001 es responsable de eliminar (o Renombrar) cualquier cabecera falsa diciendo que pertenecen a su dominio, para que aguas abajo filtros no se confunden. Sin embargo, esos filtros todavía necesitan ser configurado, como tienen que saber que las identidades puede utilizar el dominio.

Para un agente de usuario de correo (MUA), es ligeramente más difícil saber qué identidad puede confiar. Puesto que los usuarios pueden recibir correo electrónico de múltiples dominios — si tienen varias direcciones de correo electrónico — cualquiera de esos dominios podría dejar Autenticación-resultados: campos pasan porque parecían neutrales a ellos. De esa manera, un remitente malicioso puede forjar una AuthServ-id que el usuario podría confiar en si el mensaje llegó desde un dominio diferente. Para mantenerse separado de los campos de encabezado forjado, MUAs sólo deben confiar en los que cerca de la parte superior de la cabecera. Un legítimo Autenticación-resultados: aparece justo por encima de un Recibido: campo por el mismo dominio que el mensaje fue obtenido de. Adicional Recibido: los campos pueden aparecer entre la parte superior de la cabecera y como el mensaje fue transferido internamente entre servidores pertenecientes a que mismo, confianza ADMD.

El Autoridad de números asignados de Internet mantiene un registro de Parámetros de autenticación de correo electrónico. No todos los parámetros deben ser registrados, sin embargo. Por ejemplo, puede haber valores de "política" diseñados de un sitio sólo para uso interno, que no necesita registro. Además, este campo del encabezado está destinado a informar de los resultados basados en datos que ya están presentes en el mensaje; por lo tanto, utilizar este filtro para almacenar un adicional valor — por ejemplo, qué pasa con el remitente aparezca en un DNSWL— No es compatible con RFC 7001y no susceptibles de estandarización.

Crítica

Algunos expertos adoptar la posición que el ISP es el mayor inconveniente para la correcta eliminación de spam. La premisa es que los organismos reguladores no tienen ninguna autoridad y los ISP no tienen ningún incentivo.

"Autenticación no puede detener el spam, a menos que el servicio de policía/reputación/autoridad de certificación a cargo revoca certificados para mandar spam. Si eso podría suceder, entonces los ISP también estaría dispuesto e incluso entusiasmados con terminación de cuentas o de lo contrario controlar (por ejemplo bloque puerto) sus remitentes de spam. Si ISPs haría eso, entonces no habría ningún spam necesitan autenticación para detener el spam y tan necesario para una CA jugando a policía. Mientras ISPs permanecen reacios a la policía sus propios clientes de spam, ellos nunca trataría con un CA dispuesto a jugar al policía.
Autenticación de TLS, SMTP-AUTH o S/MIME no puede parar retrodispersión por las mismas razones SPF, DKIM y el resto fueron, son y serán siempre impotente contra él. Algunas de esas razones son Yahoo todavía no firma DKIM sobre todo el correo saliente Hotmail publica aún whishywashy SPF RRs y tampoco requiere su solución de falsificación snakeoil en correo entrante".
--Vernon Schryver)Suma de control distribuido Clearinghouse operador)

Véase también

  • DMARC
  • Encriptación de correo electrónico
  • La falsificación de correo electrónico
  • Ident
  • Secure Messaging

Notas

  1. ^ Dave Crocker (julio de 2009). Arquitectura de correo de Internet. IETF. RFC 5598. https://Tools.ietf.org/html/rfc5598. 02 de febrero de 2013. "Actores administrativos pueden asociarse con organizaciones diferentes, cada una con su propia autoridad administrativa. Esta independencia operativa, juntada con la necesidad de interacción entre grupos, proporciona la motivación para distinguir entre dominios administrativos de gestión (ADMDs)".
  2. ^ "Cumbre de autenticación de correo electrónico". Taller. Comisión Federal de comercio. 9 – 10 de noviembre de 2004. 4 de febrero 2013. El informe, sin embargo, identificó a nivel de dominio autenticación como un prometedor desarrollo tecnológico
  3. ^ John Klensin (octubre de 2008). Simple Mail Transfer Protocol. IETF. RFC 5321. https://Tools.ietf.org/html/rfc5321. 01 de febrero de 2013. "Cuando el servidor SMTP acepta un mensaje para transmitir o para la entrega final, inserta un registro de seguimiento (también denominado indistintamente una"línea de sello de tiempo"o"Recibido"línea) en la parte superior de los datos de correo. Este registro de rastro indica la identidad del huésped que enviaron el mensaje, la identidad de la acogida que recibió el mensaje (y está insertando este sello de tiempo), y la fecha y hora se recibió el mensaje. Los mensajes retransmitidos tienen múltiples líneas de sello de tiempo".
  4. ^ Falsificación de dirección IP es posible, pero generalmente implica un menor nivel de comportamiento criminal (allanamiento de morada, escuchas telefónicas, etc.), que son demasiado arriesgado para un típico hacker spammer o servidores inseguros no implementar RFC 1948, véase también Secuestro de transmisión Control protocolo #Connection.
  5. ^ Scott Kitterman (abril de 2014). Sender Policy Framework (SPF) para autorizar el uso de dominios de correo electrónico, versión 1. IETF. RFC 7208. https://Tools.ietf.org/html/rfc7208. 26 de abril de 2014. "Hay que tres lugares que pueden utilizarse técnicas para mejorar fallas imprevistas SPF con mediadores".
  6. ^ J. Klensin (octubre de 2008). "Alias". Simple Mail Transfer Protocol. IETF. 3.9.1 segundos. RFC 5321. https://Tools.ietf.org/html/rfc5321#Section-3.9.1. 15 de febrero de 2013.
  7. ^ Scott Kitterman (21 de noviembre de 2009). "¿Qué tan confiable es a bloque o rechazar Fail SPF?". SPF-ayuda. Gossamer-threads.com. Creo que es generalmente bien mientras ofrecen un mecanismo de listas blancas de agentes no-SRS.
  8. ^ D. Crocker; T. Hansen; M. Kucherawy, eds (septiembre de 2011). DomainKeys identificado firmas Mail (DKIM). IETF. RFC 6376. https://Tools.ietf.org/html/rfc6376. 18 de febrero de 2013. "DomainKeys identificado Mail (DKIM) permite que una persona, papel u organización para reclamar cierta responsabilidad en un mensaje al asociar un nombre de dominio con el mensaje, que están autorizados a utilizar".
  9. ^ Dave Crocker (16 de octubre de 2007). "DKIM Frequently Asked Questions". DKIM.org. 17 de febrero 2013.
  10. ^ E. Allman; J. Fenton; M. Delany; J. Levine (agosto de 2009). DomainKeys identificado Mail (DKIM) autor dominio firma prácticas (ADSP). IETF. RFC 5616. https://Tools.ietf.org/html/rfc5616. 18 de febrero de 2013.
  11. ^ Barry Leiba; Mike Thomas; Dave Crocker (2011), "dominio firma prácticas (ADSP) autor: punto y contrapunto", Internet Computing (IEEE) 15 (páginas 1 = 76-80), Doi:10.1109/MIC.2011.1
  12. ^ P. Hoffman; J. Levine; A. Hathcock (abril de 2009). Respondo por referencia. IETF. RFC 5518. https://Tools.ietf.org/html/rfc5518. 18 de febrero de 2013.
  13. ^ a b Murray Kucherawy (septiembre de 2013). Campo de encabezado de mensaje para indicar el estado de autenticación de mensaje. IETF. RFC 7001. https://Tools.ietf.org/html/rfc7001. 27 de septiembre de 2013.
  14. ^ H. Eidnes; G. de Groot; P. Vixie (marzo de 1998). Categoría "Classless" IN-ADDR.Delegación de ARPA. IETF. RFC 2317. https://Tools.ietf.org/html/rfc2317. 18 de febrero de 2013.

Referencias

MacQuigg, David. "Autenticación de correo electrónico". Archivado de el original en 2007-11-18. 2007-12-05.

  • v
  • t
  • e
Spam
Protocolos
E-mail-spam
  • Dirección soluci├│n
  • Software de correo electrónico a granel
  • Directorio cosecha ataque
  • Trabajo de Joe
  • DNSBL
  • DNSWL
  • Spambot
  • Contrato de rosa
Otros
  • Marcador automático/Robocall
  • Flyposting
  • Fax basura
  • Mensajería
  • Teléfono móvil
  • Grupos de noticias
  • Telemarketing
  • VoIP
Anti-spam
  • Dirección de correo electrónico desechables
  • Autenticación de correo electrónico
  • SORBS
  • SpamCop
  • Spamhaus
  • Lista, envenenamiento
  • Naive Bayes filtrado de spam
  • Red abuso Clearinghouse
  • Suma de control distribuido Clearinghouse
Spamdexing
  • Relleno de palabras clave
  • Bomba de Google
  • Sitio de raspador
  • Granja de enlace
  • Camuflaje
  • Página de entrada
  • Redirección de URL
  • Blogs de spam
  • Sping
  • Spam del Foro
  • Blog spam
  • Spam social
  • Spam referente
  • Parásito hosting
Fraude en Internet
  • Advance-fee fraude
  • Estafa de lotería
  • Ganar dinero rápido
  • "Phishing"
  • Vishing
  • v
  • t
  • e
Estafas y trucos de confianza
Terminología
  • Estafa
  • Cuenta del error
  • Señuelo
  • Chanta
  • Lista de primos
Notables estafas y
trucos de confianza
  • Estafa de espectro 2G
  • 419 estafas
  • Estafa de estudiante de arte
  • Juego de tejón
  • Carnada y cambio
  • Estafa de dinero negro
  • Estafa de bendición
  • Fideicomiso falso
  • Sala de calderas
  • Estafa de novia
  • Fraude de caridad
  • Clip de empalme
  • Estafa de asignación del carbón
  • Juegos de combinar colores moneda
  • Moneda estafas del balanceo
  • Caída de timo
  • Cheque vergonzoso
  • Estafas laborales
  • Juego de violín
  • Letra
  • Estafa de forraje
  • Plan de rescate de ejecución hipotecaria
  • Fraude de moneda extranjera
  • Fraude de adivinación
  • Gema estafa
  • Esquema de hacerse rico rápido
  • Estafa de productos verdes
  • Presionante
  • Estafas de propiedad intelectual
  • Doblas
  • Firma de largo
  • Estafa Coches milagro
  • Burlarse de subasta
  • Estafa en movimiento
  • Patente seguro
  • Cerdo en un poke
  • Paloma gota
  • Estafa del fondo de asistencia para desarrollo de prioridad
  • Bomba y descarga
  • Recarga de estafa
  • Salazón
  • Juego de conchas
  • Engaño bebé enfermo
  • Estafa de reparación de la esclavitud
  • Prisionero Español
  • Estafa llamada Strip search
  • Pantanos de Florida
  • Soporte técnico estafa
  • Fraude de mercadeo telefónico
  • Sastre tailandés estafa
  • Estafa tailandés zig zag
  • Tres cartas Monte
  • Caballo de Troya
  • Furgoneta blanca altavoz estafa
  • Esquema de trabajo en el hogar
Estafas de Internet y
contramedidas
  • Avalancha
  • Haga clic en fraude
  • Delitos informáticos
  • Abarrotar
  • CyberThrill
  • DarkMarket
  • Estafas de nombre de dominio
  • Autenticación de correo electrónico
  • Fraude de correo electrónico
  • Vigilancia de Internet
  • Estafa de lotería
  • PayPai (PayPaI)
  • "Phishing"
  • Referer "spoofing"
  • Informe Ripoff
  • Rock Phish
  • Estafa romance
  • Red de negocios ruso
  • SaferNet
  • Scam baiting
  • ShadowCrew
  • URL falsificado
  • Ataques Spoofing
  • Generación de acciones
  • Calificaciones de reputación Web
  • Whitemail
  • Clickjacking
Pirámide y
Ponzi esquemas
  • Aman Futures Group
  • Bernard Cornfeld
  • Caritas
  • Doña Branca
  • Fundación para la Nueva Era filantropía
  • Fraude de franquicia
  • Programa de inversión de alto rendimiento (HYIP)
  • Los inversores extranjeros servicio
  • Esquema de Kubus
  • Escándalo Madoff investment
  • Ganar dinero rápido
  • Esquema de la matriz
  • MMM
  • Petters Group Worldwide
  • Esquemas piramidales en Albania
  • Reed Slatkin
  • Escándalo financiero Saradha
  • Scott W. Rothstein
  • Stanford Financial Group
  • Estafa fe galés Thrasher
En los medios de comunicación
  • Cine y televisión
  • Literatura
Listas
  • Estafadores
  • Trucos de confianza
  • Los sindicatos, las pandillas y empresas criminales
  • Estafas por correo electrónico
  • Impostores
  • Esquemas Ponzi

Otras Páginas

Obtenido de"https://en.copro.org/w/index.php?title=Email_authentication&oldid=650700179"