Postfix usando Gmail como relay SMTP

Publicado por Diego Córdoba en

¿Cuántas veces nos ha pasado que disponemos de un servidor de correo electrónico Postfix en un servidor Linux, y a la hora de configurarlo para enviar correos electrónicos a servidores externos, estos correos llegan al SPAM?

¿Te has peleado con las direcciones IP públicas fijas y la resolución inversa de nombres? ¿Y con los registros SRV/TXT en los servicios de DNS?postfix

En este breve artículo traigo una solución simple que puede llegar a serte útil en tus servidores de correo pequeños, e incluso, medianos.

Entorno

En esta pequeña práctica vamos a configurar un servidor de correos Postfix (SMTP) para que, cuando los correos salgan a Internet, utilicen una cuenta de GMAIL como relay, lo que nos permitirá asegurarnos de que los correos lleguen a destino al INBOX siempre, puesto que el destinatario recibirá un correo desde los servidores de SMTP de GMAIL.

Configurando el servidor Postfix

Lo primero que tenemos que hacer es instalar algunos paquetes necesarios en nuestro Linux:

sudo apt-get install postfix mailutils libsasl2-2 ca-certificates libsasl2-modules

Una vez que hemos instalado estos paquetes, ya tendremos el servicio de correos funcional… solo nos faltarán algunos detalles.

Editamos la configuración

El archivo principal de configuración de Postfix es /etc/postfix/main.cf. Lo editamos con el editor de textos de nuestra preferencia, y agregamos las siguientes líneas:

