Como luchar contra el SPAM en Plesk con Qmail

Primero compruebe que todos los dominios tienen la opción ‘Correo para usuario inexistente’ definida a ‘Rechazar’ pero no a reenviar. Puede cambiar este ajuste para todos los dominios usando “Operaciones en Grupo” en la página “Dominios” del CP de Parallels Plesk Panel. La prestación ‘Rechazar correo para usuario inexistente’ está disponible a partir de Parallels Plesk Panel 7.5.3.

Asimismo, compruebe que todas las redes e IPs incluidas en la lista blanca son de su confianza.

Compruebe cuántos mensajes hay en la cola de Qmail con:

# /var/qmail/bin/qmail-qstat
messages in queue: 27645
messages in queue but not yet preprocessed: 82

Si la cola tiene demasiados mensajes, intente descubrir la procedencia del SPAM.

Si el correo está siendo enviado por un usuario autorizado pero no desde el script PHP, puede ejecutar el comando que aparece a continuación para descubrir el usuario que envió la mayoría de mensajes (desde Plesk 8). Tenga en cuenta que es necesario tener activada la opción ‘Autorización SMTP’ en el servidor para poder ver estos registros:

# cat /usr/local/psa/var/log/maillog |grep -I smtp_auth |grep -I user |awk ‘{print $11}’ |sort |uniq -c |sort -n

La ruta a ‘maillog’ puede cambiar en función del SO que esté usando.

El próximo paso es la utilidad `qmail-qread`, que puede usarse para leer las cabeceras de los mensajes:

# /var/qmail/bin/qmail-qread
18 Jul 2005 15:03:07 GMT #2996948 9073 bouncing
done remote user1@domain1.com
done remote user2@domain2.com
done remote user3@domain3.com
….

Esta muestra los remitentes y destinatarios de los mensajes. Si el mensaje incluye demasiados destinatarios, probablemente se tratará de SPAM. Ahora intente encontrar este mensaje en la cola por su ID #2996948:

# find /var/qmail/queue/mess/ -name 2996948

examine el mensaje y encuentre la primera línea “Recibido” para saber desde dónde se envió la primera vez, por ejemplo, si encuentra:

Received: (qmail 19514 invoked by uid 10003); 13 Sep 2005 17:48:22 +0700

Significa que este mensaje fue enviado a través de algún CGI por el usuario con UID 10003. Usando este UID puede encontrar el dominio correspondiente:

# grep 10003 /etc/passwd 

Si la línea ‘Recibido’ contiene un UID de un usuario ‘apache’ (por ejemplo “invoked by uid 48″) – significa que el SPAM fue enviado a través de algún script PHP. En este caso, puede intentar conocer el spammer usando la información de los correos spam (direcciones de/para, asunto o cualquier otro dato). Generalmente es muy difícil descubrir la fuente de SPAM. Si está completamente seguro de que en este momento hay algún script enviando SPAM (la cola crece rápidamente sin motivo aparente), puede usar el siguiente script para saber qué scripts PHP se están ejecutando en este momento:

# lsof +r 1 -p `ps axww | grep httpd | grep -v grep | awk ‘ { if(!str) { str=$1 } else { str=str”,”$1}}END{print str}’` | grep vhosts | grep php

También puede aplicar el artículo 1711, que describe el procedimiento para conocer desde qué dominios se está enviando el correo a través de scripts PHP.

Líneas recibidas como:

Received: (qmail 19622 invoked from network); 13 Sep 2005 17:52:36 +0700
Received: from external_domain.com (192.168.0.1)

significan que el mensaje ha sido aceptado y entregado a través de SMTP y que el remitente es un usuario de correo autorizado.

Error en Plesk: Espacio insuficiente en /migration del servidor fuente de la migración

Vaya tela…. este error persiste y persiste en las versiones de Plesk …

Síntomas
La migración de un dominio Parallels Plesk Panel finaliza sin ningún error. De todas formas, el dominio no presenta ningún archivo html.

Causa

La causa de este problema es una cantidad de espacio de disco insuficiente en el directorio /migration del servidor fuente.

