.png)
Depois de configurar com sucesso um servidor iRedMail para meu domínio principal, tentei adicionar meu domínio secundário como um alias seguindo as etapas aqui:https://docs.iredmail.org/sql.add.alias.domain.html
Isso ainda não funcionou, então adicionei adicionalmente o domínio secundário ao /etc/postfix/main.cf:
virtual_alias_domains = domain2.tld
virtual_alias_maps = hash:/etc/postfix/virtual
Nota: não removi nenhuma das entradas existentes do mysql em virtual_alias_maps.
E inseri o mapeamento em /etc/postfix/virtual e executei "postmap /etc/postfix/virtual" depois:
@domain2.tld @domain1.tld
Isso está funcionando internamente no servidor.[e-mail protegido]pode enviar para[e-mail protegido]e o usuário2 receberá o e-mail em sua caixa de correio. E-mails externos também chegam quando enviados para[e-mail protegido].
Infelizmente não funciona com e-mails externos para o domínio secundário. No meu /var/logs/mail.log encontro as seguintes linhas:
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>
E:
postfix/smtpd[5644]: warning: problem talking to server 127.0.0.1:12340: Connection timed out
Na porta 12340 o dovecot está escutando:
dovecot 513 root 67u IPv4 17087 0t0 TCP 127.0.0.1:12340 (LISTEN)
No meu log do pombal, encontro a seguinte linha repetidamente:
dovecot: quota-status: Error: quota-status: Client sent invalid recipient address: Invalid character in path
Após alguns testes adicionais com diferentes hosters de e-mail externos, percebi que 2 em cada 4 e-mails chegavam quando enviados para o domínio secundário. O GMail e o Hotmail não funcionaram, a troca da minha empresa e de algum outro provedor da web funcionou.
E é aí que estou preso. Suspeito de uma de duas coisas: ou simplesmente perdi uma configuração necessária, o que parece altamente provável, já que nunca configurei um servidor de e-mail no Debian antes, ou o erro dovecot é causado pelo meu domínio secundário. O domínio secundário contém um trema (ä/ö/ü), que sei que pode causar alguns problemas. Portanto, também possuo o domínio em sua variante formatada em punycode. Portanto, sempre que adicionei meu domínio secundário com trema a uma configuração, também adicionei a versão punnycode dele, presumindo que isso resolveria quaisquer problemas nesse sentido.
iRedMail/postfix/dovecot/whateverelseisinvolved parece estar funcionando bem com punnycode/tremas por si só, apenas parece depender do remetente, já que apenas metade dos e-mails são perdidos (o remetente não receberá um erro). Algum palpite sobre por que ou quais registros eu poderia verificar para me aprofundar nisso? Eu simplesmente deixei de configurar algo óbvio?
Qualquer impulso na direção certa é muito apreciado.
Atenciosamente, Snot
==== Informações básicas ====
- Versão iRedMail: edição 1.4.0 MARIADB
- Nome e versão da distribuição Linux/BSD: Debian GNU/Linux 10 (buster) - 10.10
- Banco de dados usado: MySQL (MariaDB)
- Servidor Web: Nginx
==== Editar ====
No que diz respeito à configuração básica; Após uma instalação limpa do Debian 10, segui as etapas deste guiahttps://www.linuxbabe.com/mail-server/debian-10-buster-iredmail-email-server
Qualquer configuração específica alterada no guia foi mencionada na postagem. Além disso, emiti um certificado que inclui o domínio principal e o domínio secundário em punnycode.
Aqui estão os vários logs na inicialização:
/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
grep postfix /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
Desativei os recursos de cota e ativei o SMTPUTF8 em meu postfix main.cf, nenhuma alteração notável, exceto uma linha adicional na inicialização no 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"
O comportamento ainda é o mesmo, infelizmente. Depois de analisar mais detalhadamente os logs, percebi que parece que os e-mails dos provedores que chegam são enviados via punycode (mesmo que eu os tenha enviado especificamente para o domínio com trema/caractere não ASCII). O GMail, por outro lado, na verdade envia o e-mail para o domínio que contém o trema (não punycode, mesmo que eu use especificamente o formato punycode no endereço de e-mail do destinatário). Portanto, precisarei ensinar meu servidor a lidar com caracteres não ASCII ou preciso ensinar o Google a enviar via punycode. Ou ensine meu servidor a traduzir tremas para punycode. A opção 2 obviamente não está realmente disponível, então 1 ou 3 está.
Entrada mail.log de e-mail de hoster não 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 do correio do 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>
Responder1
Como ainda não consigo ver uma solução completa (reescrever endereços no Postfix pode funcionar, mas seria um triste final para esta história), estou coletando minhas etapas de diagnóstico em uma resposta:
Adquira oeficazconfiguração, como despejado pelos comandos
postfix -n
epostfix -M
se o servidor de e-mail para garantir uma compreensão clara da forma como os diferentes serviços (amavis, principalmente) estão integrados.Teste individualmente não-ASCII em localpart, em cabeçalhos sem endereço e em nomes de domínio (como A-Label codificado via Punycode para começar como
xn--
e como Unicode contendo diretamente as letras não-ASCII)Manter
SMTPUTF8
desativado no Postfix - o Dovecot ainda não suporta totalmente o tratamento de mensagens que podem ser recebidas dessa forma e não é necessário nem necessariamente útil na resolução de problemas no amavis.amavis tem uma
$log_level
configuração (no Debian, presumivelmente em/etc/amavis/conf.d/
) quepode ser zerado como parte do seuiRedMaildistribuição.Se você tiver a opção de mudar isso, execute o amavis como uma fila anterioreufiltro (em vez de um smtp pós-filaffiltro) pode ou não revelar um erro ou comportamento mais útil.
amavis corrigiu alguns problemas SQL + Unicode específicos do mariadbapós a versão 2.11 que você está usando, um erro útil pode estar no log do banco de dados - ou pode ser descartado comparando a mesma pilha configurada com um backend postgres funcionalmente idêntico (o postgres não compartilha os recursos/bugs Unicode do MySQL e MariaDB)