Índice

Prólogo.......................................................................................................................... 7

1. El Spam en cifras: impacto y criticidad............................................................... 9

1.1. Situación del Spam en el panorama mundial.................................................. 10
1.2. Situación del Spam en España............................................................................... 14
1.3 Impacto económico y social del Spam en las empresas.............................. 18

2. ¿Cómo trabaja un spammer?.................................................................................. 25

2.1. Los spammers. Cómo trabaja un spammer. Preparación y ejecución
del envío de un Spam............................................................................................... 25
2.2. Prácticas de correo electrónico.............................................................................. 32
2.3. Prácticas de los spammers...................................................................................... 50

3. Políticas contra el Spam........................................................................................... 59

3.1. Técnicas de precaución............................................................................................. 59
3.2. Técnicas reactivas..................................................................................................... 60
3.3. Técnicas proactivas ................................................................................................... 62
3.4. Resumen........................................................................................................................ 65

4. Futuras amenazas y soluciones............................................................................. 66

4.1. Amenazas a nivel corporativo y social................................................................ 66
4.2. Amenazas a nivel técnico........................................................................................ 67

5. Proyecto para mitigación del Spam: red de sensores de INTECO.......... 68

5.1. Introducción............................................................................................................... 68
5.2. Objetivos....................................................................................................................... 69
5.3. Funcionamiento del sistema................................................................................. 70
5.4. Resultados estadísticos........................................................................................... 71
5.5. Contenido web.......................................................................................................... 73
5.6. Futuro y evolución.................................................................................................... 76

5
 6. Certificaciones de buenas prácticas en el correo electrónico. RACE...... 77
6.1. Rediris (Red académica de investigación nacional)...................................... 77
6.2. Red Avanzada de Calidad en el correo Electrónico (RACEv2)................... 78
6.3. Criterios técnicos RACEv2...................................................................................... 78
6.4. Sistema de evaluación............................................................................................ 80

7. La ley de Servicios de la Sociedad de la Información y Comercio

Electrónico: regulación del envío de comunicaciones comerciales
electrónicas o Spam................................................................................................. 81

8. Conclusiones.............................................................................................................. 91

6
Prólogo Mi historia con el Spam

Comencé mi “carrera” en Internet hace 14 años de-

sarrollando uno de los primeros ISP del país, Inter-
comGI (actualmente renombrado a Conzentra Da-
tacenter). Proveíamos acceso 28.8Kbps mediante
conexiones dial up al nodo local y posteriormente
por InfoVía, que despertaba odios y pasiones por
igual. Por esas fechas la experiencia de navegación
web no era muy gratificante, tanto por la lentitud
como por la falta de contenidos. Pese a que el pa-
norama ha cambiado, hoy en día hay algo que es
todo lo contrario a un servicio realmente gratifi-
cante y mágico: el correo electrónico.

Parecía un pequeño milagro poder enviar “faxes”

digitales a la otra punta del mundo a tiempo real y
a un coste increíblemente bajo. La gente se asom-
braba cuando un email llegaba a su destino y los
responsables del servicio éramos auténticos hé-
roes. Los agradecidos usuarios no se molestaban
(mucho) si el servicio dejaba de funcionar algunos
minutos (culpa de InfoVía, claro).

Con el tiempo, los usuarios se fueron acostumbran-

do y el “pequeño milagro” se convirtió en algo nor-
mal. Y el agradecimiento se convertía en exigencia.
Los responsables del servicio de correo nos hemos
convertido en algo parecido a un árbitro de fútbol:
si pasamos desapercibidos es porque todo va bien,
pero si se acuerdan de nosotros es mala señal (algo se
ha caído). A diferencia de otros departamentos, nos
puntúan de 0 a 5 sobre 10. Si todo funciona, tenemos
un 5 (un aprobado justo) porque se percibe como
normal, pero si algo falla o parece que falla o deja de
funcionar unos minutos, bajamos rápidamente de 5
a 0, y aparece la paranoia de “hace 10 minutos que no
recibo ningún mail, ¿se ha caído el servidor?”.

Afortunadamente, como buenos profesionales

que somos, podemos mantener servicios de co-
rreo con una alta disponibilidad, sin latencia y
escalables. Todo ello para pasar desapercibidos.

7
 Hasta que a alguien se le ocurrió crear Spam, esos
molestos correos no deseados que roban nuestro
tiempo y el de nuestras organizaciones. Esos co-
rreos basura que crecen respecto al correo limpio
agravando el problema cada vez más.

Las quejas de nuestros usuarios de correo electró-

nico crecían. Intentábamos contener el problema
mediante soluciones que, al no ser del todo efi-
cientes y dar algunos falsos positivos que podían
hacer descartar correo electrónico bueno como si
fuera Spam, suponían más quejas de los usuarios.

Un día, nuestra usuaria más importante (mi madre),

motivada por su desconocimiento, me llamó eno-
jada: “¿Cómo es posible que os dediquéis a enviar
mails con contenidos adultos a vuestros usuarios?”.
Consulté con nuestro administrador de sistemas
sobre soluciones en el mercado y vimos que no
existían muchas. Además, si alguna había, ni nos
las podíamos permitir, ni era del todo eficiente, ya
que según los fabricantes, el Spam era un proble-
ma “imposible” de solucionar. Me dije a mi mismo
“¿no confundirán difícil por imposible”?. “Robé”
un par de ingenieros de otro proyecto y después
de muchas noches sin dormir, nació el embrión
de SPAMINA. Así fue como comenzó todo. Así fue
como nació SPAMINA, un hijo que hoy ya es adulto
y maduro.

Hoy en día, tras muchos años gestionando servi-

dores de correo y tratando cara a cara con el pro-
blema del Spam hemos podido aprender mucho
de él y de aquellos que lo generan. En este libro
recogemos mucho de lo que hemos aprendido
y estamos encantados de poderlo compartir con
vosotros. ¡Espero que os guste!