El Administrador de Migraciones de Parallels Plesk Panel carga el Agente de Migración al servidor fuente. El Agente de Migración es un script perl que realiza el volcado de los datos, usando /migration en el servidor fuente como directorio temporal para la migración. Si el directorio /migration ya no dispone de más espacio o se encuentra en una partición de tamaño limitado, los datos no se volcan debido a esta insuficiencia de espacio de disco.

Puede comprobar el tamaño de la partición ejecutando el comando «df -h». Por ejemplo:

~# df -h

Filesystem Size Used Avail Use% Mounted on

/dev/sda1 950M 254M 649M 29% / <- la partición es demasiado pequeña

/dev/sda2 4.7G 1.6G 3.1G 35% /usr

/dev/sda3 100G 60G 41G 60% /var

/dev/sda4 4.7G 5.5M 4.7G 1% /home

~#

La partición “/” donde se encuentra el directorio /migration es demasiado pequeña. Tar no puede volcar los datos debido a la insuficiencia de espacio de disco.

Resolución

Le recomendamos liberar el directorio /migration en el servidor fuente. También puede transferir el directorio a una partición de mayor capacidad.

Por ejemplo, creemos el directorio de migración en otra partición que tenga espacio suficiente:

source~# mkdir /home/migration

Entonces creeamos un vínculo simbólico:

source~# rm -rf /migration

source~# ln -s /home/migration/ /migration

Y yasta amigos a migrar dominios a saco de servidor a servidor….

Problema con la libreta de direcciones en Horde al actualizar a Plesk a la versión 9.5.1

El problema que os comento me ha pasado con Horde (webmail por defecto en Plesk) por actualizar Plesk de la versión 9.3.0 a 9.5.1.

El problema estaba bien claro, al intentar acceder a la libreta de direcciones que Horde guarda, Horde daba el siguiente error:

DBError: field

y el log de Horde daba el siguiente error:

error log : Apr 20 18:05:16 HORDE [error] [kronolith] DB Error: no such  field:
SELECT event_id, event_uid, event_description, event_location,  event_private, event_status,
event_attendees, event_keywords,  event_title, event_category, event_recurcount, event_recurtype,
 event_recurenddate, event_recurinterval, event_recurdays, event_start,  event_end, event_alarm,
event_modified, event_exceptions,  event_creator_id FROM kronolith_events WHERE calendar_id =  'email@domain.com'
AND event_alarm > 0 AND ((event_end >=  '2010-04-20 00:00:00') OR (event_recurenddate >=
'2010-04-20  00:00:00' AND event_recurtype <> 0))
[nativecode=1054 ** Unknown  column 'event_private' in 'field list'] [pid 26294 on line 323 of  "/usr/share/psa-horde/kronolith/lib/Driver/sql.php"]
 Apr 20 18:05:16 HORDE [error] [turba] DB Error: no such field: SELECT  object_id, owner_id,
 object_type, object_members, object_uid,  object_firstname, object_lastname, object_middlenames,
 object_nameprefix, object_namesuffix, object_alias, object_bday,  object_homestreet,
object_homepob, object_homecity, object_homeprovince,  object_homepostalcode, object_homecountry,
 object_workstreet,  object_workpob, object_workcity, object_workprovince,  object_workpostalcode,
object_workcountry, object_tz, object_email,  object_homephone, object_workphone, object_cellphone,
object_fax,  object_pager, object_title, object_role, object_company,  object_category, object_notes,
object_url, object_freebusyurl,  object_pgppublickey, object_smimepublickey FROM turba_objects WHERE
 (object_type = 'Group' AND owner_id = 'email@domain.com')  [nativecode=1054 ** Unknown column
'object_firstname' in 'field list']  [pid 26294 on line 173 of  "/usr/share/psa-horde/turba/lib/Driver/sql.php"]

Vale pues despues de tantos errores aqui os digo la solución que mas o menos daban en los foros de parallels y que yo le aplique al dichoso error.

El error es debido a que Plesk al actualizar a la versión 9.5.1 instala la versión de psa-turba 2.3.3 que es la que crea el complemento de la libreta de direcciones en Horde, pues desinstalamos ese rpm que Plesk instalo:

rpm -e –nodeps psa-turba-2.3.3

Ahora nos vamos a bajar el anterior paquete rpm de la versión de psa-turba que es el 2.1.7 y posteriormente lo instalamos y listo.

