Archivos de la categoría General

errores-smtp

Listado de errores SMTP al enviar un email

errores-smtp

Algunas veces al enviar un Email, el servidor de correo del destinatario, puede devolvernos un mensaje con un error SMTP, indicándonos el motivo por el que nuestro correo no ha podido ser entregado. Descubre los errores mas comunes.

Los programas de Email, algunas veces, pueden indicarnos un error al enviar un mail. Otras veces el servidor del destinatario es quien se encarga de devolvernos un correo indicando dicho error. Estos correos suelen tener, como asunto, el texto: Message Delivery Failure, y suelen tener como remitente la cuenta Postmaster del dominio del destinatario

A continuación os indicamos los código de error más habituales, que nos podemos encontrar dentro del mail que nos envían, o como mensaje en pantalla el ejecutar el habitual Enviar y recibir. Como siempre, reconocer el problema por el que nuestro correo no se ha podido entregar, puede ahorrarnos mucho tiempo, si nos evitamos enviar un ticket o una llamada a nuestro ISP.

  • SMTP 421 ERROR – Service not available, closing transmission channel.

Esta respuesta la envía el Servidor SMTP a un Servidor SMTP remoto o a un Cliente SMTP para indicarle que el Servidor SMTP no está disponible en ese momento, quizá por un reinicio del servicio de correo, del servidor en si, o un fallo temporal en la línea.

  • SMTP 450 ERROR – Requested mail action not taken: mailbox unavailable.

Esta respuesta la envía el servidor para indicar que un mensaje no pudo entregarse al buzón del destinatario, debido a que dicho buzón de correo está ocupado, posiblemente recibiendo otro correo en ese momento.

  • SMTP 451 ERROR – Requested action aborted: local error in processing.

Esta respuesta se obtiene cuando el Servidor SMTP incurre en un error al ejecutar una transacción de SMTP. Suele deberse a un bloqueo temporal al interrumpirse el envío de un archivo adjunto o similar.

  • SMTP 452 ERROR – Requested action not taken: insufficient system storage.

No hay suficiente espacio en la cuenta para almacenar el mensaje. Si almacenamos nuestros correos en el servidor, hemos de tener en cuenta que periódicamente hemos de eliminar algunos de ellos, ya que el espacio destinado a una cuenta de correo es limitado y si llegamos a tenerla al límite es posible que nuestro ISP, no nos permita excesos de espacio temporales.

  • SMTP 500 ERROR – Syntax error, command unrecognized.

Indica que el servidor no pudo interpretar un comando que se le envió al Servidor o Cliente remoto de SMTP.

  • SMTP 501 ERROR – Syntax error in parameters or arguments.

Indica que el servidor identificó un intento de envío de un comando SMTP pero los parámetros asociados al mismo contenían algún error de sintaxis.

  • SMTP 502 ERROR – Command not implemented.

Indica que una característica o comando solicitado al servidor no pudo entregarse porque está deshabilitada o no está implementada en el conector SMTP, del servidor de correo.

  • SMTP 504 ERROR – Command parameter not implemented.

Indica que el comando enviado al conector SMTP del servidor de correo, contenía otro comando que no se pudo procesar en la misma transacción.

  • SMTP 550 ERROR – Requested action not taken: mailbox unavailable or is not local.

Indica que la dirección del destinatario no se encuentra alojada en ese servidor o sencillamente que no existe. Este es uno de los errores mas habituales cuando escribimos una dirección de correo incorrecta.

  • SMTP 551 ERROR – User not local; please try.

Indica que el receptor especificado en el comando RCPT no está albergado localmente en el servidor, o que es posible que el dominio que hemos indicado no dispone de buzones de correo.

  • SMTP 552 ERROR – Requested mail action aborted: exceeded storage allocation.

Esta respuesta se obtiene cuando el usuario ha excedido su capacidad de almacenaje de correo. Algunas veces, los servidores de correo tienen configurado que no acepten correos que contengan archivos adjuntos superiores a un tamaño en concreto. De este modo se evita bloquear un buzón de correo, por si el cliente dispone de una línea de datos de poco ancho de banda, como sería una tarifa plana con módem analógico.

  • SMTP 553 ERROR – Requested action not taken: mailbox name not allowed.

Indica que el formato de una dirección SMTP especificada es incorrecta o no está bien formateada. Esto no es muy habitual, aunque suele suceder cuando se intentan implementar cuentas de correo con caracteres especiales como sería la “ñ” un guión, un punto o un acento.

  • SMTP 554 ERROR – Transaction failed.

Es una respuesta genérica del servidor cuando falla una transacción SMTP. Normalmente ocurre esto cuando se reciben demasiados errores de procesamiento.

  • SMTP 214 ERROR – Help message.

Información sobre cómo utilizar el receptor o el significado de algún comando no estándar; es una respuesta útil solo para el usuario humano.

seguridad-informatica

Navega de forma anónima/segura mediante túneles SSH

Mediante los túneles SSH podemos asegurar casi todo tipo de protocolos, al conectarnos a una red insegura, como puede ser la red WiFi de un hotel, restaurante o las típicas redes públicas que algunos ayuntamientos ofrecen de forma gratuita (que por cierto, no sé cuanto durará), estamos expuesto a diferentes ataques por parte de otros usuarios conectados a la misma red.

El escenario por norma general es poner la tarjeta en modo “promiscuo” y estar mirando todos los paquetes que pasan por nuestra tarjeta de red, que puede tratarse de información sensible, desde usuarios y claves hasta números de cuentas bancarias.