Dídac Lee
Presidente SPAMINA
8
1. El ‘Spam’ en cifras:
impacto y criticidad
1. INTECO: Estudio sobre la situación, na-
turaleza e impacto económico y social del
correo electrónico no deseado ‘spam’, 2008.
Disponible en http://observatorio.inteco.es
El correo electrónico se ha consolidado como
uno de los pilares fundamentales de la Sociedad
de la Información. Al igual que otros muchos
servicios a través de Internet, su utilización casi
universal ha sido aprovechada como vehículo
masivo de diversas formas de ataques informáti-
cos, a menudo basados en técnicas de ingeniería
social. Dentro del abanico de usos indebidos lla-
ma especialmente la atención el auge que está
adquiriendo el fenómeno de la recepción de co-
rreo no deseado o Spam, con fines generalmente
ilegítimos.
Internacionalmente el volumen de correo elec-
trónico no deseado en la Red ha alcanzado en
los últimos años proporciones preocupantes. Las
cifras concretas de unas y otras fuentes son di-
versas, pero todas coinciden en el espectacular
incremento del Spam en los últimos años.
Desde el Observatorio de la Seguridad de la
Información (http://observatorio.inteco.es) de
INTECO (Instituto Nacional de Tecnologías de la
Comunicación, www.inteco.es), se ha tratado de
arrojar luz sobre este problema contextualizando
y estableciendo la dimensión real del mismo, tan-
to a nivel mundial como en el ámbito español y
cómo éste afecta a nuestras empresas, con la fina-
lidad de que este diagnóstico sirva posteriormen-
te para identificar las posibles vías de solución.
Este capítulo se centra, por tanto, en la cuantifica-
ción del fenómeno del Spam presentando datos
fiables sobre la problemática del correo no de-
seado, cuantificándose la magnitud del fenóme-
no a partir de los datos tanto de fuentes externas
como de fuentes propias, en concreto, los datos
obtenidos de la Red de Sensores de INTECO1.
9
 1.1. Situación del ‘Spam’ Todas las fuentes consultadas coinciden en el in-
en el panorama cremento de estos correos en los últimos años.
mundial Los datos correspondientes al primer semestre
de 2006 señalan que el porcentaje de Spam fue
de un 54%, culminando dicho año con valores del
59%; en los informes mensuales de enero y febre-
ro de 2007, el nivel de Spam ascendió desde un
60% a un 80% aproximadamente2.

Volumen de Spam en mensajes de correo en Internet 2005-2007 (%)

Fuente: MessageLabs

80%

70% 76,1% 76,0% 73,7% 75,5%

73,5% 72,8%
68,3%
60% 66,0%
63,9%
61,7% 59,2% 60,4%
50%

40%

30%

20%

10%

0%

2. Symantec (http://investor.symantec.com)
publica informes sobre el estado del Spam a
nivel mundial a partir de las respuestas pro-
porcionadas por sus productos antispam.
Es el mismo caso de MessageLabs (http://
www.messagelabs.com/)

10
1.1.1. Zonas y países La mayoría del Spam se origina en los Estados
emisores de ‘Spam’ Unidos. Aunque el porcentaje de mensajes de co-
rreo enviados desde Europa con respecto al total
es bastante menor que el de EE.UU., el índice de
Spam es bastante próximo, de lo que se deduce
que el ratio de Spam generado desde Europa so-
bre el total de mensajes enviados alcanza unas
cifras importantes.

Una posible explicación a este hecho es que mu-

chas de las redes de ordenadores zombies (bot-
nets) operan desde países de Europa del Este. En-
tre los años 2005 y 2008, España se ha mantenido
entre la quinta y undécima posición en la lista de
países que más Spam generan. Según los últimos
datos recogidos, el 2,7% del Spam mundial tiene
su origen en España, que se sitúa en la undécima
posición3.

Países generadores de Spam en internet en el año 2007 (%)

Fuente: Sophos

EEUU 22,5%
Corea del Sur 6,5%
China 6,0%
Polonia 4,9%
Rusia 4,7%
Brasil 3,8%
Alemania 3,5%
Francia 3,5%
Turquía 3,1%
Italia 2,7%
España 2,7%
India 2,6%

0% 10% 20% 30%

3. Sophos: http://esp.sophos.com/

11
 Atendiendo algunos informes que recopilan4 esta-
dísticas de diversas fuentes5, se basan en la clasifi-
cación de los propios clientes de correo y obtienen
como principales resultados a nivel mundial:

• El número de mensajes de Spam recibidos a

diario por una persona suscrita a una cuenta
de correo es aproximadamente seis, frente a
una cantidad total aproximada de correos de
diez.

• El volumen diario de correos electrónicos no

deseados asciende 12.400 millones, frente a
un total de 31.000 millones de correos.

• Anualmente, una persona suscrita a una cuen-

ta de correo ordinaria recibe aproximadamen-
te 2.200 mensajes Spam.

• El coste anual de todos los usuarios de In-

ternet que no pertenecen a una empresa es
aproximadamente 255 millones de dólares.

• El 28% de los usuarios responde al correo

Spam.

• Entre el 15% y el 20% de correos legítimos

corporativos es clasificado como correo Spam
(falsos positivos) y por tal motivo se pierde.
Esta pérdida es muy difícil de cuantificar en
términos económicos.

4 . Evett, Don: Spam statistics 2006. TopTen-

Review, http://spam-filter-review.toptenre-
views.com/

5. http://www.jupiterresearch.com/bin/item.
pl/home
http://www.emarketer.com/
http://www.gartner.com/
http://www.mailshell.com/
http://www.harrisinteractive.com/
http://www.ferris.com/

12
1.1.2. Países receptores En países como España, Suecia, Francia o Italia,
de ataques ‘Spam’ que hasta el año 2005 no presentaban cifras signi-
ficativas de Spam, comenzaron a partir de enton-
ces a reportar valores elevados, en torno al 40,1%,
40,9%, 49,8% y 57,4% respectivamente, siendo la
lengua predominante el inglés, que completa en-
tre el 70,0% y el 80,0% del total; sin embargo, se
incrementa el Spam en chino, particularmente el
que tiene como objetivo Hong Kong.

1.1.3. Evolución de la La evolución del Spam está caracterizada por las

tipología de ‘Spam’ nuevas finalidades a la que se orienta. Así, los da-
en el ámbito tos de 2007 revelan un considerable aumento
internacional del fraude online basado en la inversión en ac-
ciones o en las compras de bienes y servicios.
La tipología general del Spam deriva hacia los
grupos de Spam financiero, comercial, salud e
Internet, disminuyendo los porcentajes de Spam
de tipo ocio o de contenido para adultos.

Tipos de Spam en febrero del 2007 (%)

Fuente: Symantec

4% 3%
4%
5% 25%

13%
Financiero
Comercial
Salud
Internet
Ocio
23% 23%
Estafas
Adulto
Fraude de empresas

13
 1.1.4. Escritura y El Spam en formato de correo TEXT sigue siendo
tamaño del ‘Spam’ el formato más utilizado (aproximadamente el
50,0% del total), junto con el Spam HTML, con un
40,0%, en gran medida por la sencillez de su crea-
ción. Otros nuevos formatos de Spam, aquellos
relacionados con el envío de archivos adjuntos en
formato .pdf o .zip, por el momento representan
tan solo un 0,5% del total del volumen de Spam.
Es de esperar que esta tipología crezca en los
próximos años. Esto significa que el peso de los
mensajes no es muy grande. Aproximadamente
un 40% de los mensajes Spam no sobrepasan los
5 KB. Los spammers prefieren enviar mensajes con
menos de 10 KB porque cuanto más corto sea el
texto más rápidamente llega a los usuarios6.

1.1.5. El ‘Spam’ en otros Otro aspecto preocupante del fenómeno del

servicios: móvil y Spam es que ya no está sólo ligado al uso de
voz sobre IP Internet, sino que está traspasando barreras y
tratando de llegar a otros servicios de comuni-
cación como la telefonía móvil (Spam por medio
de los SMS y MMS), la mensajería instantánea
vía Internet o el Spam sobre tecnología de Voz
sobre IP, denominado SPIT (en inglés, Spam over
Internet Telephony). Sin embargo, en la actuali-
dad el volumen de todo este tipo de Spam no
constituye un porcentaje significativo frente al
enviado mediante correo electrónico, por lo que
no se dispone de cifras relativas a estos tipos de
incidencias.

1.2. Situación del ‘Spam’ En el ámbito nacional en relación al correo elec-

en España trónico no deseado en España, la base de los
datos procede de la red de sensores de Spam de
INTECO. Esta se compone de 14 sensores distri-
buidos geográficamente, y situados en servidores
de correo de pymes y usuarios. En ellos se pro-
cede a la monitorización de los correos que por
ellos circulan, donde son analizados y clasificados
en detalle, a través de 13 herramientas antispam
6. MessageLabs: www.messagelabs.com distintas.
14
1.2.1. Panorama general Los datos primarios tratados estadísticamente y
del ‘Spam’ en España analizados por el Observatorio de la Seguridad
de la Información relativos a España provienen
de la red de sensores de INTECO. Este análisis
supone una de las primeras iniciativas naciona-
les en cuanto al estudio estadístico sobre datos
del volumen de correo electrónico no deseado.
La información es proporcionada por diversos
sensores situados en servidores de correos de
pymes y usuarios. Para el análisis de referencia se
han tomado los datos correspondiente al período
comprendido entre el 1 de enero al 11 de marzo
de 2008, un total de 10 semanas.

Spam en España (%, del 1 de enero al 11 de marzo de 2008)

Fuente: INTECO
15,4%

84,6%

Spam Correo legítimo

Como se observa, de los más de 91 millones de

correos procesados en la muestra por los senso-
res, 77,4 millones fueron considerados Spam, lo
que corresponde al 84,6% del total de mensajes.
Y del total de mensajes detectados como Spam
en la muestra de los sensores (77 millones), fue-
ron rechazados casi 52 millones, un 67,1%, y nun-
ca llegaron al usuario. El resto, otros 25 millones
aproximadamente (32,9%), se consideran Spam y,
sin embargo, terminan en el buzón de correo elec-

15
 trónico del usuario. Esto se debe a que, según las
políticas de filtrado que los administradores impo-
nen, se puede filtrar todo el Spam o sólo una par-
te en función de unos parámetros seleccionados
previamente. En cualquier caso, es posible que no
se desee filtrar el correo entrante para que no se
pierda ningún mensaje legítimo y se produzca un
caso de falso positivo.

Porcentaje del Spam rechazado y no rechazado sobre el total del Spam

(%, del 1 de enero al 11 de marzo de 2008)
Fuente: INTECO

67,1%
32,9%

Spam rechazado Spam no rechazado

1.2.2. Países emisores de En el gráfico se aprecia claramente que el origen

‘Spam’ dirigido a del Spam destinado a España se encuentra ma-
España yoritariamente en Estados Unidos, China, Corea
del Sur y Rusia. Entre estos cuatro países envían
a España más del 50,0% del total de mensajes no
deseados en circulación. A diferencia de la situa-
ción internacional, en el caso del Spam recibido
en España, Rusia ocupa un lugar destacado.
16
Los diez países con mayor volumen de Spam enviado hacia España
(%, del 1 de enero al 11 de marzo de 2008)
Fuente: INTECO

5%
6%
21%
7%

EEUU
7%
Rep. Pop. China
Corea del Sur
Rusia 8%
Argentina 14%

España
Turquía 8%
Colombia
12%
Chile
12%
Francia

Un aspecto interesante es que existe Spam origi-

nado precisamente en España (8,0%), así como
mensajes no deseados procedentes de países de
habla hispana como Argentina o Colombia. Estos
resultados tienen su razón de ser en el progresi-
vo aumento de las máquinas comprometidas en
estos países a través de redes botnets y en las es-
trategias de los spammers de enfocar sus ataques
a nuevos usuarios sin mucho conocimiento sobre
el fenómeno. En este sentido, los países cuya re-
lación entre el volumen de Spam que envían ha-
cia España es mayor respecto al volumen total
de correos son Corea del Sur (96,6%), Colombia
(95,7%) y Chile (94,7%).

17
 1.3. Impacto económico
y social del ‘Spam’
en las empresas
7. Un análisis pormenorizado de los efectos
e incidencias del malware en los hogares
españoles se puede encontrar en el Estudio
sobre la Seguridad de la Información y e-
Confianza de los hogares españoles, INTE-
CO, 2008. Disponible en http://observatorio.
inteco.es.
18
Como en la mayoría de las evaluaciones de impacto
de otros fenómenos, como por ejemplo el malware7,
los análisis sobre las consecuencias del Spam en las
organizaciones se realizan sobre los efectos deriva-
dos del mismo. En muchas ocasiones, es más común
que estos efectos sean tratados en términos pura-
mente cualitativos y no necesariamente económicos,
como pérdidas en tiempo, desconfianza en el servi-
cio, consumos de ancho de banda y de capacidad
de almacenamiento, necesidad de un tiempo de
recuperación y reestablecimiento del servicio, etcé-
tera. No obstante, en el próximo epígrafe se tratará
de aportar algunas cifras que pueden ser indicativas
del impacto económico y que permitirán extraer
ciertas conclusiones.
En referencia al impacto económico, conviene
destacar la ausencia de información fidedigna
o de estudios detallados que permitan arrojar
cifras fiables. El cálculo preciso de las pérdidas
generadas por el correo no deseado no es sen-
cillo, ya que existen numerosas variables impli-
cadas en el fenómeno del Spam que generan un
marco de complejo análisis.
Entre ellas se pueden encontrar los rápidos avances
que se producen en la seguridad de la información,
como las mejoras en los filtros antispam de los ser-
vidores de correo que no permiten un seguimiento
homogéneo, o el hecho de que no todas las empre-
sas tienen dichos filtros instalados en sus servidores.
Se complica también por las diferentes cifras que se
manejan sobre volumen de Spam en circulación o
sobre la cantidad de Spam que llega al buzón final
de usuario.
A todo esto se añade que el coste económico para
la empresa por el tiempo perdido y coste de opor-
tunidad para cada uno de sus trabajadores no es el
mismo, sino que varía en función del salario, pro-
ductividad, dependencia jerárquica, etc. que lleva a
la necesidad de realizar nuevas estimaciones sobre
dicha cifra.
Y finalmente, se ha de definir el número de traba-
jadores afectados, esto es, aquellos que no sólo
utilizan el ordenador en su puesto de trabajo, sino
que además hacen uso frecuente del correo elec-
trónico como herramienta de trabajo. Todo ello
determina que, en los cálculos sobre impacto
económico, se hable siempre de estimaciones
basadas en predicciones estadísticas.

Por otro lado, hay que señalar que, aunque no es

posible presentar datos de impacto económico
para cada uno de los distintos agentes implicados
en el proceso del correo (operadores de teleco-
municaciones, proveedores de servicios de Inter-
net, Administración, usuarios corporativos), sí ha
sido posible realizar una estimación económica
de impacto para el conjunto de empresas.

En general, para cualquier empresa u organiza-

ción deben analizarse:

1. Las pérdidas relacionadas con la productivi-

dad:

• El tiempo perdido por los empleados en la

revisión y eliminación de sus correos, frente a
la presencia del Spam en sus buzones, menos
el tiempo de uso del mismo en condiciones
normales de trabajo, es decir, el tiempo real-
mente productivo.

• Pérdidas relacionadas con la recuperación

frente al Spam: las relacionadas con la recu-
peración de los falsos positivos, a partir del
análisis que considera el coste de los recursos
técnicos y humanos asumidos por las organi-
zaciones para brindar opciones de recupera-
ción de los correos perdidos o considerados
Spam, en ocasiones vitales para la actividad
de la organización.

2. La gestión de infraestructuras: coste relacio-

nado con la fiabilidad del servicio de autogestión
del correo electrónico.
19
 La mayoría de los estudios concluyen de forma
genérica que el grueso del impacto económico
del Spam está relacionado con:

• Las pérdidas de tiempo de proceso y huma-

no.

• La inversión en nuevas infraestructuras tec-

nológicas que suponen un mayor ancho de
banda y el incremento de las capacidades de
almacenamiento y de realización de copias
de seguridad para dar soporte a esta avalan-
cha de correos.

• La inversión en técnicos cualificados.

• La inversión en herramientas antispam y sus

actualizaciones.

• En menor medida, las pérdidas económicas

como consecuencia de la pérdida de infor-
mación relevante para la actividad; en oca-
siones, se trata de una pérdida de información
temporal.

1.3.1. Impacto económico El análisis económico se fundamenta principal-

del ‘Spam’ en las em- mente en las pérdidas económicas reales que ge-
presas españolas nera el Spam en términos de productividad del
empleado. Aunque también en este apartado re-
sulta difícil su estimación. En este sentido, se valo-
ran aspectos como el número de trabajadores con
ordenador, cuánto tiempo lo utilizan, la estimación
del tiempo utilizado para borrar correos no desea-
dos o cuánto Spam logra traspasar todos los filtros
y llegar al usuario final.

Sin embargo se pueden establecer algunas esti-

maciones al respecto, calculando el tiempo que
éste invierte diariamente en discriminar, de entre
todos los correos recibidos, aquellos legítimos. Las
pérdidas de productividad para aquellos emplea-
dos que utilizan habitualmente el correo electró-
20

Pérdidas de productividad por cada empleado que usa el correo electrónico
nCORREO
dT * ( ∑t , *cEii ,h )
E
i i d , spam
i =1
8. Dabendofer, Thomas P.: Impact Analysis
of Spam, Swiss Federal Institute of Techno-
logy, Zurich, 2005
9. INE: Encuesta Anual de Coste Laboral, año 2006
(publicadael5deseptiembrede2007).http://www.
ine.es/jaxi menu.do?type=pcaxis&path=%2Ft22/
p132&file=inebase&L=0
10. Estimación sobre el dato del coste la-
boral bruto del 4º trimestre del 2007 de la
Encuesta Trimestral de Coste Laboral, INE
(datos publicados el 14 de marzo de 2008).
nico pueden calcularse aplicando el siguiente lo-
garitmo8:
Ei – Representa a un empleado.
dT – Días de trabajo, por año, de un empleado Ei
nCORREO – Números de empleados que usan el
correo.
tEi,d,spam – Tiempo promedio, en horas y por
días, que el empleado Ei invierte en gestionar el
spam de su buzón.
cEi,h – Promedio del coste horario del empleado Ei
Las estimaciones del Observatorio de INTECO
realizadas a partir de diferentes fuentes nacio-
nales e internacionales apuntan a que el tiempo
medio diario que un trabajador español necesi-
ta para eliminar el Spam de su buzón de correo
oscila entre dos y cuatro minutos. Esto repre-
senta una media del 0,63% de la jornada laboral.
Aunque no se encuentran publicados los costes y
posibles pérdidas económicas se pueden realizar
las siguientes estimaciones: si se tiene en cuenta
que el coste laboral por empleado en términos
netos fue de 26.360 euros en el año 20069, el re-
sultado es que las pérdidas por productividad
de los empleados en las empresas como con-
secuencia del Spam se puede situar en 165€ al
año por trabajador que utiliza habitualmente el
correo electrónico en su puesto de trabajo. Si se
considera esta cifra para el año 2007, las pérdi-
das representan 179€ al año por trabajador 10.
El coste medio para una empresa con 1.000
cuentas de correo electrónico que externaliza
todo su servicio se sitúa aproximadamente en
0,045 - 0,064€ /cuenta/día, es decir, entre 9.900
y 14.000 euros al año. Por esta inversión, el ser-
vicio podría incluir prestaciones como el filtrado
de virus y Spam, el almacenamiento seguro de
21
 150GB con sistema de respaldo, el soporte de
ocho nombres de dominio o la optimización y
monitorización del tráfico de correo. Sin embar-
go, las nuevas inversiones persiguen el objetivo
de lograr fiabilidad en el servicio de correo.

Un hecho en los agentes estudiados que mere-

ce la pena destacar es el problema que el Spam
provoca en el almacenamiento y copias de se-
guridad (backup) de los correos de los usuarios.
Según los expertos, los buzones de correo de es-
tos usuarios alcanzan fácilmente el máximo de su
capacidad, sobre todo con la inclusión de Spam
en ficheros de tipo .pdf, imágenes o contenidos
multimedia. Para un usuario que desee almace-
nar 100 MB de correos legítimos, será necesario
dimensionar su buzón con un tamaño entre 0,7
y 1 GB; un servidor que sirva a 6.000 usuarios re-
querirá 6 TB.

Los falsos positivos tienen asociados importantes

perjuicios para las organizaciones, pues dan lugar
a la eliminación de correos electrónicos legítimos
cuyo contenido puede ser trascendente para los
usuarios o las organizaciones. En este sentido, al-
guno de los agentes entrevistados cifra entre una
hora y una hora y media, el tiempo de recupe-
ración de un solo mensaje que ha sido errónea-
mente clasificado como Spam. A esto se añade
que las pérdidas monetarias que puede ocasio-
nar la no recepción de esos correos no pueden
ser estimadas con precisión.

Existen también otros factores con clara influen-

cia en la economía, pero cuyos valores reales son
de difícil estimación. En este sentido, es conocido
que el Spam:

• Afecta a los recursos de los servidores, ya

que procesar Spam hace lento el tratamien-
to y proceso del correo normal.

• Constituye una herramienta de propaga-

ción de malware y ataques de phishing.
22
 • Puede llegar menoscabar la reputación de
las empresas y, en consecuencia, afectar a
sus clientes, sus ventas y sus ganancias.

1.3.2. Impacto social El Spam se ha convertido en un problema de se-

guridad para todos los trabajadores que hacen
uso de las redes de comunicación y sus servicios.
Muchos de ellos, poco relacionados con las Tecno-
logías de la Información y la Comunicación, pue-
den no reconocer los problemas tecnológicos aso-
ciados al Spam, ni incluso su nombre técnico, pero
tras una breve descripción afirman no sólo cono-
cerlo sino padecerlo. Se puede considerar que el
Spam constituye uno de los problemas de seguri-
dad informática más extendidos en la actualidad,
pues el correo electrónico es uno de los servicios
de Internet más usados por las empresas.

Incidencias de seguridad más recientes detectadas por los usuarios (según

momento en que se ha producido) (% acumulados)11
Fuente: INTECO

Última Último Últimos Último En alguna

Incidencia Nunca
Semana Mes 3 meses Año ocasión
Recepción de correos
no solicitados/ 61,0 72,9 77,8 82,8 86,6 13,4
deseados (spam)
Códigos maliciosos
9,1 22,3 35,5 55,1 81,0 19,0
(malware)
Intrusiones remotas
6,2 13,2 19,5 29,8 42,1 57,9
en su ordenador
Intrusiones en su
5,7 11,1 15,7 21,5 30,1 69,9
correo electrónico
Obtención fraudulenta
4,7 8,0 12,5 16,0 21,1 78,9
de sus datos personales
Robo de ancho de
3,5 7,0 10,4 14,5 19,4 80,6
banda WI-FI

11. INTECO: Estudio sobre la Seguridad de la

Información y e-Confianza de los hogares
españoles (informe final 2007), 2008. Dispo-
nible en http://observatorio.inteco.es

23
 Una de las conclusiones más interesantes que se-
ñalan los estudios realizados por el Observatorio
de INTECO12 es la pérdida de confianza de los
trabajadores en el filtro antispam de la organi-
zación en la que trabajan y, por tanto, en su ser-
vicio de correo electrónico, debido a la posibili-
dad de que la aplicación pueda provocar, como
efecto colateral, la aparición de falsos positivos.

En este punto, es interesante distinguir el entorno

en el que se utiliza; lógicamente, el grado de des-
confianza del usuario es mayor en el entorno la-
boral que en el doméstico, dada la importancia
asociada al contenido de los mensajes en cada
caso. Si bien, en ninguna de las dos situaciones
resulta fácil renunciar al uso del correo, por ra-
zones profesionales en el primer caso y por ne-
cesidades sociales u ocio en el segundo.

12. INTECO: Estudio sobre la situación, na-

turaleza e impacto económico y social del
correo electrónico no deseado ‘Spam’, 2008.
Disponible en http://observatorio.inteco.es

24
2. ¿Cómo trabaja un spammer?

2.1. Los spammers

2.1.1. Motivación de los Se dice que el primer Spam lo mandó en 1978 un

spammers. comercial de DEC llamado Gary Thuerk, a todas
El negocio del las direcciones de correo de ARPANET de la costa
‘Spam’ Oeste de EEUU, anunciando una nueva máqui-
na de DEC. El comercial entró a mano todas las
direcciones y el correo llegó a la mayoría de los
usuarios creando un debate sobre la idoneidad
del uso del correo para este tipo de mensajes.

Los responsables de ARPANET avisaron al comer-

cial que había hecho un uso incorrecto de la red y
se mandó una nota recordando las reglas de uso
de la misma.

Como vemos, la idea inicial del spammer era ni

más ni menos que publicitar algún articulo para
obtener beneficios económicos.

¿Por qué sigue existiendo el Spam después de 30

años de quejas continuas de los usuarios?.

Aunque parezca mentira la respuesta es bastante

simple:

1. La gente compra los productos anunciados

(aunque nos parezca increíble).

2. Mandar Spam es extremadamente barato.

3. El Spam, aunque ilegal en algunos países, es

difícilmente rastreable.

4. Los beneficios económicos obtenidos son

enormes.

25
 Hoy en día el objetivo principal, y prácticamente
único, de los spammers sigue siendo el económi-
co, aunque han diversificado las posibles fuentes
de ingresos relacionadas con el negocio. Separe-
mos los beneficios económicos del Spam en dos
grandes grupos: los spammers y las empresas que
alquilan a los spammers.

Spammers:

• Venden sus servicios de “marketing” a otras

empresas. Aquellos que mandan Spam no
son necesariamente los que venden viagra o
Rolex sino que son simplemente quienes ha-
cen llegar el mensaje al potencial cliente.

• Phishing. Robar usuarios y claves de cuentas

bancarias es uno de los “negocios” más lucra-
tivos relacionados con el mundo del Spam.

• Venden información (listas de emails). Los

spammers están relacionados y cooperan en-
tre si. La venta de listas de emails, supuesta-
mente válidos, está a la orden del día.

• Venden o alquilan botnets, no sólo para ge-

nerar más Spam, también para realizar ata-
ques de DDOS. Recordemos que el Spam es
la puerta de entrada que permite al spammer
tomar control sobre el ordenador. Una vez
que tienen capacidad de procesamiento, la
venden o la usan para sus intereses.

Empresas que se aprovechan del Spam:

• Venden productos anunciados a través del

Spam (especialmente productos farmacéu-
ticos).

• Estafan mediante técnicas de phishing, o sen-

cillamente usando cualquier otro truco, sien-
do muy típicos el Nigerian Scam o la subida
artificial de empresas en la bolsa. Alquilan a

26
 los spammers para sus fines sin ser ellos mis-
mos los que mandan el Spam.

La siguiente tabla se obtiene de los datos sema-

nales de un exspammer. Estos datos son de hace
ya unos años, pero nos pueden servir como orien-
tación.

De ella podemos extraer algunos datos curiosos

como el porcentaje de personas que siguen el
link de los Spam (0.12%) o el porcentaje de comi-
sión sobre cada venta (50%). Está claro que lo más
importante al final es el beneficio limpio semanal
que según esta tabla es de más de 7.500 USD.

2.1.2. Intercambio de Todo negocio necesita de una materia prima, ya

bases de datos de sea un producto o información. El Spam no es una
direcciones de excepción, y su materia prima son las direcciones
correo de correo, sin las cuales deja de tener sentido.

La cuestión es, ¿donde consiguen esas direccio-

nes? ¿cómo es posible que sepan mi dirección si
yo no se la doy?.

Las direcciones de correo son para los spammers

como la gasolina para los coches, e igual que ha-
cemos lo imposible para encontrar petróleo, los
27
 spammers hacen lo mismo para encontrar direc-
ciones válidas. Algunas de las técnicas que usan
son las siguientes:

1. Listas de correo. Sencillamente miran quien

está apuntado en las listas de correo y los
añaden a sus BBDD.

2. Compra de BBDD a particulares o empresas

(se ha hecho toda la vida para encontrar todo
tipo de información).

3. Bots que buscan direcciones en Internet. Bá-

sicamente hacen un “peinado” de las páginas
web y recogen las direcciones que encuen-
tran tanto en webs públicas como en chats o
newsgroups.

4. Directory Harvest Attack (DHA). Esta técnica

consiste en hacer uso de la fuerza bruta para
encontrar direcciones existentes. Se esco-
ge un dominio y se crean aleatoriamente, o
usando un diccionario, direcciones de correo.
Seguidamente se manda un email a esas di-
recciones y las que sean aceptadas por el ser-
vidor destino se considerarán como válidas.

Cómo trabaja un Spammer. Preparación y eje-

cución del envío de Spam.

El spammer, aunque ilegalmente, no deja de ha-

cer un trabajo con la intención de obtener bene-
ficios del mismo y como todo trabajo sigue unas
reglas más o menos estándar.

1. Recolección de direcciones de correo. Como

hemos comentado anteriormente, la base
del Spam son las direcciones de correo váli-
das, así que el primer paso es obtener dichas
direcciones.

2. Creación del contenido del Spam. Un spam-

mer no es otra cosa que un especialista en mar-

28
 keting que utiliza Internet para propagar su
mensaje y como tal intenta:

• Llamar la atención del lector. Como todo

buen anuncio tiene unos pocos segundos
para conseguir que el lector se interese por
la información, sino será inmediatamente eli-
minado.

• Parecer verídico. El fenómeno del Spam ha

pasado a ser tan conocido que ya no es su-
ficiente con conseguir que el correo llegue
al buzón del destinatario. Todos somos cons-
cientes de que existe Spam y por lo tanto tie-
nen que esmerarse mucho en conseguir que
el correo parezca lo más verídico posible, es-
pecialmente si se trata de phishing.

• Beneficio claro para el destinatario. La misión

del Spam no es llegar a ser leído sino conse-
guir que el receptor haga una acción concre-
ta, ya sea visitar una web o comprar un pro-
ducto. Para ello el mensaje tiene que ofrecer
un beneficio claro y específico, siendo algu-
nos de los más típicos la posibilidad ganar
dinero de manera fácil y rápida o conseguir
un cuerpo ideal sin esfuerzo alguno.

3. Envío masivo a través de botnets. Una vez se

tiene la “campaña publicitaria” preparada se
necesita hacerla llegar a los potenciales clien-
tes. Esto se consigue normalmente mediante
botnets, de manera que se puede llegar a mi-
llones de usuarios manteniendo el anonima-
to y con coste casi nulo.

4. Estudio de los resultados, incluyendo ROI y

preparación del siguiente envío. Los spam-
mers están cada vez más profesionalizados y
sus métodos así lo demuestran. Una vez han
lanzado la campaña realizan un análisis sobre
los efectos de la misma para poder decidir los
cambios a efectuar en la siguiente. Para ello
tienen en cuenta parámetros como:
29
 • Comprobar la existencia de las cuentas y
eliminar las inválidas.

• Comprobar estadísticas. Los programas que

manejan botnets incluyen módulos de esta-
dísticas que les permiten ver el alcance de las
campañas.

• Efectuar mejoras en el mensaje. Según las

estadísticas ven la penetración de los men-
sajes y deciden si seguir en la misma línea o
cambiar de dirección para intentar conseguir
mejores resultados.

2.1.3. Spam 2.0 Didac Lee, un conocido emprendedor en el área

tecnológica, acostumbra a decir una frase que no
por obvia deja de ser extremadamente importan-
te; “Para que el mensaje llegue a una persona se
tiene que transmitir de manera que sea interesan-
te para el receptor, no para el emisor”. Trasladado
al mundo del Spam, significa que el mensaje del
correo tiene que adaptarse al receptor y eso in-
cluye tanto el mensaje como el medio para llegar
a éste.

El Spam 2.0 no es otra cosa que los nuevos mode-

los utilizados por los spammers para hacer llegar
el Spam a los potenciales clientes. Estos métodos
van desde el uso de webs sociales tipo Facebook
o Myspace, a los que se llega mediante links des-
de un correo, hasta el uso masivo de botnets para
mandar el Spam.

Nos centraremos en el funcionamiento de los bot-

nets y haremos un resumen de cómo los utilizan:

1. Recordemos que el Spam se basa en inge-

niería social y que el correo es únicamente
el señuelo. El primer paso para convertir un
ordenador en parte de un botnet es mandar-
le un Spam con una URL de una web infecta-
da y un mensaje suficientemente sugerente

30
 como para que el destinatario tenga curiosi-
dad para seguir el link (p. ej.: ¿eres tú el de la
foto?).

2. A este tipo de técnica se le llama Two-stage

Attack (ataque en dos tiempos) ya que pri-
mero llega el Spam y después el usuario tiene
que conectarse a la web. Estas webs pueden
infectar la máquina sin necesidad de que se
acepte ninguna descarga desde el ordenador
si éste no cuenta con todos los parches de se-
guridad instalados.

3. Una vez en la red, empiezan las comunica-

ciones “peer to peer” con otros infectados
(en versiones anteriores la comunicación era
centralizada y normalmente usaban IRC con
lo que los firewalls podían cerrar la comuni-
cación mucho más fácilmente).

4. La máquina infectada manda mensajes para

unirse a alguna de las redes ya funcionando.
Dependiendo de los recursos que tenga la
máquina se le asignará una tarea u otra, des-
de mandar Spam a infectar otras máquinas.

5. Usan la técnica fast-flux que consiste en cam-

biar la IP de un dominio en el DNS cada poco
tiempo para que sea más difícil bloquear la
web anunciada en el mensaje.

6. Si se sienten amenazados pueden crear ata-

ques DDoS.

Una vez el ordenador está infectado, éste puede

usarse para mandar Spam, alojar webs infectadas
o reclutar otras máquinas. La tarea dependerá
tanto de la capacidad de la máquina como de las
necesidades del botnet al que pertenezca.

Una de las técnicas que usan los bots para inten-

tar evitar ser detectados es el del cambio aleatorio
de tareas, ya que hace que sea mucho más difícil
la detección al no tener un comportamiento fijo.
31
 2.2. Prácticas de El correo electrónico, al igual que la mayoría de
correo electrónico los servicios y protocolos que se implementan so-
bre Internet, se rigen a través de estándares.

2.2.1. Los estándares Los estándares son documentos formales emi-

tidos por las organizaciones de estandarización,
generados por individuos u organizaciones y cui-
dadosamente revisados por pares para alcanzar
una forma óptima y convenida de solucionar pro-
blemas, contribuyendo de esta manera a la inte-
roperabilidad y a la universalidad.

Los estándares que conciernen directamente

a la operación de Internet, incluyendo el correo
electrónico, están gobernados por Internet Engi-
neering Task Force (IETF), que recibe, revisa y man-
tiene un conjunto de documentos denominados
Request For Comments (RFC). Se revisarán a conti-
nuación las RFC principales que gobiernan el co-
rreo electrónico.

Figura 1: Cuerpo
de estándares del MIME
correo electrónico. R FC s 2 0 4 5 /2 0 4 9

For m a to
R FC 2 8 2 2

Pr otoc olo S MT P
R FC 2 8 2 1

La figura 1 muestra el cuerpo de estándares prin-

cipales y la forma en que los mismos se relacio-
nan entre sí.
32
2.2.2. El protocolo SMTP La RFC 2821 define el denominado Simple Mail
Transfer Protocol (SMTP) utilizado para la transmi-
sión de correo electrónico desde un servidor de
origen a un servidor de destino, pasando opcio-
nalmente por uno o más servidores intermedios,
conocidos como Relays de correo.

El objetivo de diseño más importante del proto-

colo SMTP es el de transferir correo de forma sim-
ple, segura y eficiente, y sus características funda-
mentales las siguientes:

• Independencia del protocolo de transporte uti-

lizado, que debe ser orientado a la conexión y
confiable (en Internet se usa TCP).

• Bidireccional y transaccional. Cada transacción

iniciada por el cliente recibe una respuesta nu-
mérica que codifica el resultado del procesa-
miento de esa transacción.

• Toda la comunicación se hace en codificación

ASCII13, en líneas de tamaño limitado14 separa-
das por una configuración única y estandariza-
da de caracteres de control (CR-LF).

• El protocolo es extensible, existiendo un meca-

nismo mediante el cual, cliente y servidor pue-
den negociar las extensiones que utilizarán.

• La información contenida en el correo electró-

nico se divide en Sobre y Contenido. A su vez, el
Contenido se divide en Encabezados y Cuerpo.

13. Actualmente existen extensiones acep-

tadas al protocolo que permiten la transmi-
sión de codificaciones no ASCII.
14. Las líneas no deben superar los 1000
bytes, incluyendo los dos bytes del salto de
línea.

33
 2.2.2.1. Codificaciones Las codificaciones numéricas con las que el ser-
numéricas de vidor reporta el resultado de cada transacción al
resultados cliente se dividen en 4 familias, que se distinguen
por el tercer dígito de la codificación:

• Las codificaciones de la familia 2XX indican

aceptación o éxito de la transacción.

• Las codificaciones de la familia 3XX indican

éxito parcial, a la espera de más datos.

• Las codificaciones de la familia 4XX indican

error temporal, indicando al cliente que in-
tente nuevamente más tarde.

• Las codificaciones de la familia 5XX indican

error permanente, indicando al cliente que
no debe volver a intentarlo. Cuando un clien-
te recibe este tipo de respuesta normalmente
debe generar una notificación de envío falli-
do (DSN) de regreso al remitente y descartar
el mensaje y/o dirección de destinatario.

2.2.2.2. Las transacciones La siguiente lista describe las transacciones que

SMTP proceden en el uso básico del protocolo SMTP:

• Cuando el cliente inicia una conexión con el

servidor se produce el Inicio de sesión, en la
cual el servidor acepta la conexión y presenta
una identificación al cliente.

• El cliente debe entonces identificarse utili-

zando el comando HELO o EHLO procedien-
do al Inicio del cliente. El servidor debe emitir
la codificación de respuesta a la transacción
y (en el caso del EHLO) la lista de extensiones
soportadas.

• El cliente inicia una o más transacciones de

correo que se dividen en tres etapas:

1. En la especificación de remitente, con el coman-

34
 do MAIL FROM, el cliente inicia una transacción
de correo indicando el remitente de Sobre del
mensaje. El servidor debe responder por el re-
mitente.

2. En una o más especificaciones de destinatario,

con el comando RCPT TO el cliente indica uno
o más destinatarios para el mensaje. El servidor
debe responder por cada destinatario por se-
parado.

3. En la transmisión de contenido, con el coman-

do DATA, el cliente transferirá el contenido del
mensaje. El servidor debe aceptar parcialmente
(o rechazar) el comando DATA. De ser acepta-
do, el cliente debe transmitir los encabezados
del mensaje, seguidos de una línea vacía y por
último el cuerpo del mensaje. La finalización de
los datos se identifica con una línea que con-
tiene solamente un punto. El servidor debe res-
ponder por el bloque completo de datos.

• La finalización la anuncia el cliente con el co-

mando QUIT, a lo que el servidor responderá
con una respuesta de aceptación (2XX) y cerra-
rá la conexión.

La figura 2 muestra una sesión de SMTP típica con

sus componentes discriminados.
I n ic io d e
S e s ió n
Figura 2: Sesión S: 2 2 0 s e gr e . s pa mi na . c om S pa mi na S e r v i c i os
de SMTP típica C: E HL O c l i e nt e . domi ni o. c om
S: 2 5 0 - s e gr e . s pa mi na . c om He l l o hos t . domi ni o. c om [ 1 . 2 . 3 . 4 ]
S: 2 5 0 - PI PE L I NI NG
S: 2 5 0 - AUT H DI GE S T - MD5 PL AI N L OGI N
S: 2 5 0 - S T ART T L S
S: 2 5 0 HE L P I n ic io d e c lie n t e
C: MAI L F ROM: <us ua r i o@undomi ni o. c om>
S: 2 5 0 OK R e m it e n t e
C: RCPT T O: <pr ue ba @s pa mi na . c om>
D e s t in a t a r io a c e p t a d o
S: 2 5 0 Ac c e pt e d
C: RCPT T O: <i nv a l i do@ot r odomi ni o. c om>
S: 5 5 0 r e l a y not pe r mi t t e d D e s t in a t a r io r e c h a z a d o
C: DAT A
S: 3 5 4 E nt e r me s s a ge , e ndi ng wi t h " . " on a l i ne by i t s e l f
C: F r om: us ua r i o@undomi ni o. c om
C: T o: pr ue ba @s a mi na . c om I n ic io d e
C: Cc : i nv a l i do@ot r odomi ni o. c om t r a n s m is ió n
C: S ubj e c t : Me ns a j e de pr ue ba d e m e n s a je
C:
C: E s t e e s un c or r e o de pr ue ba ba s i c o, e s c r i t o e n AS CI I
C: y s i n f or ma t o e s pe c i a l .
C: . T r a n s m is ió n d e m e n s a je
S: 2 5 0 OK i d=1 KYA6 c - 0 0 0 7 a S - 0 a ( e nc a be z a dos y c ue rpo)
C: QUI T
F in a liz a c ió n
S: 2 2 1 s e gr e . s pa mi na . c om c l os i ng c onne c t i on

35
 2.2.2.3. Extensiones El protocolo SMTP acepta extensiones, cuyo uso
a SMTP debe ser negociado entre cliente y servidor.

El servidor las anuncia tras el comando EHLO, y el

cliente puede optar solamente a las anunciadas.
Tienen como propósito mejorar las capacidades
del protocolo sin perder interoperabilidad. Entre
las extensiones comúnmente aceptadas pueden
mencionarse:

• 8BITMIME (RFC 1652): permite la transmisión

de caracteres no ASCII en el contenido.

• AUTH (RFC 2554): permite identificar y auten-

ticar a los clientes utilizando diferentes meca-
nismos estandarizados (LOGIN, DIGEST MD5,
etc.).

• HELP (RFC 821): habilita el comando HELP,

para obtener ayuda legible por seres huma-
nos sobre los comandos SMTP.

• PIPELINING (RFC 2920): permite enviar los

comandos en forma continua, sin tener que
esperar por la respuesta de cada uno. Mejo-
ra un poco la velocidad de transmisión, pero
también facilita el trabajo de los spammers.

• SIZE (RFC 1870): permite al servidor anunciar

al cliente el tamaño máximo de mensaje acep-
tado, y permite al cliente anunciarle el tamaño
del mensaje antes de transmitirlo.

• STATTLS (RFC 3207): permite iniciar sesión TLS

(Transport Layer Security) a fin de cifrar toda la
comunicación entre cliente y servidor.

36
2.2.3. El formato del La RFC 2822 posiblemente sea la referencia más im-
correo electrónico portante para las buenas prácticas de correo elec-
trónico. Define con un alto nivel de detalle técnico
las condiciones que debe cumplir un mensaje bien
formado, a fin de garantizar la interoperabilidad
entre diferentes servidores y clientes de correo elec-
trónico. Los siguientes puntos están cubiertos por el
estándar:

• Se define la sintaxis de los mensajes de texto

exclusivamente.

• Se construye sobre los puntos definidos por la

RFC 2821 descripta más arriba.

• Define distintos tipos de encabezado y su sin-

taxis.

• Define el formato de las direcciones de correo

electrónico, y varias convenciones utilizadas
para especificarlas.

• Define un conjunto de encabezados estándar,

su propósito y su uso.

• Menciona formas obsoletas de los puntos an-

teriores, que aunque estén desaconsejadas,
deben implementarse para mantener la com-
patibilidad.

2.2.3.1. Consideraciones Un mensaje de correo electrónico es una sucesión

generales de caracteres ASCII dividido en líneas por dos ca-
racteres separadores (CRLF) como se define en la
RFC 2821. Las líneas nunca deben superar los 998
caracteres de largo, y deberían ajustarse a 78 ca-
racteres.

La primera parte del mensaje corresponde a los

encabezados, y la segunda parte al cuerpo del
mismo. La primera línea vacía del mensaje actúa
como separador entre encabezados y cuerpos,
siendo este último opcional.
37
 El estándar describe la sintaxis de los encabeza-
dos, pero no pone ninguna condición sobre la
estructura del cuerpo del mismo, además de las
mencionadas en este punto.

2.2.3.2. Los encabezados Los encabezados se forman con un identificador y

un cuerpo, separados por dos puntos (:). El identifi-
cador comienza en el principio de una línea de en-
cabezado, y está conformado por una sucesión de
caracteres ASCII entre el 33 y el 126, sin contar los dos
puntos (:). El cuerpo está conformado por una suce-
sión de caracteres ASCII, y termina donde comienza
el siguiente encabezado, o donde aparece una línea
vacía. Para que un encabezado pueda ocupar más de
una línea, las líneas subsiguientes a la primera deben
comenzar con espacios en blanco.

Para los encabezados estructurados el estándar

define tanto el identificador como la sintaxis que
debe tener el cuerpo. Para los encabezados no es-
tructurados, el estándar solamente define el nom-
bre, dejando el cuerpo definido como texto libre.

2.2.3.3. Encabezados Algunos encabezados están directamente defini-

definidos dos por el estándar, de manera que su sintaxis y
su semántica es interoperable. Entre los más im-
portantes se pueden citar:

• Fecha de origen (Date): indica la fecha y hora

en que el mensaje se terminó de escribir.

• Remitentes: indican información sobre el

origen del mensaje: Autor (From), Remitente
(Sender), y dirección de respuesta (Reply To).

• Destinatarios: indican información sobre los

destinatarios del mensaje: Dirigido a (To), Co-
pia (Cc) y Copia Ciega (Bcc).

• Identificación: ofrecen un mecanismo para ras-

38
 trear instancias de los mensajes, así como tam-
bién crear hilos de discusión: Identificador de
mensaje (Message Id), Mensaje al que se respon-
de (In Reply To), Hilo de discusión (References).

• Información: dan información adicional so-

bre el mensaje, dirigida a seres humanos y no
a máquinas: Asunto (Subject), Comentarios
(Comments), Claves (Keywords).

• Seguimiento: transportan información sobre

el camino recorrido por el mensaje desde que
fue emitido hasta que llegó al destinatario.
Estos encabezados son muy importantes a la
hora de determinar la autenticidad del origen
de un mensaje: camino de retorno (Return-
Path) y Salto de transporte (Received). Cada
agente de transferencia de correo debería
agregar un encabezado de salto de transpor-
te, indicando de qué máquina, a qué hora y
para qué dirección fue recibido el mensaje.

2.2.3.4. Direcciones En todos aquellos encabezados que aceptan di-

de correo recciones de correo electrónico, el estándar es-
electrónico tablece una sintaxis definida. A continuación se
detallan las formas comunes:

• Dirección: sólo la dirección de correo. Por

ejemplo:
To: jperez@spamina.com
• Dirección con nombre: la dirección con un
nombre asociado. En este caso, la dirección
debe ir encerrada entre corchetes angulares.
Por ejemplo:
To: Jose Perez <jperez@spamina.com>
• Lista de direcciones: una lista de direccio-
nes, o direcciones con nombre pueden indi-
carse en el encabezado, separadas por coma.
Por ejemplo:
To: jperez@spamina.com,
Pedro Fernández
<pfern@spamina.com>

39
 • Lista de direcciones con identificador de
grupo: de manera similar al caso anterior,
pero con un identificador de grupo. El iden-
tificador se pone adelante, y se separa de la
lista de direcciones con dos puntos(:). Por úl-
timo, el grupo se termina con punto y coma
(;). Por ejemplo:
To: Oficina:jperez@spamina.com,
pfern@spamina.com
• Lista vacía con identificador de grupo: es un
caso particular de la sintaxis explicada en el
punto anterior, donde no se pone ninguna
dirección en el grupo. Se suele utilizar para
indicar el nombre del grupo sin revelar las
direcciones, que se ponen en el campo de
copia oculta. Por ejemplo:
To: Destinatarios no revelados:;
Bcc: jperez@spamina.com,
pfern@spamina.com

La figura 3 muestra un mensaje completo, con

algunos de los encabezados relevantes en una
sintaxis que conforma la RFC 2822.

Figura 3: Cuerpo Re t ur n- Pa t h: <j pe r e z @s pa mi na . c om>

Re c e i v e d: f r om s mt p. s pa mi na . c om
codificado en ( s mt p. s pa mi na . c om [ 1 9 2 . 1 6 8 . 9 6 . 4 ] )
E
sintaxis RFC 2822 by f i na l . s pa mi na . c om wi t h L MT PA N
f or <pf e r na nd@s pa mi na . c om>; C
F r i , 2 9 Aug 2 0 0 8 1 9 : 4 1 : 1 5 - 0 3 0 0 A
Re c e i v e d: f r om c l i e nt e . s pa mi na . c om
B
( c l i e nt e . s pa mi na . c om [ 1 9 2 . 1 6 8 . 9 6 . 2 ] )
( a ut he nt i c a t e d bi t s =0 ) E
by s mt p. s pa mi na . c om wi t h E S MT P i d m7 T MnqAp0 3 0 7 2 1 Z
f or <pf e r na nd@s pa mi na . c om>; A
S a t , 3 0 Aug 2 0 0 8 0 0 : 4 9 : 5 2 +0 2 0 0 D
Da t e : S a t , 3 0 Aug 2 0 0 8 0 0 : 3 6 : 0 7 +0 2 0 0
S ubj e c t : E j e mpl o de c odi f i c a c i on RF C 2 8 2 2 O
F r om: J os e Pe r e z <j pe r e z @s pa mi na . c om> S
T o: Pe dr o F e r na nde z <pf e r na nd@s pa ni na . c om>
Cc : J ua n Gonz a l e z <j ua ng@s pa mi na . c om>
Me s s a ge - I D: <C4 DE 4 6 7 7 . 4 B7 4 %j pe r e z @s pa mi na . c om>

Hol a , C
e s t e e s un me ns a j e pa r a de mos t r a r l a c odi f i c a c i on U
RF C 2 8 2 2 e l t e x t o de l c ue r po e s l i br e , s i e mpr e que E
r e s pe t e l a l ongi t ud ma x i ma de l i ne a y s e ut i l i c e n R
c ar ac t er es AS CI I uni c a me nt e . P
O

40
2.2.4. MIME El estándar MIME (Multipurpose Internet Mail Ex-
tensions) fue creado con el objetivo extender la
especificación de formato descrita en la RFC 2822
a fin de permitir transmitir contenido arbitrario,
sin perder la compatibilidad y utilizando la misma
infraestructura definida por esa RFC. MIME está
especificado en 4 RFCs diferentes, que se descri-
birán a continuación.

2.2.4.1. Cuerpos MIME La RFC 2045 define la sintaxis que debe tener un
cuerpo de mensaje RFC 2822 a fin de ser compa-
tible con el estándar MIME:

• Se define el encabezado MIME-Version que

permite a los agentes de correo reconocer un
mensaje compatible con MIME de otro que no
lo es, así como también la versión de MIME uti-
lizada. La versión en vigencia es la 1.0.

• Se define el encabezado Content-Type que

permite especificar el tipo y subtipo de con-
tenido del cuerpo, así como también la forma
en que este contenido está codificado en for-
ma nativa (llamada forma canónica).

• Se define un encabezado que especifica la

codificación utilizada para convertir la for-
ma canónica en una sucesión de caracteres
ASCII compatibles con la RFC 2822 y viceversa:
Content-Transfer-Encoding. Este encabezado
también indica (en forma explícita o implícita)
el resultado obtenido por esta codificación (de-
nominado dominio en el estándar).

• Se definen un par de encabezados adicio-

nales para describir los datos del cuerpo:
Content-ID para identificar unívocamente la
instancia del cuerpo y Content-Description
para describir su contenido.

41
 2.2.4.2. Codificaciones La RFC 2045 define tres dominios y dos codifi-
y dominios caciones que se pueden especificar en el enca-
bezado Content-Transfer-Encoding. Cuando se
especifica directamente el dominio, se indica im-
plícitamente que no se aplica ninguna codifica-
ción. Los dominios son los siguientes:

• 7bit: formado por líneas de caracteres ASCII

que conforman las RFC 2821 y 2822 descritas
más arriba. Es el valor por defecto cuando no
se especifica el encabezado Content-Trans-
fer-Encoding.

• 8bit: igual que el dominio 7bit, pero permi-

tiendo caracteres no ASCII en las líneas. Este
dominio sólo se puede utilizar en la transmi-
sión de correo electrónico si los agentes de
transmisión poseen la extensión 8BITMIME
del protocolo SMTP (explicada más arriba).
Por esa razón se desaconseja su uso, a fin de
evitar problemas de interoperabilidad.

• Binary: indica una sucesión de bytes sin ningún

tipo de restricción. Este dominio no se puede
utilizar para la transmisión de correo electróni-
co, aunque sí se puede utilizar para otros fines
(como almacenamiento, por ejemplo).

Por otro lado, se presentan dos codificaciones

que permiten convertir contenido arbitrario en
una codificación 7bit:

• Quoted-printable: es una codificación que

permite representar cualquier byte con un
signo ‘=’ seguido de su valor, representado
en hexadecimal con las letras mayúsculas.
(ej. ‘=7ª’ para representar el caracter ASCII
‘z’). Los caracteres ASCII pueden represen-
tarse de manera normal (con la excepción
del signo ‘=’), y los saltos de línea se pueden
escapar con un signo ‘=’ al final de la línea.
Esta codificación se utiliza para que el texto
codificado pueda ser comprensible por un ser

42
 humano sin necesidad de decodificarlo, y en
general se prefiere para codificar texto y otra
información naturalmente dividida en líneas.

• Base64: esta codificación utiliza un alfabeto de

65 caracteres ASCII (64 utilizados para repre-
sentar un número de 6 bits y 1 para represen-
tar un discernible, el caracter ‘=’). La entrada se
toma de 3 bytes (24 bits) y se divide en 4 gru-
pos de 6 bits que se codifican luego utilizando
el alfabeto mencionado. Como los grupos de-
ben ir completos, si no alcanzan los bytes de
la entrada para completar el último grupo, se
completa la cifra con bits en cero a la derecha
y se completa el grupo con discernibles.

La codificación base64 se prefiere en aquellos ca-

sos en que se desea codificar contenido binario,
sin formato, o no orientado a la línea.

La figura 4 muestra un ejemplo un texto codifi-

cado nativamente en iso-8859-1 convertido a sus
versiones quoted-printable y base64.

Figura 4: n a t iv o ( is o - 8 8 5 9 - 1 )
Codificación quoted- L a s pi r á mi de s t i e ne n muc hos a ños de a nt i güe da d
printable y base64 q u o t e d - p r in t a b le
L a s pi r =E 1 mi de s t i e ne n muc hos a =F 1 os de a nt i g=F Ce da d
bas e64
T GF z I HBpc uF t a WRl c y B0 a WVuZW4 gbXVj a G9 z I GHx b3 MgZGUgYW5 0
a Wf 8 ZWRhZAo=

2.2.4.3. Tipos MIME La RFC 2046 define el formato del encabezado

Content Type, los tipos principales de medio, los
subtipos y sus parámetros.

El tipo principal se separa del subtipo con una barra

directa (/), y a continuación se pueden especificar cero
o más parámetros en la forma <nombre>=<valor>,
separados por punto y coma (;).

43
 La RFC 2046 define los siguientes tipos principales:

• Text: utilizado para especificar todos aquellos

contenidos que pueden codificarse como tex-
to. El estándar define el subtipo ‘plain’ para
codificar el texto puro, y el parámetro ‘charset’
para indicar la codificación nativa utilizada.
Ejemplo:
Content-Type: text/plain;
charset=ISO-8859-1

• Image: utilizado para transmitir imágenes.

El subtipo debe indicar el formato utilizado
para codificar la imagen. El subtipo definido
en el estándar es jpeg.

• Audio: utilizado para transmitir audio. El sub-

tipo debe indicar el formato utilizado para
codificar. El subtipo definido en el estándar es
basic, que indica un canal de audio, codificado
en PCM con muestras de 8 bits con frecuencia
de muestreo de 8KHz15.

• Video: utilizado para transmitir video. El es-

tándar define video como una forma de ima-
gen que cambia en el tiempo, con un posible
canal de audio sincronizado. El subtipo debe
indicar el formato utilizado para codificar. El
subtipo definido por el estándar es mpeg.

• Application: utilizado por defecto para trans-

mitir información binaria. En general, indica
que se requiere de un software externo para
interpretar la información. Los subtipos defi-
nidos por el estándar son postscript y octect
stream.

En concreto, el estándar recomienda que todo

aquel tipo desconocido, subtipo desconocido, o
texto con charset desconocido, sea tratado como
el tipo genérico application/octect-stream.
15. Esta codificación de audio digital es muy
simple y general, y tiene la misma capaci-
dad que una línea telefónica.
44
2.2.4.4. Los tipos Además de los tipos principales descritos más arriba,
compuestos el estándar también define dos tipos denominados
compuestos o de composición (composite), que lo
que permiten es encapsular un cuerpo MIME, con sus
propios encabezados, dentro de otro cuerpo MIME.
Estos tipos aceptan el parámetro boundary que
permite a los agentes distinguir de manera flexible
y robusta cada una de las partes de la composición.
Una de las restricciones más importantes que poseen
las partes es que el encabezado de recodificación
Content-Transfer-Encoding sólo puede contener los
valores 7bit y 8bit, evitando de esta manera una do-
ble recodificación. A menos que se indique otra cosa,
el valor por defecto del encabezado Content Type es
text/plain con charset US-ASCII.

Los tipos compuestos definidos por la RFC 2046 son

los siguientes:

• Multipart: indica que el cuerpo está formado

por una o más partes independientes. En parti-
cular, un cuerpo multipart puede formar parte
de otro multipart. Los subtipos definidos son los
siguientes:

1. Mixed: indica una o más partes de igual o distinta

naturaleza, que llevan un orden definido. Por ejem-
plo, un mensaje con una imagen adjunta.

2. Alternative: indica una o más partes que repre-

sentan la misma información, aunque eventual-
mente representada de distinta manera. Por
ejemplo, un mensaje emitido en texto plano y
también en html, de forma tal que quien tiene
un lector de correo que interpreta html muestre
esta alternativa, mientras que quien no puede
representar html pueda acceder a la información
representada en texto plano.

3. Digest: similar al mixed, pero pensado especial-

mente para que sus partes sean mensajes comple-
tos. El encabezado Content-Type por defecto de los
digest es message/rfc822 (explicado más abajo).

45
 4. Parallel: similar al mixed, pero con diferente se-
mántica. En este caso, el orden de las partes no
es relevante, y de ser posible, deben ser mostra-
das en paralelo o al mismo tiempo.

• Message: indica que el cuerpo es el contenido

de un mensaje completo, con sus encabezados
incluidos. Naturalmente, el mensaje contenido
puede conformar el estándar MIME, e incluso
contener tipos multipart o message dentro de
ellos. Los subtipos definidos son los siguientes:

1. Rfc822: indica que el contenido es un mensaje

que conforma la RFC 282216 descrita más arriba.
Este es el subtipo por defecto para message.

2. Partial: permite dividir un mensaje grande en

fragmentos y transmitir cada fragmento por se-
parado. Se definen los parámetros id, number y
total que se utilizan para reconstruir el mensaje
original una vez que todos los fragmentos hayan
alcanzado el destino.

3. External body: permite indicar el cuerpo por

referencia, en vez de incluirlo explícitamente
dentro del mensaje. Se definen los parámetros
name y acces type para que los agentes puedan
acceder al contenido del cuerpo por un método
externo.

La figura 5 muestra el cuerpo MIME completo de un

mensaje multiparte que contiene un texto y dos pe-
queñas imágenes adjuntas:

16. Debe notarse que el nombre del subtipo

RFC822 corresponde al hecho de que en el
momento de la publicación de la RFC 2046
la RFC 2822 no existía aún, y por lo tanto es-
taba en vigencia su antecesora: la RFC 822.

46
 Figura 5: Ejemplo S ubj e c t : E j e mpl o de s i nt a x i s de c ue r pos MI ME
de mensaje en MI ME - Ve r s i on: 1 . 0
Cont e nt - T y pe : mul t i pa r t / mi x e d;
formato MIME. bounda r y =" s e pa r a dor de pa r t e s MI ME "

E s t e e s un me ns a j e e n f or ma t o MI ME .
- - s e pa r a dor de pa r t e s MI ME
Cont e nt - T y pe : t e x t / pl a i n; c ha r s e t =I S O- 8 8 5 9 - 1 5
Cont e nt - T r a ns f e r - E nc odi ng: quot e d- pr i nt a bl e

E s t e e s un t e x t o que ut i l i z a l a c odi f i c a c i =F 3 n i s o- 8 8 5 9 - 1 5 =
, pa r a pe r mi t i r
e l us o de l E ur o ( =A4 ) y e l C=E 9 nt i mo ( =A2 ) . A c ont i nua c i =
=F 3 n s e e nc ue nt r a n a dj unt a s dos pe que =F 1 a s i m=E 1 ge ne s .

- - s e pa r a dor de pa r t e s MI ME
Cont e nt - T y pe : i ma ge / png; na me =” i ma ge n1 . png”
Cont e nt - T r a ns f e r - E nc odi ng: ba s e 6 4
Cont e nt - Di s pos i t i on: i nl i ne ; f i l e na me =" i ma ge n1 . png"

i VBORw0 KGgoAAAANS UhE UgAAABYAAAAWCAYAAADE t Gw7 AAAABHNCS VQI CAgI f

Ahk i AAAABF 0 5 nf I 2 uAf E Xm/ t r a mz M/ Pl 9 y 4 o6 Oj s M9 1 x G/ gM/ AT e KYoi qi qS i
QS I RQKy e L i 4 s HR0 dH9 Ys Y9 XGx z d3 dX8 r XMr S dnqv XI NM0 NwDF N8 x NZ+z 0 nV6 P
v 6 +u7 z OgV4 KYbs F j / ZT T B6 T CNc j pMX3 CNYf oXhCJ uZf 6 HD7 UAAAAAS UVOYI I =
- - s e pa r a dor de pa r t e s MI ME
Cont e nt - T y pe : i ma ge / png; na me =" i ma ge n2 . png"
Cont e nt - T r a ns f e r - E nc odi ng: ba s e 6 4
Cont e nt - Di s pos i t i on: i nl i ne ; f i l e na me =" i ma ge n2 . png"

T j oODMc y Wa P5 y BDq9 c 6 k r wJ g9 ws ol z X/ t t L S k hf v Wf O8 b+bc u0 GI 0 T ny c bp/ 7

a Bz z wH9 Yi K3 7 s 3 f 3 S 9 uZNwQv l q7 ni bs e qbt Dc +qXdDy 7 CZZWAYdH2 9 2 hwa HOw
J u7 t G2 nz D/ r / e m8 NXa v pZ7 S 0 qnt z uOL MWi i VUbOz h+q5 7 / API CO1 ux y j NhAAA
AAE l F T k S uQmCC
- - s e pa r a dor de pa r t e s MI ME - -

2.2.4.5. Extensiones Si bien las RFC 2045 y 2046 describen una forma en
MIME para la cual se pueden transmitir cuerpos con información
encabezados representada arbitrariamente a través de las vías dis-
puestas por la RFC 2822, el problema sigue existiendo
para los encabezados, cuyo contenido debe atenerse
estrictamente a contener únicamente caracteres ASCII.
Esto introduce una dificultad a la hora de utilizar los
encabezados destinados a ser leídos por el hombre,
cuando el idioma utilizado por éste no puede escri-
birse correctamente utilizando únicamente caracteres
ASCII. El idioma español está incluido dentro de este
conjunto.

Para resolver este problema, sin amenazar la intero-

perabilidad de los sistemas nuevos con los existentes,
la RFC 2047 propone un mecanismo mediante el cual
se pueden utilizar las codificaciones quoted-printable
y/o base64 descritas más arriba para codificar pala-
bras dentro de los encabezados, que si bien solo con-
47
 tienen caracteres ASCII, pueden ser decodificadas por
los agentes para mostrar cualquier tipo de caracter.
Las consignas principales son las siguientes:

• Se conserva por compatibilidad el concepto

de palabra o token de la RFC 2822, como una
sucesión de caracteres ASCII que no represen-
ten espacios.

• Una palabra codificada es una palabra que

contiene información suficiente para que un
agente pueda extraer de ella una o más pala-
bras en lenguaje natural que pueden contener
caracteres no ASCII.

• La palabra codificada se forma utilizando una

convención que tiene una probabilidad muy
baja de aparecer naturalmente dentro de los
encabezados.

• Las palabras codificadas comienzan con la

combinación de caracteres ‘=?’ y terminan con
la combinación ‘?=’. Además, contienen exac-
tamente dos caracteres ‘?’ que actúan como
separadores.

• En la primera sección de la palabra se especifi-

ca la codificación nativa de la palabra.

• En la segunda sección se indica la letra ‘Q’ o la

letra ‘B’ para indicar la codificación final utili-
zada que será quoted printable o base64, res-
pectivamente.

• Por último, en la última sección se introduce la

palabra codificada donde, de existir espacios,
los mismos deben codificarse u, opcionalmen-
te en quoted printable, pueden reemplazarse
con un guión bajo ‘_’.

Por ejemplo, el texto ‘Citas del próximo año 2009’ en

el asunto de un mensaje puede representarse de la
siguiente manera:

48
 Subject: Citas del
=?ISO-8859-1?Q?Pr=F3ximo_a=F1o?= 2009

Puede apreciarse que dos palabras del lenguaje na-

tural fueron codificadas en una sola palabra.

2.2.4.6. Extensiones al MIME fue desarrollado para ser naturalmente exten-

estándar MIME sible. Se pueden agregar nuevos tipos, nuevos subti-
pos, nuevas codificaciones de transferencia, y nuevos
algoritmos. A tal fin la RFC 2048 describe un riguroso
proceso que permite el registro y la universalización
de dichas extensiones a través del IANA (Internet As-
signed Numbers Authority).

Existen tres caminos para generar una extensión a

MIME:

• Extensiones de uso experimental: no requieren

ningún tipo de aprobación ni de registro. Para
distinguirlas su nombre siempre debe comenzar
con ‘x_ ‘ o ‘x.’ .

• Extensiones personales: son extensiones que

pueden ser presentadas ante el IANA directa-
mente para su registro. Comienzan con ‘prs.’Y no
requieren exposición pública ni aprobación.

• Extensiones IETF: las extensiones destinadas a

ser utilizadas en forma masiva deben proponer-
se utilizando el mecanismo de RFC a fin de mejo-
rar su calidad y después de ser aprobadas, antes
de proceder a su registro en el IANA.

2.2.4.7. Recomendaciones La RFC 2049 lista una serie de recomendaciones para

y conformidad la implementación de codificadores y decodificado-
res MIME, así como también define un marco que
se puede utilizar para medir la conformidad de una
implementación específica con el estándar. También
presenta algunos ejemplos de manera similar a como
se ha hecho en este documento, aunque de una ma-
nera un poco más formal.
49
 2.3. Prácticas de El objetivo del spammer es lograr que la mayor
los spammers cantidad posible de copias del correo enviado
llegue a las bandejas de entrada de los usuarios,
evitando las barreras y los filtros. En esta sección
se describen algunas técnicas generalizadas y co-
munes que utilizan los spammers para enviar co-
rreo electrónico masivo.

2.3.1. La falsificación El protocolo SMTP, descrito más arriba, provee

de identidad mecanismos mediante los cuales la máquina que
envía el correo, así como el remitente, se identi-
fican ante el servidor. Estas identificaciones no
son autentificadas, por lo cual ambos pueden ser
falseados.

Falsear la identidad no es conveniente para quien

realmente desea enviar un correo y su interés es
que el correo llegue a destino, o bien enterarse
(mediante una notificación de envío) que el co-
rreo no llegó. Sin embargo, desde el punto de
vista del spammer, y ante el peligro de ser identi-
ficado y baneado17, la falsificación de identidad es
un recurso muy utilizado. Existen dos formas de
falsificación de identidad:

• Inventar una identidad totalmente inexisten-

te (nombre local y dominios falsos), o bien
parcialmente inexistente (nombre local falso
y dominio auténtico).

• Utilizar una identidad existente y pertene-

ciente a un tercero. Cuando esta práctica se
hace intencionalmente se denomina imper-
sonación, y tiene connotaciones más graves,
tanto a nivel ético como a nivel legal.

17. Castellanización del término inglés to be

banned, que significa marcado para prohi-
bir la entrada.

50
2.3.2. Arquitectura SMTP Antiguamente los servidores de SMTP aceptaban
y relays abiertos correo de cualquier origen, y dirigido a cualquier
destino. Naturalmente, con el avance del Spam
esta práctica se volvió peligrosa, porque permite
a los spammers la utilización de un servidor SMTP
de un tercero para enviar correo, sin tener que fal-
sear su identidad como se menciona más arriba.
A fin de definir correctamente lo que actualmen-
te se considera relay abierto, se definirán primero
los conceptos de tipo de remitente y tipo de des-
tinatario desde el punto de vista de un servidor
SMTP.

2.3.2.1. Tipos de Desde el punto de vista de un servidor SMTP ac-

remitente tual existen dos tipos de remitente:

• Remitente local: es un cliente del dominio

desde donde se envía el correo. Es lícito que
un remitente local utilice su servidor de SMTP
para enviar correo, tanto a los dominios loca-
les como a dominios externos.

• Remitente externo: es un remitente que no

pertenece al dominio desde donde se envía
el correo.

Para distinguir un remitente local, el servidor pue-

de utilizar una o más de las siguientes técnicas:

• IP de Origen: el servidor identifica la IP de

origen de la conexión SMTP. El remitente será
local si, y solo si, la IP desde donde se origina
la conexión se encuentra dentro de la red de
confianza, es decir la red donde solamente se
encuentran remitentes locales (como puede
ser una red interna). Las ventajas de este me-
canismo son la simplicidad y el no necesitar
extensiones al protocolo SMTP para funcionar.
Entre las desventajas que posee se pude men-
cionar que solamente permite enviar correo
desde esa red, perdiendo universalidad, y que
si bien se puede identificar al remitente como
51
 local en general, no se puede identificar a un
remitente local en especial.

• POP Before SMTP ó IMAP Before SMTP: una

técnica que exige a los remitentes locales re-
visar su bandeja de correo, de manera que la
IP de origen quedará registrada en una base
de datos, con un tiempo de vencimiento (por
ejemplo, 10 minutos). La red de confianza
mencionada en el item anterior se forma con
las IP’s registradas en esa base de datos. La
ventaja de este mecanismo es que permite
identificar a un remitente local en particular,
y que no requiere extensiones al protocolo
SMTP. La desventaja es la exigencia operativa
hacia el usuario de tener que revisar su ban-
deja de correo antes de poder enviar correo.

• SMTP Autenticado: esta moderna técnica

permite, mediante una extensión al protoco-
lo SMTP (descrita más arriba), solicitarle al re-
mitente identificación y autentificación para
considerarlo remitente local. La principal
desventaja de esta técnica es que requiere
una extensión al protocolo SMTP. Sin embar-
go, debe destacarse que esto ha dejado de
ser un problema debido a que la autentifica-
ción SMTP está ampliamente generalizada
en Internet, tanto entre clientes como entre
servidores de SMTP.

• Autenticación TLS/SSL: permite identificar

a un remitente local durante la negociación
TLS/SSL que se utiliza para transmitir datos de
manera cifrada. Es un mecanismo extremada-
mente seguro, debido a que no requiere nin-
gún tipo de intercambio de contraseñas, sin
embargo, es complicado de implementar en
la práctica y por lo tanto no es muy utilizado.

52
2.3.2.2. Tipos de Desde el punto de vista del servidor SMTP existen
destinatario tres tipos de destinatarios:

• Destinatario local: es un destinatario que

pertenece a un dominio local, cuya bandeja
de correo se encuentra directamente acce-
sible al servidor. Una característica impor-
tante de los dominios locales es que el ser-
vidor SMTP conoce la lista de destinatarios
existentes, y por lo tanto puede rechazar un
mensaje dirigido a un usuario inexistente del
dominio.

• Destinatario por reenvío autorizado: es un

destinatario que pertenece a un dominio
para el cual existe en el servidor una autori-
zación explícita de reenviar correo. A fin de
incrementar la disponibilidad, un dominio
puede declarar, además de su servidor de
intercambio de correo (MX) principal, cero o
más servidores de intercambio de correo se-
cundarios, que deben aceptar el correo diri-
gido para el dominio y reenviarlo al servidor
de correo principal. Una de las características
más importantes que posee un servidor se-
cundario es que no necesariamente conoce
la lista de destinatarios existentes, viéndose
obligado a aceptar todo el correo dirigido al
dominio con reenvío autorizado. Esta es una
de las razones por la cual los spammers pre-
fieren utilizar los servidores secundarios de
los dominios para inyectar Spam.

• Destinatario externo: es un destinatario que

no pertenece a un dominio local, ni a un do-
minio con reenvío autorizado. Normalmente
se desconoce totalmente la lista de usuarios
existentes en dominios externos.

Se denomina Relay Abierto a un servidor SMTP

que acepta correo de un remitente externo para
enviarlo a un destinatario externo.

53
 La figura 6 muestra la forma correcta en que de-
bería estar configurado un SMTP a fin de evitar
convertirse en relay abierto.

Figura 6: Servidor SMTP

bien configurado

2.3.3. Las botnets Se denominan botnets a redes de ordenadores

que son capaces de actuar en forma colaborativa
para lograr un fin. Si bien existen botnets lícitas,
donde se solicita al usuario consentimiento para
utilizar una parte del poder de procesamiento
de su ordenador, en este documento se tratarán
aquellas donde no existe conocimiento ni volun-
tad del dueño u operador.

Normalmente las botnets malignas se generan a

través de una forma de malware que se propaga
entre las máquinas víctimas, ejecutando código
sin que el usuario sea consciente de ello. Además
de utilizarse para propagar Spam, las botnets se
utilizan para generar ataques distribuidos de de-
negación de servicio (DDoS) dirigidos contra un
sitio, persona o empresa, o bien para actos de te-
rrorismo informático.

Las dos formas comunes en que estas redes se

generan son las siguientes:

• A través de virus informáticos que llevan un

código de propagación que les permite pro-
pagarse ya sea por medios autónomos o con-
venciendo al usuario de que lo haga, a través
54
 de técnicas de ingeniería social, y un código
activo preparado para activarse en algún mo-
mento y realizar alguna acción destructiva, o
bien, un pequeño servidor de SMTP que en-
vía correo Spam que viene incorporado en el
mismo virus.

• A través de spyware que se propaga de ma-

nera similar a como lo hacen los virus, pero su
código activo los lleva a conectarse, o bien a
un punto central, o entre ellos utilizando una
técnica de par a par (p2p). De esta manera la
red puede ser comandada para emitir Spam,
o para realizar DDoS’s dirigidos.

2.3.4. Secuestro de Otra técnica normalmente utilizada para emitir

ordenadores Spam o para cometer otros delitos informáticos
es la de “secuestrar” ordenadores y servidores.

Normalmente los servidores son tomados a tra-

vés de Internet, aprovechando algún error en la
configuración de los mismos, o a través de la ex-
plotación de alguna vulnerabilidad de software.

Dependiendo de la gravedad de la vulnerabilidad,

el atacante puede ganar privilegios de usuario o
privilegios de administrador. En el primer caso,
todavía se puede intentar hacer un segundo ata-
que, denominado de ‘escalamiento de privilegios’
para obtener privilegios de administrador. Exis-
ten compilados de software ya preparados para
tal fin, denominados ‘rootkits’, que de manera
sencilla exploran el sistema en busca de vulnera-
bilidades que permitan tomar privilegios de ad-
ministrador, y luego toman una serie de medidas
para ‘ocultar’ su presencia, de manera tal que se
pueda utilizar la máquina sin que su dueño u ope-
rador lo noten.

Para instalar un software que envíe Spam, nor-

malmente no es necesario poseer privilegios de
administrador, basta con obtener un acceso de
55
 usuario para instalar un pequeño servidor de
SMTP y enviar millones de correos.

2.3.5. Técnicas utilizadas Además de falsificar su identidad mediante la ge-

para enviar ‘Spam’
neración de encabezados falsos, o enviar correos
a través de ordenadores de terceros convertidos
en zombies18, los spammers cuentan con otros
recursos que les permiten intentar engañar a los
mecanismos antispam. Algunos de estos meca-
nismos se muestran a continuación.

2.3.5.1. Ofuscamiento El ofuscamiento es una técnica que busca engañar

los filtros de contenido (explicados más abajo) a fin
de generar un mensaje que el ser humano interpreta
de una manera, pero que la máquina lo interpreta de
otra diferente.

La forma más sencilla de ofuscamiento es utilizar

las codificaciones MIME descritas más arriba. Los
filtros más antiguos no hacían la decodificación
MIME y por lo tanto eran incapaces de analizar un
texto codificado.

La figura 7 muestra un texto ofuscado de manera

sencilla mediante una codificación MIME.

Figura 7: Ofuscamiento Subject: =?ISO-8859-1?B?Q29tcHJlIFZpYWdyYQ==?=

sencillo en cabecera MIME =?ISO-8859-1?B?YWwgbWVqb3IgcHJlY2lvIQ==?=

C a be c e r a MIME

As unto: C om pre V ia gra a l m e jor pre cio!

Lo que ve e l us ua r io

Como ventaja (desde el punto de vista del spa-

18. Se denomina zombie a un ordenador
que se encuentra secuestrado o quedó con-
vertido en miembro de una botnet como se
explica más arriba.
56
mmer) esta técnica es muy sencilla y no viola los
estándares, y como desventaja puede mencio-
narse que esta técnica ya no engaña a los filtros
por contenido modernos.
Otra forma más elaborada de ofuscamiento es la
de utilizar texto codificado en imágenes. El pro-
 cedimiento de extracción de texto contenido en
imágenes, conocido como OCR (Optical Charac-
ter Recognition), es un procedimiento impreciso y
costoso, y mediante la introducción de ruido blan-
co en el fondo de la imagen se vuelve práctica-
mente imposible para la máquina. Sin embargo, el
ojo humano está muy entrenado para reconocer
texto contenido en imágenes, aunque el mismo
esté muy distorsionado o con muy bajo contras-
te respecto del fondo. La ventaja de esta técnica
(siempre desde el punto de vista del spammer) es
que es extremadamente difícil distinguir una ima-
gen inocua de una imagen que contiene un texto
potencialmente detectable por un filtro de conte-
nido. La desventaja es que las imágenes ocupan
más espacio, haciendo cada correo más grande y
por lo tanto aumentando sensiblemente los tiem-
pos de transmisión.

Por último, otra técnica utilizada es el ofuscamiento

en código html. Actualmente el html se utiliza como
lenguaje para transmitir mensajes con texto enri-
quecido (fuentes, colores, distintos tamaños, etc.),
imágenes y tablas embebidas, etc. A tal fin existe el
tipo MIME text/html reconocido por prácticamente
cualquier cliente de correo gráfico moderno. La co-
dificación html permite fácilmente ocultar texto fácil-
mente visible para el ser humano, pero muy difícil de
detectar para una máquina. Como ventaja se puede
mencionar que es más liviana y fácil de generar que el
ofuscamiento con imágenes, pero como contraparti-
da es más fácil de detectar por medios automáticos.

La figura 8 muestra un ejemplo sencillo de ofus-

camiento en código html.

Figura 8: Ofuscamiento <table><tr><td><b>V</b></td><td><em>I</em></td><td

sencillo usando HTML ></td><td><em>G</em></td><td><b>R</b></td><td><em>
td></tr></table>

C ódigo HT ML

V IA G R A

Lo que ve e l us ua r io

57
 2.3.5.2. Saturación La saturación es una técnica que se utiliza para
atacar listas negras y redes bayesianas (explica-
das más abajo). Consiste en generar contenido
aleatorio en el cuerpo del mensaje junto con el
correo ofensivo, o direcciones de correo aleato-
rias en el encabezado From.

Un mismo spammer puede falsificar su identidad

en el encabezado From con direcciones de correo
aleatorias, incluso inexistentes. Los usuarios que
crean listas negras con los remitentes de correo
que consideran Spam, llenarán sus listas negras
de direcciones de correo que fueron utilizadas
una sola vez, llevándolas a un tamaño inmaneja-
ble y posiblemente dejándolas inutilizables.

En el caso del contenido aleatorio, el objetivo del

ataque son los filtros por contenido de cuerpo, ya
sea manuales o basados en técnicas de IA, como
las redes bayesianas. El texto aleatorio se gene-
ra con párrafos o frases tomadas al azar de algún
texto (eventualmente de la web), que si se lee de
forma literal no tiene sentido, pero que contiene un
montón de palabras que pueden llevar a la red de
bayes a decidir que el correo es válido. Si el usuario
además utiliza esta clase de correos para entrenar
la red, genera una saturación en la misma que la
vuelve inutilizable.

58
3. Políticas contra La problemática del Spam se centra en un conflicto
el ‘Spam’ de intereses encontrados. El spammer por su lado
intenta hacer un negocio generando un mecanis-
mo de publicidad muy económico y efectivo, pero
muy cuestionable desde el punto de vista ético.
Por otro lado, el usuario final pierde concentración
y productividad al tener que revisar una enorme
cantidad de correo para buscar lo que realmente
le resulta importante, generando una pérdida per-
sonal y, en algunos casos, corporativa.

Como ocurre con cualquier conflicto de intereses,

no existe una solución definitiva hasta que dichos
intereses dejen de estar encontrados. En este caso
el problema se resolvería si el Spam dejara de ser
un buen negocio, o si dejara de causar pérdidas a
individuos y/o empresas. No existe en un futuro
cercano una probabilidad importante de que al-
guna de esas dos cosas ocurra, con lo cual no es
posible encontrar una solución definitiva. Sin em-
bargo, sí existen formas de reducir el problema. En
este capítulo se analizarán las alternativas.

3.1. Técnicas de Se denominan técnicas de precaución a todas

precaución aquellas que buscan prevenir que el Spam se ori-
gine. Es decir, apuntan a resolver el problema de-
finitivamente. Este tipo de técnicas actúan a largo
plazo, y se vuelven efectivas en la medida en que
los individuos y la sociedad evolucionan.

Se pueden distinguir dos tipos de técnicas de

precaución:

• Educación de los usuarios: si ningún usuario

abriera los correos Spam, ni leyera, ni contestara,
ni comprara productos o servicios de los cuales
se informó a través de un correo Spam, éste deja-
ría de ser un negocio y desaparecería.
• Naturalmente este planteamiento es utópico,
sin embargo en la medida en que los usuarios
aprendan a ser cuidadosos en determinados as-
pectos, el daño que produce el Spam se irá redu-
59
 ciendo notablemente. Se puede enseñar a los
usuarios cuestiones básicas como no poner los
datos personales o dirección de correo en cual-
quier sitio, leer las políticas de privacidad de los
sitios a los que se accede, y por supuesto, no se-
guir bajo ningún concepto un correo spam, por
más que parezca conveniente en el momento. A
medida que la formación del usuario aumenta,
el problema se reduce.

• Leyes antispam: a corto plazo, se puede des-

alentar a los spammers a continuar con esa
conducta mediante leyes que la condenen.

3.2. Técnicas reactivas Son todas aquellas técnicas que buscan identificar un
correo Spam una vez que el mismo ha entrado en los
servidores de correo. Normalmente buscan identificar
el Spam por su contenido, ya sea sobre, encabezados,
o cuerpo. Después de identificarlo se procede a su
clasificación, para luego llevar a cabo una acción (por
ejemplo se puede optar por eliminar el Spam, o poner-
lo en una sección de cuarentena, separado del correo
válido).

Lamentablemente las técnicas reactivas solo resuel-

ven parte del problema. El correo Spam ya fue trans-
mitido y por lo tanto consumió recursos tanto duran-
te su transmisión como en el proceso de clasificación.
Durante la transmisión se consume gran cantidad
de ancho de banda de comunicación19. La clasifica-
ción en general además de ser imprecisa es costosa,
requiriendo poder de procesamiento y memoria; ge-
nerando por lo tanto la necesidad de utilizar equipos
mucho más potentes para poder procesar el correo.

La ventaja más importante que tienen estas técnicas

es que ofrecen la opción de usar una cuarentena,
para que el usuario tenga acceso al correo y pueda
compensar errores de clasificación.

19. Debe considerarse que más del 90% de Entre las técnicas reactivas utilizadas actualmente se
los correos transmitidos hoy en día por Inter-
net son Spam.
pueden mencionar:

60
• Listas blancas y negras: son mecanismos me-
diante los cuales un usuario, un administrador
o algún sistema automático sencillo genera lis-
tas de remitentes o de servidores en los que se
confía (lista blanca) y a los que se rechaza (lista
negra). De esta manera se puede aceptar a quie-
nes están en la lista blanca, y rechazar a quienes
están en la lista negra. Un punto importante a te-
ner en cuenta con respecto a las listas es que son
muy efectivas cuando la identidad del remitente
o del servidor puede ser fehacientemente de-
mostrada. Esto lamentablemente no es cierto en
la mayoría de los casos. Para pasar una lista blan-
ca, un spammer debería impersonar a alguien
que se encuentre en la misma. Esto requiere un
esfuerzo que normalmente el spammer no está
dispuesto a hacer. En ese sentido, la lista blanca
es efectiva para permitir paso a los remitentes de
confianza. Por otro lado, la lista negra suele ser
poco efectiva para evitar el Spam, porque basta
con que el spammer utilice una identidad falsa y
aleatoria para pasar la lista negra y a su vez ge-
nerar una saturación (explicada más arriba). Por
lo tanto, solo se debe usar la lista negra cuando
el spammer puede ser identificado, algo que en la
práctica rara vez ocurre.

• Reglas de contenido ponderadas: una técnica

muy efectiva para reconocer un correo Spam.
Se basa en analizar diferentes características del
contenido de un correo, asignando una pon-
deración a cada regla. Si aparecen suficientes
características sospechosas dentro de un co-
rreo, entonces el mismo es considerado Spam.
En general las reglas son simples, y el éxito del
método reside en elegir correctamente las pon-
deraciones a utilizar. Por citar algunos ejemplos
de reglas de contenido:

1. El correo está escrito en inglés: es más probable

que un Spam esté escrito en inglés que en algún
otro idioma.

61
 2. El correo está en html: es más probable que un
Spam esté codificado en html.

3. El correo tiene una imagen y poco texto: es

probable que sea un Spam que esconde texto
dentro de la imagen.

• Redes Bayesianas: una red bayesiana es un mo-

delo probabilístico que es capaz de aprender, en
función de un entrenamiento, a calcular la pro-
babilidad de ocurrencia de un evento. En este
caso, la probabilidad de que un correo sea Spam
en función de las palabras que contiene. Es muy
efectiva para reconocer Spam, pero requiere que
el usuario la entrene, indicándole primero ma-
nualmente qué correos son Spam y qué correos
no. Además, los spammers suelen enviar correo
con contenido aleatorio (como se explica más
arriba) y si el usuario entrena la red con este tipo
de correos la misma tiende a saturarse, perdien-
do rápidamente efectividad.

3.3. Técnicas proactivas Las técnicas proactivas son todas aquellas destinadas
a evitar que el correo Spam ni siquiera se transmita.
Se basan en intentar identificar al spammer en vez de
al correo Spam. En general, las técnicas proactivas son
muy efectivas, pero poseen el inconveniente de que
en caso de error no existe manera de que el usuario
acceda al correo rechazado, por lo tanto requieren un
monitoreo constante e intervención por parte de los
administradores de los sistemas de correo a fin de evi-
tar pérdida de información potencialmente valiosa.

Entre las técnicas proactivas más comunes pueden

citarse las siguientes:

• Listas de reputación de servidores: son siste-

mas centralizados que recogen, validan y pu-
blican información sobre distintos servidores
de correo que operan en Internet, generando
listas que se distribuyen públicamente a tra-
vés de diferentes métodos. El más difundido

62
 sin duda es DNSRBL (DNS Realtime Block Lists),
que utiliza el servicio DNS para publicar las di-
recciones IP de servidores que generan Spam,
poseen Relays abiertos, no obedecen correcta-
mente los estándares, trabajan en rangos de IP
dinámicas, etc. Consultando estas listas los ser-
vidores de correo pueden optar por rechazar las
conexiones provenientes de estos servidores.

Posiblemente el desafío más grande para estas lis-

tas de reputación es la de mantener la veracidad
de la información que contienen, porque pierden
rápidamente efectividad si registran servidores
genuinos, o por el contrario, si dejan demasiados
servidores generadores de Spam sin registrar.
Existen varios mecanismos para recolectar infor-
mación sobre servidores genuinos y servidores
generadores de Spam. Algunos ejemplos que
pueden mencionarse son los siguientes:

1. Trampas de Spam: también conocidas como

Honeypots, son casillas de correo secretas que se
publican en lugares de la web donde los seres
humanos no llegan, pero sí lo hacen las arañas20
que suelen utilizar los spammers para recolectar
direcciones de correo. El solo hecho de recibir un
correo en esta casilla indica con un altísimo gra-
do de probabilidad que quien emite el correo es
un spammers.

2. Pruebas Desafío/Respuesta: son mecanismos

automáticos que prueban los servidores de co-
rreo para verificar que están correctamente con-
figurados y que obedecen los estándares.

3. Denuncias directas: algunos sistemas de repu-

tación aceptan denuncias de administradores y,
previa verificación, proceden a listar las direccio-
nes IP de los servidores ofensivos.

• Fingerprinting: conforma una familia de téc-

20. Programas automáticos que recorren la nicas que buscan recopilar firmas de correos
web siguiendo hipervínculos y recolectando Spam, de manera tal que cuando un servidor
información. detecta un correo Spam (utilizando alguna de
63
 las técnicas reactivas descritas más arriba), genera
el informe y lo publica de forma tal que el resto
de los servidores que recibirían el mismo correo
puedan rechazarlo de antemano. Esta técnica es
muy utilizada sobre todo para detener los correos
Spam que ofuscan su contenido en imágenes.

• Greylisting: una técnica que se basa en incremen-

tar artificialmente el coste de envío de un men-
saje, obligando al remitente a reintentar varias
veces antes de permitirle entregar un mensaje.

Cuando llega un mensaje se verifica si el remiten-

te (dirección de correo y servidor) es conocido. En
caso de no ser conocidos se inicia una ventana
negra que puede durar entre 5 y 50 minutos. Du-
rante la ventana negra todo intento de entregar
el correo es rechazado con una respuesta SMTP
4XX (rechazo temporal). Pasado el tiempo de la
ventana negra se inicia la ventana gris, de entre
4 y 8 horas de duración. Si se reintenta la entrega
dentro de la ventana gris, el mensaje es acepta-
do y se inicia la ventana blanca. Si no se reintenta
la entrega dentro de la ventana gris, el registro
expira. La ventana blanca dura entre 20 y 40 días,
en los cuales todos los correos son aceptados sin
retrasos. Unos días antes de la expiración de la
ventana blanca la recepción de un correo de este
remitente genera una renovación automática
de la misma. Si las ventanas blanca o gris expi-
ran el remitente pasa a ser desconocido nueva-
mente y el proceso de validación debe repetirse.

A pesar de su aparente simplicidad, esta técnica

es notoriamente efectiva en la práctica, siempre
y cuando se combine con otras técnicas como las
descritas más arriba. La razón es que el spammer
normalmente no reintenta desde la misma IP y
con el mismo remitente. Y si reintentara, se arries-
ga a ser identificado y marcado (por ejemplo, en
una DNSRBL).

64
 La figura 9 muestra gráficamente el algoritmo de
greylisting.

Figura 9: Algoritmo
de greylisting

3.4. Resumen La investigación teórica y la experiencia de campo

obtenida demuestran claramente que no existe una
técnica que resuelva en forma definitiva y perma-
nente el problema del Spam. La mayor efectividad
se consigue con una combinación inteligente de téc-
nicas fiables y no obstrusivas como las explicadas en
este capítulo. Además, todo el proceso debe ser con-
tinuamente revisado para adaptarlo a la evolución
que los spammers naturalmente demuestran en sus
intentos por flanquearlo.

65
 4. Futuras amenazas y soluciones

4.1. Amenazas a nivel Cuando hablamos de spammers estamos hablando,

corporativo y social normalmente, de gente muy cualificada, con impor-
tantes recursos económicos y lo que es más impor-
tante, con la posibilidad de seguir ganando mucho
dinero. Esta combinación nos lleva a una conclusión
elemental: los spammers seguirán generando acti-
vidad y no dejarán de innovar para conseguir esqui-
var todas las trampas que les pongamos.

En cualquier caso no debemos ser pesimistas,

como mínimo a nivel técnico. La realidad es que
las empresas acostumbran a tener bastante con-
trolado el problema y la cantidad de Spam que re-
ciben los trabajadores es relativamente pequeña.
Si a los filtros antispam les sumamos la formación
a los usuarios, disminuimos muchísimo el posible
efecto del Spam.

Difícilmente podemos preveer los problemas futu-

ros que nos deparará el Spam, pero dos de las pre-
ocupaciones que tenemos en un futuro próximo
son la desconfianza de los usuarios y la fuga de in-
formación de las empresas mediante los botnets.

¿Es realmente tan fácil que alguien entre en una

cuenta bancaria ajena? Pocas personas conocen
a alguna víctima de phishing, pero aún así, la des-
confianza al usar las webs bancarias va en aumen-
to y si hay desconfianza significa que los avances
en este sector pueden verse afectados.

Existen grupos especializados en erradicar el

phishing y los bancos destinan sumas importan-
tes de dinero a solucionar este problema, pero la
educación de los usuarios sigue siendo la mejor
herramienta para combatirlo.

Un problema que nos encontraremos cada vez

con más frecuencia es el de la fuga de informa-
ción. El incremento de máquinas zombies es enor-
66
 me y éstas pueden ser tanto ordenadores persona-
les como de empresa. Eso significa que “alguien” es
capaz de navegar por la red de la empresa y copiar
información “teóricamente” confidencial. Traducido
al lenguaje coloquial estamos hablando de espio-
naje industrial. Esto es factible y cada vez más fácil
de hacer, pero no debemos olvidar que la mayor
parte de las fugas de información se hacen a través
de personas pertenecientes a la propia empresa.

4.2. Amenazas A nivel técnico, el fenómeno del Spam presenta los

a nivel técnico siguientes peligros:

• Contaminación: el espacio de correo electróni-

co, al igual que cualquier espacio público, sufre
del efecto de la contaminación, que en caso de
crecer demasiado, vuelve inefectivo y eventual-
mente inutilizable el servicio.

• Consumo de recursos: el Spam genera un gran

consumo de recursos, requiriendo equipos más
potentes y mayores anchos de banda para po-
der procesar el correo electrónico en general.

• Compromisos de seguridad: la seguridad de

los sistemas se ve comprometida de dos for-
mas como consecuencia del Spam. Por un lado
el Spam es utilizado para transmitir diferentes
formas de malware que se utilizan para gene-
rar ataques de distintas características sobre los
mismos sistemas, sobre usuarios y sobre insti-
tuciones o empresas.

• Errores de interoperabilidad: administrado-

res de sistemas y empresas pueden reaccio-
nar de forma errónea al problema del Spam,
y en el intento de encontrar una solución co-
menzar a utilizar técnicas no estandarizadas,
obstrusivas o muy agresivas que terminan
degradando el servicio e incomunicando
a los usuarios, de manera similar a como lo
hace el mismo Spam.
67
 5. Proyecto para mitigación del ‘Spam’:
red de sensores de INTECO

5.1. Introducción El Instituto Nacional de Tecnologías de la Comuni-

cación (INTECO, www.inteco.es), desde su Centro de
Respuesta a Incidentes de Seguridad en Tecnolo-
gías de la Información (TI) para Pymes y Ciudadanos
(INTECO-CERT, http://cert.inteco.es ), es responsable
del desarrollo de medidas preventivas y reactivas
ante incidencias de seguridad en los sistemas de
información.

En esta línea, uno de los objetivos a cubrir es la ob-

tención de indicadores de una de las amenazas de
seguridad con mayor problemática en materia de
correo seguro: el Spam, con gran evolución y creci-
miento desde 2006.

Por todo ello se ha desarrollado un sistema de son-

das con el objetivo de detectar, notificar y generar
estadísticas de Spam. Un sistema que permita vis-
lumbrar una panorámica general del estado del
Spam así como posible notificación de un listado
de direcciones IP sospechosas o comprometidas a
los responsables de las mismas. Este sistema puede
constituir un valioso mecanismo no solo para miti-
gar el Spam sino para conocer si las medidas que se
están adoptando a nivel institucional o privado son
eficaces.

Para la realización de este sistema de detección de

Spam ha sido necesaria la articulación de la Red de
Sensores de INTECO, basada en una serie de entida-
des colaboradoras distribuidas, desde las que se re-
coge la información necesaria mediante un proceso
automático que proviene de los servicios de correo,
y que posteriormente es procesada para la elabora-
ción de estadísticas concretas.

La explotación estadística de resultados del siste-

ma genera servicios de valor añadido para toda la

68
 comunidad y especialmente para las instituciones
participantes en la Red de Sensores.

Los sensores forman parte de una conjunto hetero-

géneo de organizaciones distribuidas principalmen-
te por todo el territorio nacional y pertenecientes a
distintos ámbitos de actuación (sector universitario
e investigación, administración - nacional, autonó-
mica, provincial y local -, proveedores de servicio de
correo electrónico, sector privado, etc…).

El objetivo fundamental en la captación o incorpo-

ración de nuevos miembros a esta Red, es la obten-
ción de un sistema de sondas lo más heterogéneo
posible con dispersión geográfica y sectorial, para
que constituya de forma fidedigna, una muestra re-
presentativa de la recepción de Spam en España.

5.2. Objetivos Los objetivos base del proyecto son la recogida de

datos y generación de estadísticas sobre detección
de Spam en España. Además con dicha Red de Sen-
sores se pretende alcanzar otros objetivos específi-
cos, entre los que destacan:

1. Disponer de información agrupada de los men-

sajes rechazados por la aplicación de medidas
antispam: Listas Negras, SPF (Sender Policy
Framework), filtros de contenido, resolución
inversa, etc.

2. Informar a las entidades colaboradoras de po-

sibles orígenes de Spam en sus redes.

3. Confeccionar mapas sobre el origen geográfi-

co del Spam y sobre las organizaciones impli-
cadas (consciente o inconscientemente) en su
transporte.

4. Crear un grupo de colaboradores cohesionado

que permita compartir experiencias y adoptar
medidas comunes frente al Spam.

69
 5. Ofrecer de forma individualizada (y preser-
vando la confidencialidad) informes sobre la
evolución temporal o tendencia del Spam en-
caminado por una organización concreta, para
estudiar la eficacia de las medidas adoptadas.
Adicionalmente permitir la comparativa de una
organización colaboradora, con el total de su
sector o de su región geográfica.

6. Compartir listados de direcciones IP emisoras

de Spam con aquellos CERTS o CSIRTS (Com-
puter Emergency Response Team, Computer
Security Incident Response Team) con compe-
tencias nacionales, para realizar acciones con-
juntas que mitiguen el envío de Spam en aque-
llas infraestructuras de su competencia.

7. Guiar los esfuerzos e iniciativas en materia de

campañas preventivas y de sensibilización de
aquellas entidades con competencias como
INTECO-CERT para informar debidamente del
buen uso del correo electrónico y de las ame-
nazas a las que está expuesto.

5.3. Funcionamiento Las organizaciones que forman parte de este pro-

del sistema yecto cuentan con uno o varios sensores en sus ser-
vidores de correo donde, a través de un programa
sonda (en código abierto) instalado en ellos, se re-
copila información sobre sus formas de clasificación
del correo no deseado o Spam.

En la información recogida de cada organización se

incluye:

• El sistema que emplea para detectar los mensa-

jes no deseados, destacando:

1. Métodos
por conexión: orígenes incluidos en
listas negras (RBL), sistemas de detección de
Spam o rechazo de mensajes cuyas direcciones
de origen no cumplen los estándares, usuario
destino inexistente, etc.
70
 2. Métodos por contenido: el contenido del
cuerpo y cabeceras del mensaje cumple unos
patrones que lo identifica como Spam.

Las políticas de detección de Spam podrán variar

significativamente de un sensor a otro:

• Cómo actúa contra los mensajes: rechazándo-

los, marcándolos, etc.

• El origen o procedencia de los mensajes.

• El número de mensajes que ha detectado den-

tro de la clasificación mencionada anterior-
mente.

• El número total de mensajes procesados por la

organización.

• La distribución horaria de los dos tipos de

mensajes, etc.

5.4. Resultados La información que se recibe y completa, se pue-

estadísticos de ver de forma gráfica y tabular en un portal web,
diseñado principalmente para la presentación de
estadísticas de forma visual e interactiva para el pú-
blico objetivo del portal.

A continuación se muestran las consideraciones que

se deben tener en cuenta sobre los datos mostrados
en el portal web y su interpretación. Y después se
detalla el contenido web de la sección de estadísti-
cas del portal.

Consideraciones sobre los datos recopilados

De los informes de los sensores, que se envían pe-

riódicamente, el servidor central obtiene, entre
otros datos, información asociada a las direcciones
IP por varios métodos:

• Ipwhois: que permite obtener información de

71
 la organización que tiene asignada la dirección
IP. Esta información es mantenida por los Regis-
tros Regionales de Internet.

• Resolución inversa de dominio: nombre de

dominio asignado a la dirección IP. No tiene por
qué existir, normalmente corresponde a la or-
ganización que utiliza la dirección IP.

• ASN (Autonomous System Number): datos del

sistema autónomo de Internet al que pertene-
ce la dirección IP. El ASN es utilizado para enca-
minar los datos por Internet y también ofrece
información sobre la organización responsable
de la dirección IP.

Actualmente, la mayor parte del Spam se envía

desde equipos comprometidos (bots) con puertas
traseras y otros troyanos, no desde las máquinas de
los “spammers”. Por tanto, estas estadísticas indican
más bien dónde se comprometen más máquinas
que dónde se genera exactamente.

Los criterios para filtrar Spam no son universales (no

todas las organizaciones utilizan los mismos crite-
rios), ni exactos (un mensaje de Spam puede no ser
detectado, y puede haber falsos positivos). Por tan-
to hay que considerar un cierto margen de error en
estas estadísticas.

Sobre la interpretación de las estadísticas :

• Muestreo estadístico: la información mostra-

da proviene de un muestreo de la información
que envían los sensores. Se ha analizado la dis-
tribución de direcciones IP que envían Spam y
se ha comprobado que:

• La mayoría de máquinas que envían correo,

envían en porcentajes muy altos o sólo correo
limpio o sólo Spam.

• La mayor parte del Spam se envía desde mu-

chas máquinas que envían pocos mensajes
72
 cada una. Esto refuerza la teoría de la utilización
de botnets.

Estos criterios son tenidos en cuenta en el algoritmo

de muestreo aleatorio.

• Fuentes de datos : las fuentes de los datos o

sensores, pueden tratar el Spam de formas dis-
tintas, lo cual introduce variaciones en los datos
que se envían a la Red de Sensores de INTECO.

• La mayoría de los servidores de correo tienen al

menos un filtro antispam y un antivirus. El filtro
antispam puede estar antes o después del an-
tivirus, lo cual hace variar el total de mensajes
procesados.

• No todas las organizaciones utilizan los mismos

criterios para filtrar el Spam. Por ejemplo, hay
algunas que rechazan todos los mensajes pro-
venientes de direcciones IP residenciales (como
ADSL), lo cual también puede filtrar mensajes
legítimos. Esto produce que distintas organiza-
ciones detecten cantidades de Spam distintas
en una misma muestra de correo.

• En general, los filtros antispam no son infalibles,

pueden dejar pasar mensajes claramente inde-
seados y dar falsos positivos. Esto introduce un
cierto error en todos los informes.

5.5. Contenido web El portal http://ersi.inteco.es se centra fundamen-

talmente en la sección que presenta las estadísticas
sobre el Spam, donde se muestran gráficas y tablas
con estadísticas de totales, evoluciones, comparati-
vas, etc., que se obtienen agregando los datos que se
reciben de los sensores mediante diferentes criterios.

En la página inicial de la sección de estadísticas de

Spam se muestra un mosaico de gráficas con un
resumen de las estadísticas. Seleccionando alguna
73
 de estas gráficas se accede a páginas con datos más
detallados de cada estadística.
Figura 10:
Vista Web
de Mosaico
de gráficas
estadísticas.

En las páginas de información detallada aparecen

una o más gráficas y una tabla en la parte inferior.
Tanto las tablas como las gráficas se pueden orde-
nar y filtrar en tiempo real, para extraer toda la infor-
mación posible contenida en la base de datos.

Figura 11:
Vista Web de
gráfica y tablas
detalladas de
estadísticas.

74
Las páginas con información detallada contienen
información agregada:

• Por países: muestra los datos acumulados de

mensajes procesados, detectados y rechaza-
dos procedentes de cada país durante un pe-
riodo de tiempo determinado. La información
del país se extrae del ipwhois.

• Por dominios: datos acumulados de mensajes

procesados, detectados y rechazados según la
resolución inversa de dominio de la dirección IP
durante un periodo de tiempo predeterminado.

• Por horas: mensajes procesados, detectados y

rechazados distribuidos a lo largo de las 24 ho-
ras del día. Permite ver a qué horas del día se
reciben más mensajes de correo no deseado.

• Por ipwhois: mensajes procesados, detectados

y rechazados según la organización que tiene
asignada la dirección IP. Esta información se
puede utilizar para mandar mensajes de aviso
o protesta a organizaciones en cuyas redes se
origina mucho Spam.

• Por ASN: mensajes procesados, detectados y recha-

zados según el ASN al que pertenece la dirección IP.
Esto da una idea de la carga a que son sometidas
diferentes secciones de Internet por el Spam.

• Totales: resúmenes de totales para un determi-

nado periodo de tiempo.

• Evolución temporal de totales: datos de men-

sajes procesados, detectados y rechazados a
lo largo de un periodo de tiempo dividido en
intervalos, en principio, de un día.

• Evolución temporal de MTAs: MTA, Mail Transfer

Agent, es cada ordenador distinto que envía co-
rreo electrónico detectado en la red de sensores.
Muestra MTAs totales y las que envían Spam (que
también pueden enviar mensajes “limpios”).
75
 • Por métodos: mensajes detectados y rechaza-
dos con distintos métodos antispam.

5.6. Futuro y evolución La evolución lógica de este proyecto una vez que ha
sido puesto en producción pasa por los siguientes
puntos principales:

1. Incrementar la implantación del script sonda en

un conjunto de organizaciones colaboradoras su-
ficientemente amplio y heterogéneo para que los
datos reflejados sean significativos y relevantes,
ofreciendo una imagen en tiempo real de lo que
está sucediendo con el correo basura. Se contem-
pla la posibilidad de incorporar instituciones u or-
ganizaciones de otros países.

2. Crear nuevas gráficas en el sitio web, que permi-

tan la explotación de la información almacenada
en el sistema, desde nuevos puntos de vista ami-
gables para el usuario.

3. Correlación de los datos de Spam con otros re-

positorios de seguridad, ofreciendo implicacio-
nes no detectadas hasta la fecha.

4. Interactuar con otros centros de seguridad para

realizar intercambios de información en materia
de seguridad informática, y ofrecer un frente co-
mún cohesionado en la lucha contra el correo
basura. En este sentido, el proyecto fue presen-
tado en la vigésima edición de FIRST (www.first.
org) celebrado en Vancouver en Junio 2008,
contando con un gran interés y respaldo de la
iniciativa por otros centros de seguridad interna-
cionales, estableciendo vías de cooperación en
la lucha contra el Spam.

76
6. Certificaciones de buenas prácticas
en el correo electrónico. RACE

6.1. Rediris (Red RedIRIS cuenta con unas 250 instituciones afiliadas,
académica de principalmente Universidades y Organismos Públi-
investigación cos de Investigación, que llegan a formar parte de
nacional) esta comunidad mediante la firma de un acuerdo
de afiliación.

Los servicios de comunicaciones que RedIRIS ofrece

a la comunidad académica y científica española, re-
quieren el soporte de una infraestructura básica de
transporte adaptada tecnológicamente a las nece-
sidades de los centros e instituciones usuarias. Estos
servicios se proporcionan además en colaboración
con otras redes académicas y foros internacionales.

RedIRIS es la Gran Instalación Telemática del Plan Nacional de I+D+i,

creada para potenciar los resultados de la investigación española.

• Es una Red de datos para facili-

tar el desarrollo científico.
• Es una herramienta de colabo-
ración para los investigadores.
• Es un elemento básico para ex-
perimentos científicos.
• Es un banco de pruebas de nue-
vas tecnologías y servicios.
• Es un elemento de ciertos ins-
trumentos científicos.
• Es una ayuda para impulsar la
Sociedad de la Información.

Financiada por la Secretaría General

de Política Científica y Tecnológica
del Ministerio de Educación y Cien-
cia. Gestionada desde la Entidad Pú-
blica Empresarial Red.es del Ministe-
rio de Industria Turismo y Comercio

77
 6.2. Red Avanzada de RACE es un servicio de RedIRIS creado para conseguir
Calidad en el correo mejorar la calidad de los servidores de correo insta-
Electrónico (RACEv2) lados en la comunidad RedIRIS. RACE por un lado
define una relación de criterios y normas acerca de
la correcta configuración de los servidores de correo
electrónico y por otro lleva acabo actividades de au-
ditorías para comprobar el cumplimiento de dichos
criterios. Se prevé la disponibilidad de una aplicación
web (evaluador) que automatice las tareas de vali-
dación de cada criterio para las organizaciones que
deseen ser auditadas.

El documento de buenas prácticas RACEv2 tiene

como objetivo exponer las mejores recomendacio-
nes para diseñar, configurar y gestionar un servicio
de correo electrónico desde el punto de vista de la
excelencia en la calidad del servicio ofrecido tanto
a usuarios locales de una organización, como al res-
to de entidades con las que se intercambia tráfico
SMTP.

Las recomendaciones RACEv2 se estructuran en cri-

terios de calidad, clasificados según su ámbito de
aplicación y asignados a diferentes niveles, que per-
mitirán medir la calidad cuantitativa del Servicio de
Correo Electrónico de una organización, y promover
la mejora del mismo. Las recomendaciones indicadas
en el documento cumplen escrupulosamente el con-
tenido de los diferentes estándares de Internet (RFCs)
relacionados con SMTP y otros protocolos.

6.3. Criterios técnicos RACEv2 han clasificado los criterios (y por ende sus
RACEv2 recomendaciones asociadas) según su ámbito de
aplicación:

1. Criterios de enrutamiento SMTP: afectan al en-

rutamiento de correo.
• Reglas anti-relay
• Política de logs (trazas)
• Resolución inversa de MTAs
• Número máximo de destinatarios
• Control de acceso al puerto 25 en entrada/salida
78
• Tamaño máximo de mensaje
• Definición de registros SPF (Sender Policy Fra-
mework)
• Uso de Lista Blanca de RedIRIS
• Chequeo de SPF en correo entrante
• Control de destinatarios
• Control de flujo SMTP

2. Criterios de infraestructuras: definen los recur-

sos necesarios para dar soporte a un servicio de
correo electrónico de calidad.

• Sincronización NTP
• Alta disponibilidad

3. Criterios de autenticación y cifrado.

• Autenticación centralizada
• Acceso externo cifrado
• Servicio SUBMISSION
• Cifrado MTAi-MTAi
• Cifrado MTA-MTA

4. Criterios de Servicios: servicios básicos y de va-

lor añadido.

• Disponibilidad de abuse@ y postmaster@

• Documento descriptivo del Servicio
• Servicio de antivirus
• Acceso remoto por WebMail y otros
• Política de backup (buzones)
• Servicio de cambio de contraseña
• Servicio antispam
• Servicio antispam personalizado
• Servicio de respuesta automática por ausencia
prolongada
• Redirección de cuentas
• Servicio de listas de distribución

5. Criterios generales: otro tipo de criterios que no

encajan en las clases anteriores.

• Estadísticas

79
 Cada uno de estos criterios dispone de una pun-
tuación que permitirá disponer de una baremación
cuantitativa tal como se describe en el siguiente
apartado. Todos los criterios son revisados periódica-
mente por un comité para adecuarlos a la evolución
tecnológico del entorno SMTP.

6.4. Sistema de La evaluación de una organización con los criterios

evaluación RACEv2 permite disponer de unos datos cuantita-
tivos y cualitativos de la calidad del servicio. Actual-
mente (Septiembre 2008) la evaluación se realiza por
un equipo de personas y se está desarrollando una
evaluación automática online. Se han definido 5 cri-
terios imprescindibles y obligado cumplimiento se-
gún lo establecido en los RFCs y legislación española
que son:

• Criterio 1: reglas anti-relay

• Criterio 2: política de trazas (logs)
• Criterio 3: resolución inversa de MTAs
• Criterio 4: control de destinatarios
• Criterio 19: disponibilidad de direcciones abu-
se@ y postmaster@

Si estos sencillos criterios son cumplidos, el provee-

dor podrá seleccionar en el formulario los criterios
que considera que cumple, para ser evaluados por
RACEv2. Dado que cada criterio dispone de una pun-
tuación, la suma de los puntos de todos los criterios
superados corresponderá a uno de los 3 niveles exis-
tentes según los siguientes baremos:

• Nivel imprescindible: 500 puntos

• Nivel 1: 501- 800 puntos
• Nivel 2: 801-1600 puntos
• Nivel 3: 1601-2240 puntos

Más información sobre RACE puede consultarse en

http://rediris.es/racev2

80
7. La ley de Servicios de la Sociedad de la Información
y Comercio Electrónico: regulación del envío de
comunicaciones comerciales electrónicas o ‘Spam’

Concepto y requisitos del Spam

Como punto de partida inicial, el Spam o ‘correo ba-

sura’ (en su acepción española) puede definirse como
“cualquier tipo de comunicación no solicitada remiti-
da por vía electrónica”.

Esta definición incorpora los diferentes requisitos

que necesariamente deben confluir en una comuni-
cación para que pueda ser identificada como Spam,
que precisamos seguidamente:

• Comunicación. Estamos partiendo de la base

que el Spam pretende y tiene como finalidad
que un ‘mensaje’ de un remitente llegue a un
destinatario identificado.

• No solicitada. Para considerarlo Spam, dichos

destinatarios reciben la referida comunicación
sin haberla solicitado. No se entra a valorar si,
una vez recibida, el ‘mensaje’ es de su interés,
sino el hecho de que cuando se envía, no media
la previa solicitud o consentimiento para que se
dirija a su correo.

• Vía electrónica. En último de los elementos

esenciales es que dicha comunicación se reciba
por vía electrónica, es decir, que el destinatario
disponga de sistema electrónico donde el ‘men-
saje’se recibe. Será por ello, la dirección de correo
electrónico, un teléfono móvil o elemento simi-
lar, lo que sirva para identificar al destinatario.

Debe tenerse en cuenta que existen algunos aspec-

tos que no identifican a una comunicación como
Spam, mientras no concurran los tres requisitos pre-
viamente mencionados. Dichos aspectos son:

81
 • Contenido comercial. El uso de esta técnica es
una práctica muy extendida en el ámbito comer-
cial, pero no se requiere que la comunicación ne-
cesariamente ofrezca algún producto o servicio
concreto. De hecho, cada vez más pueden iden-
tificarse envíos no solicitados de índole política,
religiosa o difamatoria.

• Multitudinario. Con esta característica, se iden-

tifica que la comunicación se remita al máximo
número de destinatarios posible, tal y como nos
hemos referido arriba. Pero la realidad es que tan
Spam es una comunicación a un único destina-
tario como la que se dirige a toda una lista de
distribución recopilada por parte del emisor.

A la hora de estudiar el Spam, podemos realizarlo

desde dos perspectivas diferentes, por un lado des-
de una perspectiva comercial y por otro desde una
perspectiva técnica como ataque a la seguridad de
los sistemas del destinatario. Respecto de la perspec-
tiva técnica, la regulación no es un medio práctico
para dar soluciones a los problemas que el Spam, ya
que el remitente buscará la forma en la que evitar ser
identificado, lo que no ocurre cuando tiene el interés
comercial de la primera perspectiva.

Así, desde una perspectiva comercial, donde el re-

mitente está interesado en ser identificado, a fin de
que el destinatario acceda a su oferta comercial, las
obligaciones jurídicas que se imponen con carácter
previo al comerciante, toman un papel más que re-
levante a la hora de garantizar el envío licito de co-
municaciones comerciales electrónicas. Es por ello,
que seguidamente, se analiza la normativa que es de
aplicación a las comunicaciones comerciales por vía
electrónica.

Normativa aplicable

La normativa existente aplicable al Spam a día de hoy

hace referencia de forma expresa a las comunicacio-
nes no solicitadas cuando dichas comunicaciones
82
se realizan (i) por vía electrónica y (ii) tienen carácter
comercial.

Por otro lado es necesario referirse al ámbito terri-

torial de aplicación de dicha normativa, la cual des-
afortunadamente se circunscribe a la Unión Europea,
ante la falta de una regulación de ámbito territorial
superior, pese a que en la práctica el envío de comu-
nicaciones comerciales electrónicas tienen un alcan-
ce supra comunitario.

En el ámbito Comunitario, son dos las normas esen-

ciales en lo que se refiere al Spam:

• A nivel comunitario, la Directiva 2000/31/CE,

del Parlamento Europeo y del Consejo, de 8 de
junio de 2000, relativa a determinados aspectos
jurídicos de los servicios de la sociedad de la in-
formación, en particular el comercio electrónico
en el mercado interior (Directiva sobre el comer-
cio electrónico, DCE).

• En el ámbito nacional, y como transposición de

la referida Directiva 2000/31/CE, se encuentra
la Ley 34/2002, de 11 de julio, de servicios de la
sociedad de la información y de comercio elec-
trónico (LSSICE).

La DCE estableció en sus artículos 6 y siguientes los

requisitos mínimos de las comunicaciones comercia-
les no solicitadas por vía electrónica, haciendo hin-
capié en aspectos como la información que necesa-
riamente debe contener la comunicación comercial,
el establecimiento de listas de exclusión voluntaria
de este tipo de comunicaciones y las especialidades
cuando dichas comunicaciones comerciales son en-
viadas por un miembro de una profesión regulada.

Con la trasposición de la DCE a través de la LSSICE se

establecen e identifican en España las obligaciones
que deben cumplirse para poder remitir de forma lí-
cita comunicaciones comerciales por vía electrónica.

Así, la LSSICE, a partir de las sucesivas modificaciones

83
 operadas por la Ley General de Telecomunicaciones
(Ley 32/2003, de 3 noviembre), la Ley de Firma Elec-
trónica (Ley 59/2003, de 19 de diciembre) y la más
reciente Ley de Medidas de Impulso de la Sociedad
de la Información (Ley 56/2007, de 28 de diciembre),
se establecen las siguientes obligaciones en lo que se
refiere específicamente para el envío de comunica-
ciones electrónicas:

a) Deberán ser claramente identificables como co-

municaciones comerciales, además de identificar a la
persona - física o jurídica – en nombre de la cual se
envían. (Art. 20.1.1 LSSICE).

b) En los supuestos de remitir la comunicación a través

de correo electrónico o medio de comunicación elec-
trónica equivalente (como por ejemplo, un mensaje
corto al teléfono móvil), incluirán la mención “publici-
dad” o “publi” al inicio del mensaje. (Art. 20.1.2 LSSICE).

c) La LSSICE distingue dos situaciones respecto de los