wget http://autoinstall.plesk.com/PSA_9.3.0/dist-rpm-CentOS-5-x86_64/opt/horde/psa-turba-2.1.7-cos5.build93091230.06.noarch.rpm

rpm -i psa-turba-2.1.7-cos5.build93091230.06.noarch.rpm

Y listo¡¡¡ ya tenemos la libreta de direcciones que guarda Horde y no hemos perdido ningún contacto porque no hemos tocado la base de datos ni las tablas que usa Horde.

Error al borrar un dominio en Parallels Plesk Panel

Un error que sigue apareciendo aunque pasen versiones y versiones de Plesk Panel ( desde la 7.4 a la 9.2 ) es la perdida de integridad referencial en algunas tablas. Esto provoca que a la hora de ejectuar algunas herramientas y falten datos se generen errores. En ese caso al borrar el dominio ‘delete.me’ nos aparece este mensaje :

0: class.MailManager.php:242
        MailManager::execWithException(string 'smart_exec', string 'mailmng', array, array, string 'lst')
1: class.MailManager.php:274
        MailManager->callMailManager(string 'remove-mailname', array)
2: class.MailManager.php:354
        MailManager->removeMailname(string 'sharoj.com', string 'delete')
3: cmd_mail.php3:1357
        mn_del(string '490')
4: class.DSMail.php:211
        DSMail->delete(boolean false)
5: class.PhDomain.php:358
        PhDomain->reset(integer '0', boolean true, boolean false)
6: class.BsDomain.php:330
        BsDomain->reset(integer '0')
7: class.BsDomain.php:302
      BsDomain->delete(integer '0')
8: class.BsDomain.php:536
        mdeleteDomains(array)
9: removeDomains.php3:42
        require(string '/opt/psa/admin/htdocs/domains/removeDomains.php3')
10: plesk.php:51

Tendremos que buscar manualmente donde está el problema y repararlo , directamente a la base de datos de Plesk (generalmente llamada psa).

Comenzamos a buscar relaciones rotas entre objetos:

# mysql -uadmin -p`cat /etc/psa/.psa.shadow` psa
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 152938
Server version: 5.0.32-Debian_7etch10-log Debian etch distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> select id, name from domains where name = "delete.me";
+------+------------+
| id   | name       |
+------+------------+
| 1241 | delete.me  |
+------+------------+
1 row in set (0.00 sec)

Ya tenemos el ID del dominio, nos centramos en las cuentas de correo ya que el error se genera al borrar cuentas de correo. Vamos a ver que tablas hay en esta version de Plesk ( 9.2.3 )

mysql> show tables like '%mail%' ;
+------------------------+
| Tables_in_psa (%mail%) |
+------------------------+
| Webmails               |
| badmailfrom            |
| mail                   |
| mail_aliases           |
| mail_redir             |
| mail_resp              |
| mass_mail              |
| mass_mail_clients      |
| mass_mail_domains      |
+------------------------+
9 rows in set (0.00 sec)

La tabla que nos interesa es mail vamos a ver que esctructura tiene y vamos sacando datos:

mysql> desc mail ;
+---------------+------------------------------------------+------+-----+---------+----------------+
| Field         | Type                                     | Null | Key | Default | Extra          |
+---------------+------------------------------------------+------+-----+---------+----------------+
| id            | int(10) unsigned                         | NO   | PRI | NULL    | auto_increment |
| mail_name     | varchar(245)                             | NO   |     |         |                |
| perm_id       | int(10) unsigned                         | NO   | MUL |         |                |
| postbox       | enum('false','true')                     | NO   |     | false   |                |
| account_id    | int(10) unsigned                         | NO   | MUL |         |                |
| redirect      | enum('false','true')                     | NO   |     | false   |                |
| redir_addr    | varchar(255)                             | YES  |     | NULL    |                |
| mail_group    | enum('false','true')                     | NO   |     | false   |                |
| autoresponder | enum('false','true')                     | NO   |     | false   |                |
| spamfilter    | enum('false','true')                     | NO   |     | true    |                |
| virusfilter   | enum('none','incoming','outgoing','any') | NO   |     | none    |                |
| mbox_quota    | bigint(20)                               | NO   |     | -1      |                |
| dom_id        | int(10) unsigned                         | NO   | MUL |         |                |
+---------------+------------------------------------------+------+-----+---------+----------------+
13 rows in set (0.01 sec)
mysql> select * from mail where dom_id = 1241;
+-----+-----------+---------+---------+------------+----------+------------+------------+---------------+------------+-------------+------------+--------+
| id  | mail_name | perm_id | postbox | account_id | redirect | redir_addr | mail_group | autoresponder | spamfilter | virusfilter | mbox_quota | dom_id |
+-----+-----------+---------+---------+------------+----------+------------+------------+---------------+------------+-------------+------------+--------+
| 490 | delete.me |    2202 | true    |       2204 | false    |            | false      | false         | false      | incoming    |         -1 |   1241 |
+-----+-----------+---------+---------+------------+----------+------------+------------+---------------+------------+-------------+------------+--------+
1 row in set (0.00 sec)

