.png)
Nachdem ich erfolgreich einen iRedMail-Server für meine Hauptdomäne eingerichtet hatte, versuchte ich, meine sekundäre Domäne als Alias hinzuzufügen, indem ich die folgenden Schritte befolgte:https://docs.iredmail.org/sql.add.alias.domain.html
Das hat noch nicht geholfen, also habe ich die sekundäre Domäne zusätzlich zu /etc/postfix/main.cf hinzugefügt:
virtual_alias_domains = domain2.tld
virtual_alias_maps = hash:/etc/postfix/virtual
Hinweis: Ich habe keine der vorhandenen MySQL-Einträge unter virtual_alias_maps entfernt.
Und das Mapping in /etc/postfix/virtual eingetragen und anschließend "postmap /etc/postfix/virtual" ausgeführt:
@domain2.tld @domain1.tld
Dies funktioniert intern auf dem Server.[email geschützt]kann senden an[email geschützt]und Benutzer2 erhält die E-Mail in seinem Postfach. Externe E-Mails kommen auch weiterhin an, wenn sie an[email geschützt].
Bei externen Mails an die Zweitdomain funktioniert es leider nicht. In meiner /var/logs/mail.log finde ich folgende Zeilen:
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>
Und:
postfix/smtpd[5644]: warning: problem talking to server 127.0.0.1:12340: Connection timed out
Auf Port 12340 lauscht Dovecot:
dovecot 513 root 67u IPv4 17087 0t0 TCP 127.0.0.1:12340 (LISTEN)
In meinem Dovecot-Protokoll finde ich wiederholt die folgende Zeile:
dovecot: quota-status: Error: quota-status: Client sent invalid recipient address: Invalid character in path
Nach einigen weiteren Tests mit verschiedenen externen Mail-Hostern stellte ich fest, dass 2 von 4 Mails ankamen, wenn sie an die sekundäre Domain gesendet wurden. Bei GMail und Hotmail war das nicht der Fall, der Exchange meiner Firma und einige andere Web-Provider kamen durch.
Und da stecke ich fest. Ich vermute eines von zwei Dingen: Entweder habe ich einfach eine notwendige Konfiguration übersehen, was sehr wahrscheinlich ist, da ich noch nie zuvor einen Mailserver unter Debian eingerichtet habe, oder der Dovecot-Fehler wird durch meine sekundäre Domäne verursacht. Die sekundäre Domäne enthält einen Umlaut (ä/ö/ü), von dem ich weiß, dass er einige Probleme verursachen kann. Daher besitze ich die Domäne auch in ihrer Punycode-formatierten Variante. Immer wenn ich also meine sekundäre Domäne mit ihrem Umlaut zu einer Konfiguration hinzufügte, fügte ich auch die Punycode-Version davon hinzu, in der Annahme, dass dies alle diesbezüglichen Probleme lösen würde.
iRedMail/Postfix/Dovecot/wasauchimmerandersdabeiistscheintmitPunnycode/Umlautenan sich gut zu funktionieren, es scheint nur vom Absender abzuhängen, da nur die Hälfte der Mails verloren geht (der Absender erhält keine Fehlermeldung). Irgendeine Vermutung, warum das so ist oder welche Protokolle ich überprüfen könnte, um tiefer in die Sache einzudringen? Habe ich einfach vergessen, etwas Offensichtliches zu konfigurieren?
Jeder Anstoß in die richtige Richtung ist sehr willkommen.
Grüße, Snot
==== Grundlegende Informationen ====
- iRedMail-Version: 1.4.0 MARIADB-Edition
- Name und Version der Linux/BSD-Distribution: Debian GNU/Linux 10 (Buster) – 10.10
- Verwendete Datenbank: MySQL (MariaDB)
- Webserver: Nginx
==== Bearbeiten ====
Was die Basiseinrichtung betrifft: Nach einer sauberen Debian 10-Installation habe ich die Schritte in dieser Anleitung befolgthttps://www.linuxbabe.com/mail-server/debian-10-buster-iredmail-email-server
Jede spezifische Konfiguration, die von der Anleitung abweicht, wurde im Beitrag erwähnt. Ich habe zusätzlich ein Zertifikat ausgestellt, das die Hauptdomäne und die sekundäre Domäne in Punnycode enthält.
Hier die verschiedenen Protokolle beim Booten:
/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
Ich habe die Kontingentfunktionen deaktiviert und SMTPUTF8 in meiner Postfix-Main.cf aktiviert. Keine nennenswerte Änderung außer einer zusätzlichen Zeile beim Booten im 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"
Das Verhalten ist leider immer noch dasselbe. Nach weiterer Analyse der Protokolle wurde mir klar, dass es so aussieht, als würden die Mails der Anbieter, die durchkommen, per Punycode gesendet (selbst wenn ich sie ausdrücklich an die Domain mit dem Umlaut/Nicht-ASCII-Zeichen gesendet habe). GMail hingegen sendet die Mail tatsächlich an die Domain, die den Umlaut enthält (Nicht-Punycode, selbst wenn ich ausdrücklich das Punycode-Format in der Empfänger-Mailadresse verwende). Also muss ich entweder meinem Server beibringen, mit den Nicht-ASCII-Zeichen umzugehen, oder ich muss Google beibringen, per Punycode zu senden. Oder ich muss meinem Server beibringen, Umlaute in Punycode zu übersetzen. Option 2 ist offensichtlich keine wirkliche Option, also ist es 1 oder 3.
Mail.log-Eintrag von einer E-Mail, die nicht von einem GMail-Hoster stammt:
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)
mail.log-Eintrag aus GMail-Mail:
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>
Antwort1
Da ich noch immer keine vollständige Lösung sehe (die Adressumschreibung in Postfix könnte funktionieren, wäre aber ein trauriges Ende dieser Geschichte), fasse ich meine Diagnoseschritte in einer Antwort zusammen:
Erwerben Sie dieWirksamKonfiguration, wie sie beispielsweise von den Befehlen
postfix -nundpostfix -Mvom Mailserver ausgegeben wird, um ein klares Verständnis der Art und Weise sicherzustellen, wie die verschiedenen Dienste (vor allem Amavis) integriert sind.Testen Sie Nicht-ASCII-Zeichen einzeln im lokalen Teil, in Nicht-Adressheadern und in Domänennamen (dort als A-Label, das über Punycode codiert ist und wie beginnt
xn--, und als Unicode, das die Nicht-ASCII-Buchstaben direkt enthält).In Postfix deaktiviert lassen
SMTPUTF8– Dovecot unterstützt die Verarbeitung von E-Mails, die auf diese Weise empfangen werden könnten, noch nicht vollständig und ist weder erforderlich noch unbedingt hilfreich bei der Lösung von Problemen in Amavis.amavis hat eine
$log_levelEinstellung (in Debian, vermutlich in/etc/amavis/conf.d/), diekann als Teil IhreriRedMailVerteilung.Wenn Sie die Möglichkeit haben, dies zu ändern, führen Sie amavis als Vorwarteschlange ausMFilter (anstatt als Post-Queue SMTPFFilter) kann einen nützlicheren Fehler oder ein nützlicheres Verhalten aufdecken, muss es aber nicht.
amavis hat einige MariaDB-spezifische SQL+Unicode-Probleme behobennach der von Ihnen verwendeten Version 2.11 könnte ein nützlicher Fehler im Datenbankprotokoll enthalten sein - oder durch Vergleichen desselben konfigurierten Stacks mit einem funktional identischen Postgres-Backend ausgeschlossen werden (Postgres verfügt nicht über die gleichen Unicode-Funktionen/-Fehler wie MySQL&MariaDB)