După ce am configurat cu succes un server iRedMail pentru domeniul meu principal, am încercat să adaug domeniul meu secundar ca alias urmând pașii de aici: https://docs.iredmail.org/sql.add.alias.domain.html
Acest lucru nu a funcționat încă, așa că am adăugat, în plus, domeniul secundar în /etc/postfix/main.cf:
virtual_alias_domains = domain2.tld
virtual_alias_maps = hash:/etc/postfix/virtual
Notă: nu am eliminat niciuna dintre intrările mysql existente sub virtual_alias_maps.
Și a introdus maparea în /etc/postfix/virtual și a executat „postmap /etc/postfix/virtual” după aceea:
@domeniul2.tld @domeniul1.tld
Acesta funcționează intern pe server. [email protected] poate trimite la [email protected] și user2 va primi e-mailul în căsuța sa poștală. E-mailurile externe ajung, de asemenea, atunci când sunt trimise la [email protected].
Din păcate, nu funcționează cu e-mailuri externe către domeniul secundar.
În /var/logs/mail.log-ul meu găsesc următoarele rânduri:
postfix/smtpd[5541]: NOQUEUE: respinge: RCPT de la mail-oi1-x231.google.com[2607:f8b0:4864:20::231]: 451 4.3.5 <[email protected]>: adresa destinatarului respinsă : Problemă de configurare a serverului; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail-oi1-x231.google.com>
Și:
postfix/smtpd[5644]: avertisment: problemă la convorbirea cu serverul 127.0.0.1:12340: conexiune a expirat
Pe portul 12340, dovecot ascultă:
dovecot 513 root 67u IPv4 17087 0t0 TCP 127.0.0.1:12340 (ASCULTATE)
În jurnalul meu porumbel găsesc în mod repetat următorul rând:
dovecot: quota-status: Eroare: quota-status: Clientul a trimis adresa destinatarului nevalid: Caracter nevalid în cale
După câteva teste suplimentare cu diferiți hosteri externi de e-mail, mi-am dat seama că 2 din 4 e-mailuri au ajuns atunci când au fost trimise către domeniul secundar. GMail și Hotmail nu, schimbul companiei mele și alt furnizor de web au venit.
Și acolo sunt blocat. Bănuiesc unul din două lucruri:
Fie pur și simplu am ratat o configurație necesară, ceea ce pare foarte probabil, deoarece nu am mai configurat niciodată un server de e-mail pe Debian, fie eroarea porumbelului este cauzată de domeniul meu secundar. Domeniul secundar conține un umlaut (ä/ö/ü), despre care știu bine că poate cauza unele probleme. Prin urmare, dețin și domeniul în varianta sa formatată punycode. Deci, ori de câte ori am adăugat domeniul meu secundar cu umlaut la o configurație, am adăugat și versiunea punnycode a acestuia, presupunând că ar rezolva orice problemă în acest sens.
iRedMail/postfix/dovecot/whateverelseisinvolved par să funcționeze bine cu punnycode/umlauts în sine, se pare că depinde doar de expeditor, deoarece doar jumătate din e-mailuri se pierd (expeditorul nu va primi o eroare). Vreo ghicire de ce sau ce jurnale aș putea verifica pentru a săpa mai adânc în asta? Pur și simplu am omis să configurez ceva evident?
Orice împingere în direcția corectă este foarte apreciată.
Salutari,
Snot
==== Informații de bază ====
- Versiunea iRedMail: ediția 1.4.0 MARIADB
- Numele și versiunea distribuției Linux/BSD: Debian GNU/Linux 10 (buster) - 10.10
- DB folosit: MySQL (MariaDB)
- Server web: Nginx
==== Editare ====
În ceea ce privește configurarea de bază; După o instalare curată a Debian 10, am urmat pașii din acest ghid https://www.linuxbabe.com/mail-server/debian-10-buster-iredmail-email-server
Orice configurație specifică care se modifică din ghid a fost menționată în postare. În plus, am emis un certificat care include domeniul principal și domeniul secundar în punnycode.
Iată diferitele jurnaluri la boot:
/var/log/mail.log:
14 august 14:24:36 s postfix/postfix-script[1637]: avertisment: linkul simbolic părăsește directorul: /etc/postfix/./makedefs.out
Aug 14 14:24:37 s amavis[573]: starting. /usr/sbin/amavisd-new la host.domain1.tld amavisd-new-2.11.0 (20160426), compatibil Unicode, LC_ALL="C", LANG="en_US.UTF-8"
14 august 14:24:37 s postfix/postfix-script[1819]: pornirea sistemului de corespondență Postfix
14 august 14:24:37 s postfix/master[1821]: demonul a început -- versiunea 3.4.14, configurație /etc/postfix
Aug 14 14:24:39 s amavis[1915]: Net::Server: Group Not Defined. Implicit la EGID „121 121”
Aug 14 14:24:39 s amavis[1915]: Net::Server: User Not Defined. Implicit la EUID „113”
Aug 14 14:24:39 s amavis[1915]: Niciun program ext pentru .F, încercat: unfreeze, freeze -d, melt, fcat
Aug 14 14:24:39 s amavis[1915]: Niciun program ext pentru .zoo, încercat: zoo, unzoo
Aug 14 14:24:39 s amavis[1915]: Fără decodor pentru .F
Aug 14 14:24:39 s amavis[1915]: Fără decodor pentru .zoo
Aug 14 14:24:39 s amavis[1915]: Utilizarea codului principal al scanerului AV intern pentru clamav-socket
Aug 14 14:24:39 s amavis[1915]: S-a găsit un scaner av secundar clamav-clamscan la /usr/bin/clamscan
/var/log/dovecot/dovecot.log:
14 august 14:24:26 s dovecot: master: Dovecot v2.3.4.1 (f79e8e7e4) pornește pentru pop3, imap, sieve, lmtp (dumpurile de miez dezactivate)
Aug 14 14:24:43 s dovecot: stats: Eroare: (stats-reader): nu a răspuns cu o linie validă VERSION: EXPORT#011global
Aug 14 14:24:43 s dovecot: stats: Eroare: (stats-reader): nu a răspuns cu o linie validă VERSION: EXPORT#011global
grep postfix /var/log/syslog:
14 august 14:24:36 s postfix/postfix-script[1637]: avertisment: linkul simbolic părăsește directorul: /etc/postfix/./makedefs.out
14 august 14:24:37 s postfix/postfix-script[1819]: pornirea sistemului de corespondență Postfix
14 august 14:24:37 s postfix/master[1821]: demonul a început -- versiunea 3.4.14, configurație /etc/postfix
Am dezactivat funcțiile thequota și am activat SMTPUTF8 în postfixul meu main.cf, nicio modificare notabilă, cu excepția unei linii suplimentare la boot în mail.log:
Aug 14 14:59:46 s amavis[571]: starting. /usr/sbin/amavisd-new la host.domain1.tld amavisd-new-2.11.0 (20160426), compatibil Unicode, LC_ALL="C", LANG="en_US.UTF-8"
Comportamentul este în continuare același, din păcate. După ce am analizat în continuare jurnalele, mi-am dat seama că e-mailurile de la furnizorii care vin sunt trimise prin punycode (chiar dacă l-am trimis în mod specific la domeniul cu umlaut/non-ASCII-char). Pe de altă parte, Gmail trimite de fapt e-mailul către domeniul care conține umlaut (non-punycode, chiar dacă folosesc în mod special formatul punycode în adresa de e-mail al destinatarului).
Deci, fie va trebui să-mi învăț serverul să gestioneze caracterele non-ASCII, fie trebuie să învăț Google să trimită prin punycode. Sau învață-mi serverul să traducă umlauts în punycode. Opțiunea 2, evident, nu este chiar pe opțiune, deci 1 sau 3 este.
intrare mail.log din e-mailul non-GMail hoster:
postfix/amavis/smtp[2300]: 4Gn0zh0z4FzLnSJ: to=<[email protected]>, orig_to=<[email protected]>, relay=127.0.0.1[127.0.0.1],delay=1044,delay=044 0.1/0/0.01/3.9, dsn=2.0.0, stare=trimis (250 2.0.0 de la MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: în coadă ca 4Gn0zm04JHzLxc0)
intrare mail.log din e-mailul GMail:
14 august 15:06:44 s postfix/smtpd[2281]: avertisment: problemă la convorbirea cu serverul 127.0.0.1:12340: Conexiunea a expirat
14 august 15:06:44 s postfix/smtpd[2281]: NOQUEUE: respinge: RCPT de la mail-ot1-x32b.google.com[2607:f8b0:4864:20::32b]: 451 4.3.5 <user@ dömain2.tld>: Adresa destinatarului respinsă: Problemă de configurare a serverului; de la=<[email protected]> la=<user@dömain2.tld> proto=ESMTP helo=<mail-ot1-x32b.google.com>