Esta es una práctica bastante común denominada error web , es la razón principal por la que los clientes de correo no se cargan automáticamente imágenes externas (el segundo es protegerlo de ver imágenes de spam no deseadas que pueden ser inquietantes; por ejemplo, pornografía).
Básicamente, cuando carga un correo electrónico con imágenes externas habilitadas y un enlace a una imagen como <img src='http://192.1.1.1/images/53512_58925.png'>
está en la fuente, su servidor web registrará algo como lo siguiente (el ejemplo a continuación es el registro de acceso predeterminado para nginx
web server ) cuando su navegador / cliente de correo busca y descarga la imagen:
10.1.2.3 - - [10/Oct/2012:10:33:41 -0400] "GET /images/53512_58925.png HTTP/1.1" 200 1933 "http://192.1.1.1/images/53512_58925.png" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.81 Safari/537.1"
que les da:
- su dirección IP de su computadora donde vio el correo electrónico (
10.1.2.3
en este ejemplo),
- la marca de tiempo del acceso por el reloj del servidor
[10/Oct/2012:10:33:41 -0400]
,
- la (primera línea de) la solicitud HTTP GET para obtener la imagen (
GET /images/53512_58925.png
),
- el código de respuesta HTTP (200 significa éxito),
- el tamaño del archivo al que se accede (1933 bytes),
- la URL completa del archivo (192.1.1.1 es la IP del servidor del remitente del correo electrónico), y
- la cadena User-Agent del cliente (que indica qué navegador web y posiblemente el sistema operativo está utilizando).
Para realizar un seguimiento realmente preciso, deberían tener una URL única para la imagen; Por ejemplo, el archivo 53512_58925.png podría significar que el usuario 58925 leyó el correo electrónico con el ID 53512 o algo así. También podrían hacer algo con los parámetros HTTP GET algo como <img src='http://192.1.1.1/images/logo.png?user_id=58925&email_id=53512'>
que también se registraría.
No voy a comentar sobre la legalidad de esto; las leyes varían y algunos países en los que no vivo han promulgado recientemente leyes estrictas de privacidad de TI (por ejemplo, en contra de una política similar de seguimiento de cookies sin el consentimiento explícito del usuario). Además, este foro no está realmente destinado a proporcionar asesoramiento legal.
Esto no tiene nada que ver con la política del mismo origen (utilizada para limitar el poder de los scripts de cliente cargados de forma remota en lenguajes como javascript; por lo tanto, ir a unsafe-web-page.com no debería poder leer / modificar el navegador datos en otras pestañas) o XSS (donde los atacantes explotan fallas para inyectar contenido en páginas web que no son propias).