risc2000
Goto Top

E-Mail Versand per SMTP funktioniert nicht mit Postfix und saslauthd

Hallo, ich versuche gerade einen Mail Server auf einem Debian 3.1 Server aufzusetzen. Der Server wird mittels mehrere Dienste realisiert, courier, postfix, mysql etc... Grundsätzlich funktioniert er bereits, also er nimmt E-Mails von anderen Servern entgegen und es ist möglich diese E-Mails per pop3 vom Server zu holen. Es gelingt mir aber nicht Mails per SMTP mit diesem Server zu versenden. Das Problem scheint an der Authentifizierung am Server zu liegen. Wenn ich versuche eine Mail vom Clienten zum Server zu senden, erhalte ich folgende Ausgaben in den Logdateien des Servers.

  • /var/log/mail.log *

warning: SASL authentication failure: Password verification failed
warning: [80.211.21.33]: SASL PLAIN authentication failed: authentication failure
warning: [80.211.21.33]: SASL LOGIN authentication failed: authentication failure

  • Ausgaben von saslauthd im Debugmodus *

saslauthd[18371] :rel_accept_lock : released accept lock
saslauthd[18372] :get_accept_lock : acquired accept lock
saslauthd[18371] :cache_get_rlock : attempting a read lock on slot: 499
saslauthd[18371] :cache_lookup : [login=info] [service=] [realm=smtp]: not found, update pending
saslauthd[18371] :cache_un_lock : attempting to release lock on slot: 499
saslauthd[18371] :do_auth : auth failure: [user=info] [service=smtp] [realm=] [mech=pam] [reason=PAM auth error]

Benutzer und Passwort existieren, da ja POP3 auch funktioniert. Ich sollte vielleicht noch erwähnen, das es sich um einen virtuellen E-Mail Server handelt, d.h. Benutzernamen und Passwörtern werden nicht im System sondern in einer MySQL Datenbank gespeichert.

Merkwürdig finde ich auch, das testsaslauthd schon nicht funktioniert.

  1. testsaslauthd -u info -p test
0: NO "authentication failed"

Wie gesagt der User info existiert in der DB und bei POP funktioniert es.

Dies ist meine /etc/postfix/sasl/smtpd.conf,

pwcheck_method: saslauthd
auxprop_plugin: sql
mech_list: PLAIN LOGIN
log_level: 9
saslauthd_path: /var/run/saslauthd/mux
autotransition: true
allow_plaintext: true
sql_engine: mysql
sql_hostnames: 127.0.0.1
sql_user: mailadmin
sql_passwd:
sql_database: mailserver
sql_select: select password from users where email='%u@%r'


Ich habe den Eindruck, dass diese ignoriert wird, da sich Veränderungen in dieser nicht Auswirken. Fall jemand eine Idee hat, würde ich mich freuen, denn ich komm erstmal nicht weiter.

Content-ID: 63247

Url: https://administrator.de/contentid/63247

Ausgedruckt am: 22.11.2024 um 22:11 Uhr

cykes
cykes 07.07.2007 um 16:57:15 Uhr
Goto Top
Hi,

spontan würde ich mal sagen, dass diese Zeile des Rätsels Lösung ist:

sql_select: select password from users where email='%u@%r'

Probier doch mal, Dich beim SMTP Server mit der kompletten Email Adresse info@Domain als User
anzumelden.

Gruß

cykes
risc2000
risc2000 07.07.2007 um 17:19:46 Uhr
Goto Top
@cykes, Danke habe ich schon probiert funktioniert aber noch nicht. Der Tipp mit der DB Abfrage könnte mich weiter bringen. Mir ist noch folgendes aufgefallen.

info@domain.de als User

/var/log/mail.log => warning: SASL authentication failure: incorrect digest response


nur info als user

/var/log/mail.log => warning: SASL authentication failure: no secret in database


###[Edit]###

Also, ich habe jetzt mal die Logdateien des MySQL Servers aktiviert, und etwas interessantes Festgestellt.

beim Versuch E-Mails per SMTP zu versenden werden 2 Abfragen durchgeführt. Auszug aus /var/log/mysql/mysql.log

42 Query select password from users where email='info@domain.de'
44 Query SELECT password FROM users WHERE email = 'info'

Die erste Abfrage entspricht der aus /etc/postfix/sasl/smtpd.conf, diese Ist richtig und liefert damit auch das Passwort zurück. Das Problem ist die Zweite Abfrage, da
dort '@domain.de' fehlt und somit kein Passwort zurückgeliefert werden kann. Ich konnte jetzt mein Problem lösen, in dem ich in der Datenbank
einfach ein Zweiten Eintrag hinzugefügt habe:

[email] [password]
info@domain.de
info

Damit liefert die Zweite Abfrage auch das Passwort zurück, und nun können endlich E-Mails per SMTP versendet werden. Ich kann mit diesem Kompromiss leben, aber mich
würde doch interessieren, wie diese Zweite Abfrage zustande kommt.
cykes
cykes 08.07.2007 um 08:40:49 Uhr
Goto Top
Hmm, kann es vielleicht sein, dass auf Clientseite irgendwas wie POP before SMTP eingeschaltet
ist und deswegen 2 Abfragen kommen?