Para éste ejemplo he usado un servidor VPS de tipo “budget” (precios bajos – prestaciones bajas) para realizar el artículo. Lo primero será asegurarnos de que el servidor SSH, en mi caso OpenSSH, está correctamente configurado para soportar los túneles.

Procedemos a mirar la configuración del servicio SSH en /etc/ssh/sshd_config y buscamos las siguientes directivas:

AllowTcpForwarding yes
GatewayPorts yes
TCPKeepAlive yes

Donde el primer parámetro activa el redireccionamiento y encapsulación de los diferentes protolocos basado en TCP y el segundo hace que la conexión se mantenga de forma continua, normalmente después de un tiempo, que suele ser aproximadamente unas dos horas, la conexión TCP se desconecta de forma automática.

Una vez editado el fichero de configuración, procedemos a reiniciar el servicio:

/etc/init.d/ssh restart

En otros sistemas operativos como CentOS, los demonios se encuentran en rc.d.

El siguiente paso es conectarnos y crear el túnel en el puerto que pasaremos como argumento al cliente ssh:

>ssh -D 8080 mad@servidor-personal.com

Con el comando de arriba, estamos creando un túnel en el puerto 8080 de nuestro propio equipo hacia el servidor SSH. Si queremos aprovechar el puerto y navegar de forma segura, tendremos que configurar nuestro navegador para al conectarse a los servidores web, use como servidor SOCKS nuestro propio equipo local y el puerto 8080.

Por ejemplo en Firefox se hace en la Configuración de Red:

Después de guardar los cambios, es recomendable reiniciar el navegador. El proceso es similar en la mayoría de los demás navegadores, para crear el túnel SSH, si estamos en Windows, en la parte final de artículo encontrarás otros artículos de apoyo para hacerlo desde Windows mediante el cliente SSH PuTTy.

Podemos ver un claro ejemplo si empleamos un sniffer, en éste caso WireShark, las diferencias entre el envío de datos cifrados y en claro.

En el ejemplo de arriba los datos están cifrados, mientras que en el de abajo no.

El uso de túneles no se limita sólo al ámbito web, podemos tunelizar cualquier protocolo, si queremos acceder de forma segura a nuestro servidor de correo, también podemos tunelizar POP, SMTP, IMAP y demás.

ssh -f usuario@servidor-personal.com -L 2000:smtp.gmail.com:25 -N

En éste ejemplo, estamos haciendo un túnel desde el puerto 2000 del servidor-personal al puerto 25 del servidor SMTP de gmail.com. El uso es ilimitado, sólo depende de nuestra imaginación.

Recursos y Documentación:

_SSH Port Forwarding [Symantec]

_Port Forwarding [The SSH Definitive Guide]

_How to tunnel Web Traffic with SSH Secure Shell [Using PuTTy]

_Breaking Firewalls with OpenSSH and PuTTy

Nota:
No hace falta tener un VPS o un servidor dedicado, podemos usar nuestro propio equipo que tenemos en casa, claro está, que habrá que mantenerlo encendido continuamente.

Podeis usar tambien una shell gratuita, yo uso la de http://shellmix.com

Si nó… pues siempre tendremos web proxy para navegar desde la oficina como la de NavegasinLey.com

SSHPASS nos permite incluir la password en la misma linea de conexión SSH

Con la necesidad de hacer un script en bash, me ví con la obligación de hacer una conexion ssh y no queria que me pidiera contraseña cada vez que lo ejecutara.
Tenia la opcion por claves publicas y privada pero creo que iba a perder mucho tiempo, asi que opte por la siguiente:
Nos bajamos el paquete llamado sshpass de sourceproject

wget http://heanet.dl.sourceforge.net/project/sshpass/sshpass/1.05/sshpass-1.05.tar.gz
tar xvf sshpass-1.05.tar.gz
cd sshpass-1.05
./configure
make
sudo make install

Ahora una vez instalado sshpass en nuestro sistema o servidor, la sentencia para conectarnos a ssh es la siguiente:

sshpass -p 'passwd' ssh root@192.168.1.54

Cambiar nombre del Host sin reiniciar en CentOS/RedHat – Linux

Este procedimiento deberia funcionar en las distribuciones RedHat Linux 7.x/9, RHEL, Fedora y CentOS sin problemas porque todas tienen similar configuración. El objetivo es nunca reiniciar sin necesidad y mantener el tiempo de uptime del servidor intacto y por supuesto no interrumpir los otros servicios.

  1. Abrimos una consola como usuario root.
  2. Editar el archivo network y cambiar el nombre del host en la variable HOSTNAME.
    nano /etc/sysconfig/network
    HOSTNAME=central
  3. Adicionar  el número ip del nuevo host.
    nano /etc/hosts
    192.168.0.1 central

    Las modificaciones realizadas en /etc/hosts y /etc/sysconfig/network son necesarias para que los cambios sean permanentes.
  4. Cambiar el nombre del host usando el comando hostname.
    hostname redhat9
  5. y ejecutar nuevamente el comando hostname sin incluir el host para ver el cambio.
    hostname
  6. Finalmente reiniciar el servicio de red para aplicar los cambios realizados.
    service network restart
  7. Para verificar que el nombre del host fue realmente cambiado debemos salir e ingresar nuevamente a la sesión. Con cerrar la terminal y abrir otra terminal veremos que el nombre ha cambiado.

Rápido, sin problemas y no interrumpimos los servicios del servidor ni tampoco perdemos el uptime de nuestro servidor.