relayhost = [smtp.gmail.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_use_tls = yes

Con eso le diremos a Postfix que utilice soporte SASL para autenticación con un servidor externo, y le diremos que contacte a dicho servidor utilizando el nombre smtpgmail.gmail.com y le apunte al puerto 587 de TCP, el servicio de SMTP seguro.

Los datos de autenticación los buscará en /etc/postfix/sasl_passwd, como lo hemos especificado en el archivo anterior.

Por lo tanto, editamos el /etc/postfix/sasl_passwd, y colocamos el siguiente contenido:

[smtp.gmail.com]:587    USERNAME@gmail.com:PASSWORD

Donde deberemos reemplazar USERNAME y PASSWORD por los de una cuenta de gmail válida.

Nuestro servidor Postfix enviará correos, ahora, desde esta cuenta de gmail.

Por último, debemos crear el archivo de lookup para que postfix pueda conectarse al servidor remoto de gmail utilizando las credenciales especificadas.

Para ello, primero corregimos los permisos del archivo de credenciales, puesto que es un archivo crítico de la configuración:

sudo chmod 0400 /etc/postfix/sasl_passwd

Y luego, creamos la tabla lookup:

sudo postmap /etc/postfix/sasl_passwd

Y recargamos el servicio:

sudo service postfix restart

Ya deberíamos tener nuestro servidor configurado!

Probando la configuración

Vamos a enviarnos un correo electrónico! Solo debemos correr un comando como este, donde la dirección de correos es la del receptor, en este caso, mi cuenta de OMB.

echo «probando servidor» | mail -s «prueba postfix_gmail» d1cor@openmailbox.org

Si nos fijamos en los logs de correo:

admin@ip-172-31-23-221:~$ sudo tail /var/log/mail.log -f
[...]
Jun 25 02:17:35 ip-172-31-23-221 postfix/smtp[27147]: 6E222603AA: to=<d1cor@openmailbox.org>, relay=smtp.gmail.com[74.125.28.108]:587, delay=1.2, delays=0.02/0.01/0.44/0.75, dsn=2.0.0, status=sent (250 2.0.0 OK 1466821060 fj13sm3011362pab.0 - gsmtp)
[...]

Como vemos, el correo está en estado «sent» 🙂

Y si chequeamos nuestra casilla de correos?

postfixNotas

Debemos verificar que el archivo ca-certificates.crt mencionado en el main.cf existe. En el caso de no existir, se puede utilizar cualquier otro certificado válido del directorio /etc/ssl/certs.

Y por último, recordar que estamos enviando correos desde Postfix utilizando Gmail como relay, por lo que tendremos las limitaciones que nos entrega Gmail a la hora de enviar correos, en cuestión de cantidad de destinatarios y correos enviados por día.

Puede verse esta información accediendo a la página de soporte de gmail al respecto.

En fin, espero que les sea de utilidad!! Cualquier consulta o sugerencia quedamos a disposición! Son libres de comentar y compartir. Gracias!

Hasta la próxima!


¿Preguntas? ¿Comentarios?

Si tenés dudas, o querés dejarnos tus comentarios y consultas, sumate al grupo de Telegram de la comunidad JuncoTIC!
¡Te esperamos!


Diego Córdoba

- Ingeniero en Informática - Mg. Teleinformática - Tesis pendiente - Docente universitario - Investigador

3 comentarios

fede · 5 junio, 2017 a las 11:53

Hola Diego,
me estado pegando un buen rato con postfix hasta que encontre tu pagina y logre que me funcionara el relay de gmail¡¡¡, gracias por el post me «salvo» 😀

ahora que por fin me funciona me gustaria me aclarases un par de cosass sobre el codigo:
no se bien que cerificado utilizar, en clase utilizamos el /etc/ssl/certs/Thawte_Premium_Server_CA.pem, probe ambos(el de clase y el de tu pagina) y los dos me funcionana asi que no se ¿cual es mejor?

¿por que algunos tienen extension .PEM y otros.CRT?¿ambas extensiones son validas?

En el comando mail que utilizas en el ejemplo,¿hay alguna manera de sobreescribir la cabecera «From»(nombre y/o direccion)?

Si respondo al email supoongo que me llegara al relay¿no?¿alguna forma de que me llegue la respuesta a a mi servidor?

Gracias por tu post, me sirvio de mucho:D, saludos Diego.

    Diego Cordoba - @d1cor · 12 junio, 2017 a las 15:24

    Hola Fede! Te respondo lo que puedo 😛

    Los certificados que el sistema tiene dentro de /etc/ssl/certs generalmente van a funcionar bien, porque son los certificados que incluyen las claves públicas de las autoridades certificantes (CA’s) en las que el sistema confía, de modo que el cliente no tenga ningún tipo de advertencia de certificado o firma digital falsos.

    Tanto .crt como .pem son extensiones válidas para certificados digitales. PEM es el formato interno de ambas (Portable Enhancement Mail) por lo general, pero algunos sistemas y aplicaciones de windows, por ejemplo, no te reconocen las extensiones .pem, y se usa .crt, pero en general, el crt internamente tiene formato PEM (y raramente DER, otro formato de certificado).

    Y para lo de la dirección de respuestas, yo en este servidor no lo he levantado, por lo que sí, llegan al relay, a la cuenta de gmail. Acá podés hacer dos cosas. Una, en la cuenta de gmail del relay establecer reglas de forwarding para que te reenvíe los mails a tu cuenta del servidor; y otra, más elegante, en las configuraciones de postfix podés reescribir el campo FROM y REPLY-TO de los correos. Para eso tendrías que leer algo de doc… te paso algunos links que pueden serte útiles:

    http://www.postfix.org/ADDRESS_REWRITING_README.html
    https://serverfault.com/questions/811245/how-to-configure-postfix-to-force-from-field-but-leave-reply-to-alone
    http://thinlight.org/2016/07/30/postfix-replace-sender-address-and-add-reply-to-header/

    Espero te sirva!
    (luego leo tranqui tus otros comentarios y te voy respondiendo :P)
    Abz!

Diego Cordoba - @d1cor · 31 enero, 2018 a las 14:51

Hola Nicolás!

Si te referís al archivo «/etc/ssl/certs/ca-certificates.crt», debería generarse solo cuando vos instalás el paquete ca-certificates.

Ese archivo contiene los certificados digitales x509 reconocidos por el sistema, de modo que si el servidor remoto envía su certificado (clave pública) para garantizar la privacidad y autenticidad de la comunicación, tu servidor pueda aceptarlo como certificado válido en forma automática.

No es necesario que google te reconozca como servidor, ya que el Postix es el servidor, pero conecta contra una cuenta de google como cliente, de modo que para google, tu postfix es un cliente conectado que envía correos… la única diferencia es que, en vez de ser una «persona» conectada al gmail enviando mails, es un postfix el que conecta para enviar y recibir, y las «personas» se conectan contra el postfix y lo utilizan como servidor.

Espero te aclare un poco!
Culquier duda quedo a disposición.
Saludos!!

Los comentarios están cerrados.