.png)
Después de configurar con éxito un servidor iRedMail para mi dominio principal, intenté agregar mi dominio secundario como alias siguiendo los pasos que se detallan aquí:https://docs.iredmail.org/sql.add.alias.domain.html
Esto todavía no funcionó, así que agregué adicionalmente el dominio secundario en /etc/postfix/main.cf:
virtual_alias_domains = domain2.tld
virtual_alias_maps = hash:/etc/postfix/virtual
Nota: No eliminé ninguna de las entradas de MySQL existentes en virtual_alias_maps.
E ingresé el mapeo en /etc/postfix/virtual y luego ejecuté "postmap /etc/postfix/virtual":
@domain2.tld @domain1.tld
Esto está funcionando internamente en el servidor.[correo electrónico protegido]puede enviar a[correo electrónico protegido]y el usuario2 recibirá el correo en su buzón. Los correos electrónicos externos también llegan cuando se envían a[correo electrónico protegido].
Lamentablemente no funciona con correos externos al dominio secundario. En mi /var/logs/mail.log encuentro las siguientes líneas:
postfix/smtpd[5541]: NOQUEUE: reject: RCPT from mail-oi1-x231.google.com[2607:f8b0:4864:20::231]: 451 4.3.5 <[email protected]>: Recipient address rejected: Server configuration problem; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail-oi1-x231.google.com>
Y:
postfix/smtpd[5644]: warning: problem talking to server 127.0.0.1:12340: Connection timed out
En el puerto 12340 el palomar está escuchando:
dovecot 513 root 67u IPv4 17087 0t0 TCP 127.0.0.1:12340 (LISTEN)
En mi registro de palomar encuentro la siguiente línea repetidamente:
dovecot: quota-status: Error: quota-status: Client sent invalid recipient address: Invalid character in path
Después de algunas pruebas adicionales con diferentes servidores de correo externos, me di cuenta de que 2 de cada 4 correos llegaban cuando se enviaban al dominio secundario. GMail y Hotmail no lo hicieron, el intercambio de mi empresa y algún otro proveedor web sí lo hicieron.
Y ahí es donde estoy estancado. Sospecho una de dos cosas: o simplemente me perdí una configuración necesaria, lo cual parece muy probable, ya que nunca antes configuré un servidor de correo en Debian, o el error de dovecot es causado por mi dominio secundario. El dominio secundario contiene una diéresis (ä/ö/ü), que soy consciente de que puede causar algunos problemas. Por lo tanto, también soy propietario del dominio en su variante formateada en punycode. Entonces, cada vez que agregaba mi dominio secundario con su diéresis a una configuración, también agregaba la versión punnycode, asumiendo que resolvería cualquier problema al respecto.
iRedMail/postfix/dovecot/whateverelseisinvolved parecen estar funcionando bien con punnycode/umlauts per se, simplemente parece depender del remitente, ya que solo la mitad de los correos se pierden (el remitente no recibirá un error). ¿Alguna idea de por qué o qué registros podría verificar para profundizar en esto? ¿Simplemente me perdí configurar algo obvio?
Cualquier impulso en la dirección correcta es muy apreciado.
Saludos, mocos
==== Información básica ====
- Versión de iRedMail: edición 1.4.0 MARIADB
- Nombre y versión de la distribución Linux/BSD: Debian GNU/Linux 10 (buster) - 10.10
- Base de datos usada: MySQL (MariaDB)
- Servidor web: Nginx
==== Editar ====
En cuanto a la configuración básica; Después de una instalación limpia de Debian 10, seguí los pasos de esta guía.https://www.linuxbabe.com/mail-server/debian-10-buster-iredmail-email-server
Cualquier configuración específica que se modifique con respecto a la guía se menciona en la publicación. Además, emití un certificado que incluye el dominio principal y el dominio secundario en punnycode.
Aquí los distintos registros de arranque:
/var/log/mail.log:
Aug 14 14:24:36 s postfix/postfix-script[1637]: warning: symlink leaves directory: /etc/postfix/./makedefs.out
Aug 14 14:24:37 s amavis[573]: starting. /usr/sbin/amavisd-new at host.domain1.tld amavisd-new-2.11.0 (20160426), Unicode aware, LC_ALL="C", LANG="en_US.UTF-8"
Aug 14 14:24:37 s postfix/postfix-script[1819]: starting the Postfix mail system
Aug 14 14:24:37 s postfix/master[1821]: daemon started -- version 3.4.14, configuration /etc/postfix
Aug 14 14:24:39 s amavis[1915]: Net::Server: Group Not Defined. Defaulting to EGID '121 121'
Aug 14 14:24:39 s amavis[1915]: Net::Server: User Not Defined. Defaulting to EUID '113'
Aug 14 14:24:39 s amavis[1915]: No ext program for .F, tried: unfreeze, freeze -d, melt, fcat
Aug 14 14:24:39 s amavis[1915]: No ext program for .zoo, tried: zoo, unzoo
Aug 14 14:24:39 s amavis[1915]: No decoder for .F
Aug 14 14:24:39 s amavis[1915]: No decoder for .zoo
Aug 14 14:24:39 s amavis[1915]: Using primary internal av scanner code for clamav-socket
Aug 14 14:24:39 s amavis[1915]: Found secondary av scanner clamav-clamscan at /usr/bin/clamscan
/var/log/dovecot/dovecot.log:
Aug 14 14:24:26 s dovecot: master: Dovecot v2.3.4.1 (f79e8e7e4) starting up for pop3, imap, sieve, lmtp (core dumps disabled)
Aug 14 14:24:43 s dovecot: stats: Error: (stats-reader): didn't reply with a valid VERSION line: EXPORT#011global
Aug 14 14:24:43 s dovecot: stats: Error: (stats-reader): didn't reply with a valid VERSION line: EXPORT#011global
sufijo grep /var/log/syslog:
Aug 14 14:24:36 s postfix/postfix-script[1637]: warning: symlink leaves directory: /etc/postfix/./makedefs.out
Aug 14 14:24:37 s postfix/postfix-script[1819]: starting the Postfix mail system
Aug 14 14:24:37 s postfix/master[1821]: daemon started -- version 3.4.14, configuration /etc/postfix
Deshabilité las funciones de cuota y habilité SMTPUTF8 en mi postfix main.cf, sin cambios notables, excepto por una línea adicional al arrancar en mail.log:
Aug 14 14:59:46 s amavis[571]: starting. /usr/sbin/amavisd-new at host.domain1.tld amavisd-new-2.11.0 (20160426), Unicode aware, LC_ALL="C", LANG="en_US.UTF-8"
Desafortunadamente, el comportamiento sigue siendo el mismo. Después de analizar más a fondo los registros, me di cuenta de que parece que los correos electrónicos de los proveedores que llegan se envían mediante punycode (incluso si los envié específicamente al dominio con diéresis/carácter no ASCII). GMail, por otro lado, en realidad envía el correo al dominio que contiene la diéresis (sin código punycode, incluso si uso específicamente el formato punycode en la dirección de correo del destinatario). Entonces, tendré que enseñarle a mi servidor a manejar caracteres que no sean ASCII o debo enseñarle a Google a enviar mediante punycode. O enseñarle a mi servidor a traducir diéresis a punycode. Obviamente, la opción 2 no es realmente una opción, por lo que sí lo es la 1 o la 3.
Entrada de mail.log del correo del proveedor de alojamiento que no es de GMail:
postfix/amavis/smtp[2300]: 4Gn0zh0z4FzLnSJ: to=<[email protected]>, orig_to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10024, delay=4, delays=0.1/0/0.01/3.9, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 4Gn0zm04JHzLxc0)
entrada mail.log del correo GMail:
Aug 14 15:06:44 s postfix/smtpd[2281]: warning: problem talking to server 127.0.0.1:12340: Connection timed out
Aug 14 15:06:44 s postfix/smtpd[2281]: NOQUEUE: reject: RCPT from mail-ot1-x32b.google.com[2607:f8b0:4864:20::32b]: 451 4.3.5 <user@dömain2.tld>: Recipient address rejected: Server configuration problem; from=<[email protected]> to=<user@dömain2.tld> proto=ESMTP helo=<mail-ot1-x32b.google.com>
Respuesta1
Como todavía no puedo ver una solución completa (la reescritura de direcciones en Postfix podría funcionar, pero sería un final triste para esta historia), estoy recopilando mis pasos de diagnóstico en una respuesta:
Adquirir eleficazconfiguración, como los volcados por los comandos
postfix -n
ypostfix -M
si el servidor de correo para garantizar una comprensión clara de la forma en que se integran los diferentes servicios (amavis, principalmente).Pruebe individualmente no ASCII en localpart, en encabezados sin direcciones y en nombres de dominio (allí como etiqueta A codificada a través de Punycode para comenzar como
xn--
y como Unicode que contiene directamente las letras no ASCII)Mantener
SMTPUTF8
deshabilitado en Postfix: Dovecot aún no admite completamente el manejo de correo que podría recibirse de esa manera y no es necesario ni necesariamente útil para resolver problemas en amavis.amavis tiene una
$log_level
configuración (en Debian, presumiblemente en/etc/amavis/conf.d/
) quepuede ser puesto a cero como parte de suiRedMaildistribución.Si tiene la opción de cambiar eso, ejecute amavis como cola anteriormetroilter (en lugar de como un smtp posterior a la colaFilter) puede o no revelar un error o comportamiento más útil.
amavis solucionó algunos problemas de SQL+Unicode específicos de mariadbdespués de la versión 2.11 que está utilizando, puede haber un error útil en el registro de la base de datos, o podría descartarse comparando la misma pila configurada con un backend de postgres funcionalmente idéntico (postgres no comparte las características/errores Unicode de MySQL y MariaDB)