Vemos que tiene al menos una cuenta de correo para el usuario 2204, vamos a buscar este usuario en la tabla accounts, ya que el id es accounts_id

mysql> show tables like '%acco%'
    -> ;
+------------------------+
| Tables_in_psa (%acco%) |
+------------------------+
| accounts               |
+------------------------+
1 row in set (0.00 sec)
mysql> select * from accounts where id = 2204 ;
Empty set (0.01 sec)

Pues no está, aquí tenemos el problema, no existe la información del usuario pero sí el buzón.
lo más comodo es borar la entrada en la base de datos de la cuenta de correo. Dado que vamos a borrar el dominio nos es indiferente conservarlo.

mysql> delete from mail where id =490 limit 1 ;
Query OK, 1 row affected (0.03 sec)

De otra forma , habíamos dado de alta una fila en accounts con el id 2204 .

Solución al error: MySQL query failed: Incorrect information in file: ‘./psa/misc.frm’

Síntomas

En la página Inicio de Sesión de Parallels Plesk Panel en https://plesk.host.name:8443, aparece el siguiente error:

ERROR: PleskMainDBException
MySQL query failed: Incorrect information in file: ‘./psa/misc.frm’

0: /usr/local/psa/admin/plib/common_func.php3:216
db_query(string ‘select param, val from misc’)
1: /usr/local/psa/admin/plib/common_func.php3:513
get_param(string ‘mysql41_compatible’)
2: /usr/local/psa/admin/plib/common_func.php3:410
db_set_names()
3: /usr/local/psa/admin/plib/common_func.php3:389
db_connect_real(string ‘localhost’, string ‘admin’, string ‘***********’, string ‘psa’)
4: /usr/local/psa/admin/plib/common_func.php3:369
db_connect()
5: /usr/local/psa/admin/auto_prepend/auth.php3:87

Causa

La causa de este problema son unos permisos incorrectos al directorio /tmp. Por este motivo, MySQL no puede crear sus archivos temporales correctamente para el motor InnoDB en el inicio.

Los permisos correctos son:

~# ls -ld /tmp/
drwxrwxrwt 4 root root 36864 Aug  8 08:41 /tmp/
~#

Resolución

Corrija los permisos con el siguiente comentario:

~# chmod 1777 /tmp

Información Adicional

Para ver el error, actualice la sección [mysqld] en el archivo /etc/my.cnf con esta línea:

/etc/my.cnf
---&gt;8---
[mysqld]
innodb_force_recovery = 4
---8&lt;---

Ahora reinicie el servicio con:

~# /etc/init.d/mysqld restart
Stopping MySQL:                                            [  OK ]
Starting MySQL:                                            [  OK ]
~#

En el archivo de registro de errores de MySQL debería aparecer el siguiente error:

/var/log/mysqld.log
---&gt;8---
^G/usr/libexec/mysqld: Can't create/write to file '/tmp/ib1suXEE' (Errcode: 13)
020326 22:26:17  InnoDB: Error: unable to create temporary file; errno: 13
020326 22:26:18 [Note] /usr/libexec/mysqld: ready for connections.
---8&lt;---

La ubicación del archivo de registro de errores de MySQL se define en el archivo de configuración:

~# grep log-error /etc/my.cnf
log-error=/var/log/mysqld.log
~#