A modo de resumen, cabrían resaltar los siguientes topics:

- 179 billones de mensajes de spam/phishing diarios
- 82% del tráfico en este Q2 es spam, con un pico del 92% en Junio
- Dominios más usados en el FROM por spammers: gmail.com, hipenhot.nl, yahoo.com, 123greetings.com, hotmail.com…
- La mayoría de la “temática” del spam sigue siendo productos farmacéuticos (64%)
- 307.000 nuevos zombies activos diarios
- India, Brasil , Vietnam y Alemania son los países con más PCs zombies

Como siempre, buen trabajo estadístico por parte de Commtouch!

Dicho módulo comenzó con estas transparencias introductorias en las que se da un repaso a todo lo que engloba el servicio de correo electrónico, como son los protocolos y RFCs, MTAs, el problema del spam, botnets, phishing, diversas técnicas antispam, filtrado por contenidos, pasarelas de correo…etc.

Espero que os resulte interesante ;-)

El anuncio completo en la lista de ClamAV.

A más de uno le pillará el toro, seguro ;-)

Puedes descargarlas aquí: Transparencias FBL-ARF.

[+] Día 5 de Mayo

10.00-10.30h Sesión1 (mañana):Recepción y Bienvenida

ECO: Assciation of the German Internet Industry.
A cargo de: Sascha Wilms, Project Manager de ECO y CSA (Certified Sender Alliance) (La charla es en castellano)

* Introducción de ECO
* Actividades anti-abuse y anti-spam
* CSA Whitelist en sender++

FBLs (FeedBack Loops)y ARF (Abusing Reporting Format)

* Introducción. Alvaro Marin (Hostalia)
* Experiencias. Juan MIguel Morillas. (Telefonica España)
* Debate y propuestas

16.00-17.00h Sesión2 (tarde): Intercambio de experiencias entre miembros del Foro

* Experiencias con Conficker. Antonio Javier García Martinez. Seguridad Operaciones Telefónica (Seguridad Operaciones)

* Mundo-R: Experiencias sobre el control del puerto 25/SMTP
* Genetsis
* Vodafone

17.00-18.00h Propuesta compartir rangos IPs dinámicas

[+] Día 6 de Mayo

10.00-11.30h Sesión3 (mañana): Asuntos internos Foro ABUSES

Concurso de experiencias y buenas practicas en la gestión de incidentes abuse

13.00-13.30h Sesión final: Conclusiones y próxima reunión

Veremos qué da de sí :-)

Las transparencias en cuestión:

http://www.alvaromarin.com/wp-content/uploads/2009/04/Maawg-04.pdf

Espero que os gusten, a pesar de lo escuetas que son O:-)

Esta nueva versión trae bastantes novedades que se pueden ver en la lista de correo de ClamAV announce, comentadas por Luca Gibelli.

Entre ellas, destaca una nueva herramienta llamada clamdtop que permite monitorizar qué está haciendo el demonio clamd en cada momento. Dejo un pantallazo de su aspecto ejecutándose en un servidor en el que he instalado esta nueva versión:

14/12/08

Esperemos que sea verdad que a principios de año vuelven… :-/

Un par de cosas interesantes respecto al correo electrónico que aparecen en este panel:

[-] qmail-spp in plesk does not set SMTPAUTHUSER and SMTPAUTHMETHOD variables bug is fixed.

Como ya comentaba en otros posts, el qmail de Plesk no declaraba las variables SMTPAUTHUSER y SMTPAUTHMETHOD, por lo que no se podía comprobar si el usuario estaba autenticado desde un plugin con SPP, por ejemplo. Esto parece que ha sido arreglado en esta versión, después de darles mucho la “chapa” al respecto.

[+] Soporte para Postfix

En efecto, era una de las “features” más pedida en los foros de Plesk, y parece que han hecho caso :-)
No he tenido tiempo aún para ver cómo funciona, pero no parece estar muy tuneado por defecto:

# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases, hash:/var/spool/postfix/plesk/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
html_directory = no
inet_interfaces = all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 10240000
mydestination = localhost.$mydomain, localhost, localhost.localdomain
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
sample_directory = /usr/share/doc/postfix-2.3.3/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_send_xforward_command = yes
smtp_use_tls = yes
smtpd_authorized_xforward_hosts = 127.0.0.0/8
smtpd_client_restrictions = reject_rbl_client
smtpd_recipient_restrictions = permit_mynetworks,
 permit_sasl_authenticated, reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sender_restrictions =
 check_sender_access hash:/var/spool/postfix/plesk/blacklists
smtpd_tls_cert_file = /etc/postfix/postfix_default.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_tls_security_level = may
smtpd_use_tls = yes
transport_maps = hash:/var/spool/postfix/plesk/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = $virtual_maps,
 hash:/var/spool/postfix/plesk/virtual
virtual_gid_maps = static:31
virtual_mailbox_base = /var/qmail/mailnames
virtual_mailbox_domains = $virtual_mailbox_maps,
 hash:/var/spool/postfix/plesk/virtual_domains
virtual_mailbox_maps = hash:/var/spool/postfix/plesk/vmailbox
virtual_transport = plesk_virtual
virtual_uid_maps = static:110

Sí que es interesante que desde el panel de control se puede habilitar el puerto de Submission (TCP:587) para el envío de correo, lo que añade al master.cf:

submission inet n - - - - smtpd
 -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
 -o smtpd_client_restrictions=permit_sasl_authenticated,reject

Habrá que ir probándolo y viendo cómo funciona, pero desde luego, un punto para Plesk por haber dado la opción a Postfix (Qmail sigue estando disponible e instalable en Plesk 9) como MTA :-)

Leyendo el blog de MailChannels, que compara dichos RFCs, se aprecian los siguientes cambios:

• RFC 5322 (Internet Message Format)

- Especificación de qué puede contener una cabecera de un mensaje SMTP y qué no.

- Se recomienda que la parte de dominio de una dirección de email, sea un dominio legítimo en el ámbito o contexto en el que ese mensaje se esté tratando.

- No es posible el uso de texto entrecomillado en la cabecera Message-ID.

- La definición de la cabecera Received pasa a estar en el RFC 5321.

• RFC 5321 (SMTP)

- Actualizaciones y aclaraciones sobre textos ya existentes en el RFC 2821, dejando partes de él obsoletas.

- Recomendación del uso del puerto 587 (Submission – RFC 4409) en algunas configuraciones en vez de el uso del de SMTP para el envío de correo.

- Los comandos “MAIL FROM” y “RCPT TO” ya no pueden contener detrás un espacio.

- Mención de la existencia de SPF y DKIM para la comprobación del remitente.

- Posibilidad de desconectar a un cliente SMTP tras un timeout.

- Códigos 100 de respuesta eliminados del estándar por su falta de uso.

- Posibilidad de responder con un código 550 después del comando DATA (para filtros antispam “inline”, por ejemplo).

- Mención a la existencia de IPv6 pero sin ser un requerimiento.

- Los bounces ante abusos, ataques…etc solamente deberán ser enviados si se tiene constancia de que van a ser últiles en el origen (por ejemplo, no tiene sentido enviar bounces al origen ante detecciones de virus o spam en mensajes, ya que suelen ser falsificados en su totalidad).

- Posibilidad de rechazar con mensajes 550 (por ejemplo) a emisores que cometan abusos (muchos RCPTs inválidos, por ejemplo).

No hay grandes cambios ni medidas drásticas pero parece que los RFCs se adaptan a las necesidades que van surgiendo por el aumento del spam.