Puncte:1

iRedMail: aliasul de domeniu nu funcționează cu unele e-mailuri externe (diacritice/punycode)

drapel ke

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>
SnotMcBooger avatar
drapel ke
Mulțumesc pentru intrare @anx. Am adăugat jurnalele de după pornire și câteva note suplimentare. Am activat suportul SMTPUTF8 în postfix, deoarece nu a fost activat, dar, din păcate, nicio schimbare. De asemenea, am dezactivat funcțiile de cotă, dar am putut observa orice diferență de comportament. După cum se spune în postare, se pare că e-mailurile care trec sunt trimise în punycode, spre deosebire de e-mailurile gmail, care de fapt sunt trimise către domeniul care conține caracterul non-ascii. Poate că există o modalitate de a traduce asta în punycode înainte de a-l procesa în continuare?
SnotMcBooger avatar
drapel ke
Mulțumesc pentru indiciu, am revenit la setarea SMTPUTF8. Am repornit serverul complet de mai multe ori. De fapt, am repornit serverul chiar înainte de a extrage jurnalele pe care le-am adăugat la postare. Încă l-am repornit, aceleași rezultate totuși. Timeout-ul are loc numai cu e-mailurile trimise către „dömain2.ch”, prin orice alt mesaj. Chiar și cele punycode. Timeout-ul are loc la portul dovecot, dar numai atunci când este trimis un mail care conține un umlaut în domeniu, fără a fi transformat în punycode de către serverul de e-mail care trimite, de exemplu google sau hotmail. În general, serverul de schimb pare să-l transforme în slab.
Puncte:0
drapel fr
anx

Deoarece încă nu pot vedea o soluție completă (rescrierea adresei în Postfix ar putea funcționa, dar ar fi un final trist al acestei povești), îmi adun pașii de diagnosticare într-un răspuns:

  • Achiziționați efectiv configurație, cum ar fi descărcat de comenzi postfix -n și postfix -M dacă serverul de e-mail pentru a asigura o înțelegere clară a modului în care sunt integrate diferitele servicii (amavis, în primul rând).

  • Testați individual non-ASCII în partea locală, în antetele fără adresă și în nume de domenii (acolo ca etichetă A codificată prin Punycode pentru a începe ca xn--, și ca Unicode care conține direct literele non-ASCII)

  • A pastra SMTPUTF8 dezactivat în Postfix - Dovecot nu acceptă încă pe deplin gestionarea e-mailurilor care ar putea fi primite în acest fel și nu este nici necesar, nici neapărat util în rezolvarea problemelor în amavis.

  • amavis are o $log_level setare (în Debian, probabil în /etc/amavis/conf.d/) acea poate fi pus la zero ca parte a dvs iRedMail distributie.

  • Dacă aveți opțiunea de a comuta, rulați amavis ca o coadă înainte milter (în loc să fie un smtp post-coda de coadă filter) poate sau nu dezvălui o eroare sau un comportament mai util.

  • amavis a remediat unele probleme SQL+Unicode specifice mariadb după versiunea 2.11 pe care o utilizați, o eroare utilă ar putea fi în jurnalul bazei de date - sau ar putea fi exclusă prin compararea aceleiași stive configurate cu un backend postgres identic din punct de vedere funcțional (postgres nu împărtășește caracteristicile/bugurile Unicode ale MySQL&MariaDB)

anx avatar
drapel fr
anx
Sigur sper ca *nu* alta dintre acele probleme „Unicode, dar cea greșită” din nou..

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.