Ich habe die ISPMail-Tutorials auf workaround.org (die Wheezy-Version 2.9) befolgt und bisher hat alles gut funktioniert. Als ich den Schritt „E-Mail-Zustellung testen“ erreichte, bemerkte ich einen Fehler bezüglich der Abfrage im Ausgabeprotokoll von /var/log/mail.log.
May 14 06:48:59 mail postfix/pickup[17704]: EA4AD240A98: uid=0 from=<root>
May 14 06:48:59 mail postfix/cleanup[17776]: EA4AD240A98: message-id=<[email protected]>
May 14 06:48:59 mail postfix/qmgr[17706]: EA4AD240A98: from=<[email protected]>, size=429, nrcpt=1 (queue active)
May 14 06:49:00 mail dovecot: auth-worker(17782): mysql(127.0.0.1): Connected to database mailserver
May 14 06:49:00 mail dovecot: auth-worker(17782): Warning: mysql: Query failed, retrying: Table 'mailserver.users' doesn't exist
May 14 06:49:00 mail dovecot: auth-worker(17782): Error: sql([email protected]): User query failed: Table 'mailserver.users' doesn't exist (using built-in default user_query: SELECT home, uid, gid FROM users WHERE username = '%n' AND domain = '%d')
May 14 06:49:00 mail dovecot: lda([email protected]): msgid=<[email protected]>: saved mail to INBOX
May 14 06:49:00 mail postfix/pipe[17780]: EA4AD240A98: to=<[email protected]>, relay=dovecot, delay=0.09, delays=0.03/0.01/0/0.06, dsn=2.0.0, status=sent (delivered via dovecot service)
May 14 06:49:00 mail postfix/qmgr[17706]: EA4AD240A98: removed
Ich fand es ziemlich interessant, dass die Datenbank nicht gefunden wird. Ich bin also noch einmal alles durchgegangen und habe JEDE Datei geprüft, die ich berührt habe und die mit der Datenbank zu tun hatte (einschließlich der Postfix-CF-Dateien). Alles ist korrekt. Daher bin ich an diesem Punkt verblüfft, aber seltsamerweise scheint die E-Mail dennoch das richtige Ziel in /var/vmail/domain.com/ erreicht zu haben.
Sollte ich mir darüber Sorgen machen oder übersehe ich hier etwas? Da es sich um eine Nachricht von Dovecot handelt, wäre es die Abfrage von dovecot-sql.conf.ext, die ich hier einfüge
driver = mysql
connect = host=127.0.0.1 dbname=mailserver user=blocked password=***REMOVED***
default_pass_scheme = PLAIN-MD5
password_query = SELECT email as user, password FROM virtual_users WHERE email='%u';
Antwort1
Wie in Ihrem Mail.log steht, ist der Wert für user_query nicht definiert. Aus diesem Grund greift Dovecot auf die Standardabfrage zurück.
Öffnen Sie Ihre Konfigurationsdatei /etc/dovecot/dovecot-sql.conf.ext. Der Wert für user_query ist höchstwahrscheinlich auskommentiert oder leer. Füllen Sie ihn mit einer geeigneten Abfrage.
Wenn Sie wie ich für alle Mailkonten (sagen wir 5000) die gleiche UID und GID verwenden, können Sie ganz einfach Folgendes tun:
user_query = SELECT ('5000') as 'uid',('5000') as 'gid'
Noch etwas, das mir in Ihrer Konfigurationsdatei aufgefallen ist. Vermeiden Sie besser die Verwendung von PLAIN-MD5 als Standardpasswortschema. Wechseln Sie besser zu etwas Stärkerem wie SHA512.
Ich hoffe, meine Antwort ist hilfreich für Sie. Prost!
Antwort2
verwenden Sie nano oder vi (nano speichern = Strg+o, dann beenden = Strg+x) vi speichern = Einfügen-Taste und Esc-Taste, dann :wq! Eingabe Es wird gespeichert und beendet.
/etc/dovecot/conf.d/auth-sql.conf.ext
...
passdb {
driver = sql
args = /etc/dovecot/dovecot-sql.conf.ext
}
...
userdb {
driver = static
args = uid=vmail gid=vmail home=/home/vmail/%d/%n/Maildir
}
Kommentieren Sie den UserDB-Abschnitt mit dem SQL-Treiber aus:
#userdb {
#driver = sql
#args = /etc/dovecot/dovecot-sql.conf.ext
#}
systemctl restart dovecotund es sollte funktionieren.
Das Problem besteht darin, dass der UserDB-Treiber verwendet wird sqlund in der Datenbank nach der Tabelle sucht users, diese Tabelle jedoch nicht existiert.
Dies ist ein Problem mit einem beliebten Tutorial, von dem ich viele Variationen im Internet gefunden habe (welche ist die Originalversion? Ich weiß es nicht). Dieses Tutorial erklärt nicht, dass die userdb-Zeilen auskommentiert werden sollten, es enthält nur Anweisungen zum Hinzufügen oder Ändern von Zeilen in Konfigurationsdateien. Das Tutorial verwendet MariaDB oder MySQL für virtuelle Benutzertabellen. In diesem Fall benötigen wir nur driver = sqldie passdb, die zu führt dovecot-sql.conf.ext, die eine ordnungsgemäße Abfrage an die Datenbank für das Passwort und eine statische Möglichkeit zum Abrufen des Homedir enthält.
Ich habe dies auf meinem Server mit den Einstellungen getestet, die meiner Meinung nach sein sollten, nachdem ich das gefundene Tutorial gelesen hatte (ich glaube, Sie haben dasselbe Tutorial verwendet), und ich hatte ein ähnliches Problem. Ich habe meine Postfix- und Dovecot-Einstellungen auf meinem eigenen Server einfach drei- oder sogar viermal überprüft und diese Lösung hat das Problem gelöst. Ich habe Dovecot und Postfix zusammen mit Clamav, Spamassassin und Postgrey konfiguriert. Alles funktioniert ziemlich hervorragend, aber ich habe insgesamt über 40 Stunden damit verbracht, jede einzelne Zeile in den Dovecot- und Postfix-Konfigurationsdateien Schritt für Schritt zu überprüfen.
Bearbeitet 22. März 2019
Ich habe ein Buch gelesen, in dem es eine andere Erklärung für den Pam-Treiber gibt.
In der Datei /etc/dovecot/conf.d/10-auth.conf gibt es am Ende eine Zeile:
!include auth-system.conf.ext
In der Datei /etc/dovecot/conf.d/auth-system.conf.ext gibt es einen standardmäßig auskommentierten Abschnitt, der wie dieser aussieht.
#passdb {
#driver = pam
# [session=yes] [setcred=yes] [failure_show_msg=yes] [max_requests=<n>]
# [cache_key=<key>] [<service name>]
#args = dovecot
#}
#userdb {
# <doc/wiki/AuthDatabase.Passwd.txt>
#driver = passwd
# [blocking=no]
#args =
#override_fields = home=/home/virtual/%u
#}
Wenn Sie anstelle der manuell in der Datenbank erstellten Konten ein statisches lokales Konto verwenden möchten (ich habe keine automatische Möglichkeit gefunden, Massen-E-Mail-Konten in MariaDB einzufügen), sollte Ihr Code in /etc/dovecot/conf.d/auth-system.conf.ext wie folgt geändert werden:
passdb {
driver = pam
# [session=yes] [setcred=yes] [failure_show_msg=yes] [max_requests=<n>]
# [cache_key=<key>] [<service name>]
#args = dovecot
}
userdb {
# <doc/wiki/AuthDatabase.Passwd.txt>
driver = passwd
# [blocking=no]
#args =
#override_fields = home=/home/virtual/%u
}
Dies ist eine wirklich kurze Erklärung. Dovecot kann eine SQL-Datenbank verwenden, in der Sie Benutzer erstellen, oder es kann PAM verwenden, um lokale Benutzerkonten im System zu authentifizieren. Es hängt nur vom Administrator ab, welche Methode gewählt wird. Meiner Meinung nach ist SQL viel sicherer als PAM und /etc/shadow, denn wenn Sie einen Benutzer in MySQL/MariaDB erstellen möchten, können Sie SHA wählen, wie im folgenden Beispiel:
INSERT INTO Users_tbl (DomainId, password, Email) VALUES (1, ENCRYPT('yourdifficultpasswordphrase', CONCAT('$6$', SUBSTRING(SHA(RAND()), -16))), '[email protected]');
Und dann:
nano /etc/dovecot/dovecot-sql.conf.ext
driver = mysql
connect = host=localhost dbname=yourdbname user=dbuser
password=yourdifficultpassword
default_pass_scheme = SHA512-CRYPT
password_query = SELECT Email as User, password FROM Users_tbl WHERE
Email='%u';
SHA-512 erledigt den Job. Natürlich ist das eine sehr kurze Erklärung, aber ich hoffe, sie erklärt den Unterschied und warum SQL die bessere Wahl ist.
Antwort3
Dovecot sucht nach einer Tabelle mit dem Namen, userswährend Sie scheinbar Daten in virtual_usersder Tabelle haben:
Query failed, retrying: Table 'mailserver.users' doesn't exist
Benennen Sie die Tabelle um oder konfigurieren Sie Dovecot für die Verwendung virtual_usersder Tabelle.
Antwort4
Dies ist keine genaue Antwort, könnte aber für Ihr Problem relevant sein, sodass neue Besucher die Fehlerbehebung durchführen können. Siehe den Link unten.