sujetos intervinientes en la comunicación comercial,
dependiendo de si existe una relación previa entre
ellos o no.

Cuando dicha relación previa no existe, se prohíbe

el envío de comunicaciones comerciales que previa-
mente no hayan sido solicitadas o expresamente auto-
rizadas por el destinatario. (Art. 21.1 LSSICE).

En ambos casos, tanto para la respuesta a una solicitud

como para la expresa autorización, el remitente debe-
rá velar por la conservación de los medios de prueba
necesarios que acrediten la autorización al envío de di-
chas comunicaciones comerciales, a fin de evitar posi-
bles sanciones económicas en supuestos de denuncia
de particulares por el envío de comunicaciones comer-
ciales no solicitadas. A estos efectos, la normativa de
aplicación establece la libertad de forma para acreditar
dichos extremos, siendo fundamental que el procedi-
miento utilizado para dicha acreditación demuestre
fehacientemente que la autorización ha sido realizada
por el destinatario de la comunicación.

84
En concreto, para el supuesto de la autorización, ésta
deberá tener las siguientes condiciones:

• Debe ser previa al envío mismo de la comunica-

ción.

• Debe ser expresa. El destinatario debe realizar

una manifestación positiva para poder entender
que se otorga la autorización. En otras palabras,
una autorización basada en la no oposición del
destinatario al envío no sería válido, siendo ne-
cesario un acto expreso de manifestación de la
voluntad del destinarlo autorizando el envío.
Un sistema válido comúnmente utilizado para
el cumplimiento de esta condición es el deno-
minado sistema de casillas “opt-in”, mediante
ventanas en las páginas web donde registrar los
datos de los destinatarios.

