Efectivamente, el método ideal (y creo que lo menciono en algún lado) es no permitir que llegue el comentario a la base de datos. Ya que, en el método expuesto, aunque no se logra el objetivo del spam (publicidad gratuita para el anunciante), sigue perjudicando al servidor (cargando al mismo al usar la base de datos).
El por qué se ha implementado de una forma y no de la otra es por motivos de sencillez. El filtrado antes de la inclusión del spam en la base de datos requiere una de las siguientes opciones:
Añadir en el código de drupal (el gestor de contenidos que se usa aquí) los if correspondientes a palabras prohibidas
Usar un módulo anti spam de los que ya existen
Elaborar un módulo ligero y específico de filtrado
El primer caso es sencillo de implementar y una pesadilla de mantener. Ya he cometido antes el error de tocar código de drupal y cuando llega una actualización de seguridad hay que mirar línea a línea que se actualiza para ver si tu código tendrá interferencias de la actualización. El segundo caso funciona pero los módulos que he visto son muy buenos y hacen muchas cosas y un objetivo importante en el mantenimiento de este servidor es reducir la carga en lo máximo posible, por tanto esos módulos no se usarán en tanto soluciones ad hoc funcionen con menos requisitos. Y nos queda la tercera opción: para hacer un módulo (pasatiempo que también he practicado una vez), hay que mantener un interface determinado para comunicarlo con el core. Módulos de pequeñas líneas de código efectivo se convierten en cientos de líneas y ponerme a recordar los intringulis de la programación para drupal.
Por todas estas razones, se optó por una solución menos efectiva pero igualmente menos intrusiva con respecto a drupal y de fácil mantenimiento. En el caso de una carga masiva del sistema o de ataques de spam más inteligentes que no se detecten y eliminen adecuadamente se tendrá que reelaborar la estrategia a seguir, (que posiblemente sea buscar un módulo ya programado que haga la tarea).
No es bueno tocar un código que tu no mantienes
Efectivamente, el método ideal (y creo que lo menciono en algún lado) es no permitir que llegue el comentario a la base de datos. Ya que, en el método expuesto, aunque no se logra el objetivo del spam (publicidad gratuita para el anunciante), sigue perjudicando al servidor (cargando al mismo al usar la base de datos).
El por qué se ha implementado de una forma y no de la otra es por motivos de sencillez. El filtrado antes de la inclusión del spam en la base de datos requiere una de las siguientes opciones:
El primer caso es sencillo de implementar y una pesadilla de mantener. Ya he cometido antes el error de tocar código de drupal y cuando llega una actualización de seguridad hay que mirar línea a línea que se actualiza para ver si tu código tendrá interferencias de la actualización. El segundo caso funciona pero los módulos que he visto son muy buenos y hacen muchas cosas y un objetivo importante en el mantenimiento de este servidor es reducir la carga en lo máximo posible, por tanto esos módulos no se usarán en tanto soluciones ad hoc funcionen con menos requisitos. Y nos queda la tercera opción: para hacer un módulo (pasatiempo que también he practicado una vez), hay que mantener un interface determinado para comunicarlo con el core. Módulos de pequeñas líneas de código efectivo se convierten en cientos de líneas y ponerme a recordar los intringulis de la programación para drupal.
Por todas estas razones, se optó por una solución menos efectiva pero igualmente menos intrusiva con respecto a drupal y de fácil mantenimiento. En el caso de una carga masiva del sistema o de ataques de spam más inteligentes que no se detecten y eliminen adecuadamente se tendrá que reelaborar la estrategia a seguir, (que posiblemente sea buscar un módulo ya programado que haga la tarea).