Una de las principales dificultades para la obtención

del destinatario es la necesidad de su acreditación en
un momento posterior, si fuera necesario justificar el
motivo del envío de la referida comunicación. Recor-
demos que, en este caso, estamos ante la necesidad
de recabar un consentimiento cualificado, ya que la
norma que lo regula establece que la autorización
deberá ser expresa (Art. 21.1 LSSICE).

Por ello, el remitente podrá plantearse dos vías para el

cumplimiento de este extremo, a saber:

a) De forma que el destinatario manifieste de forma

expresa su consentimiento para recibir la comunica-
ción comercial por vía electrónica. Dentro de esta vía,
que podemos denominar directa, encajan procedi-
mientos como la utilización de un formulario en pa-
pel que rellene y firme el destinatario, una respuesta
directa al email de solicitud enviado.

Aunque más seguro, no está exento de dificultades

en la acreditación cuando por ejemplo, las comuni-
caciones van dirigidas a un correo electrónico ‘corpo-
rativo’. En este caso, dicho correo electrónico puede
cambiar de usuario a lo largo del tiempo en que esté
85
 activo, y debemos hacer reseña que en materia de
protección de datos, el consentimiento debe darlo
el usuario: si éste cambia el consentimiento deja de
estar vigente.

b) Otra forma de obtenerlo es mediante la implanta-

ción de un procedimiento cuyo seguimiento por par-
te del futuro destinatario de la comunicación comer-
cial por vía electrónica implica la voluntad de aceptar
la recepción de la misma. Es la vía indirecta.

Este tipo de procedimientos son más ágiles en la

forma de recabar el consentimiento del destinatario,
al tener la posibilidad de sistematizarse. Es muy ha-
bitual su uso en los formularios habilitados en pági-
nas web para la recogida de datos personales de sus
usuarios, donde a través de casillas, ventanas emer-
gentes o pasos intermedios, el usuario, debe aceptar
la recepción de este tipo de comunicaciones.

La dificultad en este caso es la de acreditar que dicho

procedimiento está operativo y realmente cumple:
se ha configurado de modo que ese acto de volun-
tad del usuario se dirija a otorgar su consentimiento.
Una solución para esta dificultad, podría pasar por la
realización de un acta de manifestación notarial por
la que se acredite la forma en la que se establece el
mencionado procedimiento.

Como excepción a esta prohibición expresa, la LS-

SICE (primer párrafo Art. 21.2) permite el envío de
estas comunicaciones si previamente existe entre el
remitente y el destinatario una relación contractual
previa, que le haya permitido al primero recabar líci-
tamente los datos del destinatario y los utilizara para
realizar una oferta comercial de productos y servicios
en las siguientes condiciones:

• En primer lugar, que sean productos y servicios

propios del remitente. Esto implica que la excep-
ción no operará respecto de oferta comercial de
terceras entidades que no sean el referido remi-
tente, ni siquiera entidades que formen parte
del mismo Grupo de Empresas.
86
• En segundo lugar, que sean similares a los que
inicialmente contratara el destinatario. Esta
condición previene que si el objeto social del
remitente es lo suficientemente variado, pero
el destinatario-cliente únicamente lo es por uno
de ellos, no reciba más publicidad por esta vía
que la que previamente haya contratado.

c) El remitente deberá ofrecer al destinatario la posi-

bilidad de oponerse al tratamiento de sus datos con
fines promocionales mediante un procedimiento
sencillo y gratuito. Dicha obligación se mantendrá vi-
gente para todas las comunicaciones que se dirijan al
destinatario, incluso en la primera. (segundo párrafo
Art. 21.2 LSSICE).

Por otra parte, el medio a través del cual el destinata-

rio podrá oponerse al tratamiento o revocar su con-
sentimiento previamente otorgado, deberá:

• Ser accesible en cualquier momento.

• Ser sencillo.
• Ser gratuito.

Por ello, podrán utilizarse sistemas como la activa-

ción de pestañas en formularios, incorporación de
hipervínculos o la posibilidad de responder al propio
email. No valdrán, por el contrario, sistemas para los
que haya que pagar un importe superior al de una
llamada telefónica ordinaria como sucedería con un
número de tarificación adicional.

Como hemos visto arriba, uno de los medios para

poder remitir comunicaciones comerciales por vía
electrónica, es a partir de la previa obtención del con-
sentimiento del destinatario.

Sanciones en materia de la LSSI

Ante el incumplimiento de las obligaciones estable-

cidas en el punto anterior para el envío de comuni-
caciones comerciales por vía electrónica, el remitente
puede llegar a ser sancionado por el organismo esta-
tal correspondiente.
87
 La LSSICE establece en las letras c) y d) del apartado
4º del artículo 38, respecto de los hechos considera-
dos como infracciones leves, lo siguiente:

“c) El incumplimiento de lo previsto en el artículo 20

para las comunicaciones comerciales, ofertas promo-
cionales y concursos.”

“d) El envío de comunicaciones comerciales por co-

rreo electrónico u otro medio de comunicación elec-
trónica equivalente cuando en dichos envíos no se
cumplan los requisitos establecidos en el artículo 21
y no constituya infracción grave.”

Por ello, el incumplimiento de las obligaciones res-

pecto del envío de este tipo de comunicaciones que
se ha identificado arriba, encajarán dentro de las in-
fracciones leves en los siguientes casos:

• No identificar la comunicación electrónica como

comunicación comercial.

• No identificar al comerciante que la remite.

• No incluir la leyenda “PUBLICIDAD” ó ”PUBLI” en

la comunicación.

• El envío de hasta dos comunicaciones comercia-

les electrónicas no solicitadas.

Además, entre las infracciones graves, se identifica la

establecida en la letra c) del apartado 3º del artículo
38 de la LSSICE:

“c) El envío masivo de comunicaciones comerciales

por correo electrónico u otro medio de comunicación
electrónica equivalente o el envío, en el plazo de un
año, de más de tres comunicaciones comerciales por
los medios aludidos a un mismo destinatario, cuando
en dichos envíos no se cumplan los requisitos esta-
blecidos en el artículo 21.”

Las sanciones por las infracciones identificadas tam-

bién se establecen en la LSSICE, en su artículo 39, que
88
impone por la comisión de una infracción leve una
multa que podrá alcanzar los 30.000 €, mientras que si
la infracción es grave, la multa oscilará entre 30.000 € y
150.000 €

Vulneración de la normativa de protección de datos

La Ley 34/2002, de 11 de julio, de Servicios de la

Sociedad de la Información, al regular el régimen
jurídico de las comunicaciones comerciales por vía
electrónica, ya advierte que les será directamente
de aplicación la Ley Orgánica de Protección de Da-
tos de Carácter Personal y su normativa de desarro-
llo, en especial en lo que se refiere a la obtención de
datos personales, información a los interesados y la
creación y mantenimiento de ficheros de datos de
carácter personal.

Lo establecido en esta norma debe de alertarnos so-

bre el hecho de que el envío de comunicaciones co-
merciales no solicitadas que se efectúa conculcando
lo establecido en la LSSI puede suponer además una
vulneración del derecho a la intimidad y el incum-
plimiento de la legislación en materia de protección
de datos. Debe de tenerse en cuenta en este sentido
que la Agencia Española de Protección de Datos ha
sido muy clara al sostener que una dirección de co-
rreo electrónico puede ser considerada como dato
de carácter personal.

No obstante debemos de tener en cuenta que el Real

Decreto 1720/2007, de 21 de diciembre, por el que
se aprueba el Reglamento de desarrollo de la Ley Or-
gánica de protección de datos de carácter personal
introduce una importante modificación en el ámbito
objetivo de aplicación de la Ley al establecer en su ar-
tículo 2,2 que quedarán fuera de él los datos referidos
a personas jurídicas y los ficheros que se limiten a in-
corporar los datos de las personas físicas que presten
sus servicios en aquellas, consistentes en su nombre
y apellidos, las funciones o puestos desempeñados,
así como la dirección postal o electrónica, teléfono y
número de fax profesionales, siempre y cuando estos
datos se utilicen con una finalidad empresarial.
89
 Esta limitación en el ámbito de aplicación de la LOPD
supone, sin duda, una flexibilización en cuanto al tra-
tamiento de datos de estas personas de contacto en
empresas clientes o proveedoras siempre y cuando,
debemos insistir en esto, los datos que se recaben no
excedan de los indicados y se utilicen con una fina-
lidad estrictamente empresarial, pero, en modo al-
guno, habilita a la utilización indiscriminada de estas
cuentas de correo, números de teléfono o fax para el
envío de comunicaciones comerciales no deseadas.

Papel de la Agencia Española de Protección de Datos

El órgano encargado de velar por el cumplimiento de

la referida normativa es la Agencia Española de Protec-
ción de datos, la cual ha visto ampliadas sus compe-
tencias con la entrada en vigor de la Ley 32/2003, de 3
de noviembre, General de Telecomunicaciones y la Ley
34/2002, de 11 de julio, de Servicios de la Sociedad de
la Información. En virtud de estas normas la Agencia
ha pasado a tener un papel muy activo en la lucha con-
tra el Spam al convertirse en el órgano encargado de
la imposición de sanciones en el caso de infracciones
derivadas del envío de comunicaciones comerciales
no solicitadas realizadas a través de correo electrónico
o medios de comunicación electrónica equivalente
conculcando lo establecido en la LSSI.

90
8. Conclusiones Los spammers cuentan con recursos, tanto econó-
micos como de conocimiento, más que suficientes
para seguir inundando Internet con sus correos e in-
tentando llegar a los potenciales clientes. Intentan
ataques rápidos que pueden alargarse en el tiempo
dependiendo de su efectividad, mutando cuando
el porcentaje de penetración no es suficientemente
bueno. Mediante el uso de botnets la capacidad de
procesamiento de la que disponen es prácticamen-
te ilimitada y su coste es mínimo.

Cuanto más Spam exista en la red (en los últimos

años se ha ido duplicando anualmente) mejor tiene
que ser el filtro de protección. Ya no es suficiente un
antispam que filtre el 90% del correo, ya que esto
puede significar recibir, por ejemplo, 20 correos
Spam diarios y en conclusión, lo que cuenta es la
molestia que percibe el cliente, no los porcentajes
de funcionamiento.

Recordemos que el Spam se basa en la ingeniería

social, un simple correo Spam con unas pocas pa-
labras y una URL a una web comprometida puede
ser el primer paso para tomar el control de toda una
red.

La lucha contra el Spam es, sin duda, una batalla a

largo plazo donde el éxito de un antispam es efímero
y requiere de un trabajo constante ya que sabemos
que los ataques se modificarán para intentar eludir
los sistemas de protección. Dicha batalla se ganará
únicamente cuando los usuarios dejen de comprar
productos anunciados a través de mensajes Spam.

En cualquier caso, existen unos sencillos consejos

que pueden ayudar a cualquier empresa a minimi-
zar los problemas relacionados con el Spam :

1. Mantener permanentemente actualizados los

ordenadores, tanto sus sistemas operativos
como aplicaciones y sistemas antivirus.

2. Usar un antispam capaz de contrarrestar al

91
 máximo los ataques de los spammers y que ga-
rantice las actualizaciones necesarias para ello.

3. Formación a los usuarios:

a. Desconfiar de los correos que prometen grandes
beneficios.

b. No responder nunca a un correo electrónico no

deseado, no visitar nunca direcciones web recibidas
o incluidas en correos electrónicos de incierta pro-
cedencia.

c. Si se recibe un aviso para ser dado de baja de una

lista de distribución, en la cual no se ha inscrito, no
responder a dicha comunicación.

d. Utilizar la copia ciega (Cc) al enviar un correo a

una lista de direcciones.

e. Mantener siempre activas las herramientas de fil-

tro antispam.

f. No publicitar la cuenta de correo de manera direc-

ta en Internet.

g. Utilizar varias cuentas de correo electrónico y

emplearlas en el entorno adecuado (laboral, perso-
nal…).

h. Para las cuentas de correo utilizar nombres que

sean poco identificables.

Siguiendo estas sencillas reglas podemos conseguir

que el Spam sea un problema bajo control.

92