PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : PostFix: smtp auth



Stiftmaster
28.09.08, 12:38
Hallo,

momentan bin ich dabei, einen Mail-System (PostFix, Courier, MySQL) unter SuSE 11.0 einzurichten und stoße dabei immer mal wieder auf kleinere Problemchen. Momentan hänge ich am Versenden von E-Mails. Hier habe ich mich an folgendem HowTo orientiert: http://www.howtoforge.de/howto/virtuelle-benutzer-und-domains-mit-postfix-courier-und-mysql-ubuntu-710/4/

ich kann mich von einem externen Rechner per Telnet verbinden. Dann gebe ich als erstes ehlo localhost ein. Dann erhalte ich folgende Ausgabe:


220 mail.DOMAIN.de ESMTP Postfix
ehlo localhost
250-mail.DOMAIN.de
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Soweit so gut dachte ich mir. Wenn ich mich dann aber einloggen möchte, klappt dies leider nicht. Dann habe ich geschaut, was in dem und anderen Tutorials dazu steht und ich finde immer wieder, eine andere Reihenfolge bei der Auth-Zeile, nämlich


250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN

Daher die Frage: liegt das daran und wieso ist bei mir die Reihenfolge falsch bzw. anders? Oder ist das sogar egal, in welcher Reihenfolge die stehen?

Noch mal zum Login: Hier muss ich ja die Benutzer-Passwort-Kombination in Base64 Format angeben. Diese habe ich mir wie folgt erzeugt:


printf 'MeinBenutzername\0MeinBenutzername\0MeinPasswort' | mmencode

Allerdings ralle ich nicht, wieso ich zwei Mal meinen Benutzername angeben muss. Sehe ich das richtig, dass \0 einfach nur Platzhalter/Trenner sind?

Ich habe ebenso die Logs meiner MySQL-Datenbank während des Logins angeschaut (weil ich mich ja gegen eine MySQL-Datenbank authentifizieren möchte). Hier kommt nicht ein SQL Befehl an.

Hat jemand einen Tipp auf Lager, woran dies hängen könnte bzw. wie ich raus kriegen kann, woran es hängt?

Vielen Dank für eure Mühen

Stefan

Roger Wilco
28.09.08, 12:54
Die Reihenfolge der Authentifizierungsmechanismen ist für dich egal. Das soll dem Client einfach einen Vorschlag unterbreiten, welchen Mechanismus er zuerst benutzen soll.

Und die "\0" sind ASCII-Zeichen, die als Feldtrenner verwendet werden (nullterminierte Strings eben).

Stiftmaster
28.09.08, 13:03
Hi,

danke - aber: Ich habe ja nur einen Vorschlag - nämlich PLAIN - und das steht halt mal hinter und mal vor LOGIN, oder ist LOGIN auch nur ein Auth.-Mechanismus?

OK - das mit den ASCII-Zeichen hab ich mir schon gedacht. Aber wieso muss ich dann zwei Mal den gleichen Benutzernamen eingeben oder liegt dort eventuell ein Verständnis-Problem vor?

Vielen Dank

Stefan

Stiftmaster
28.09.08, 13:12
Hi,

google hat mir gerade schon bisschen geholfen. LOGIN und PLAIN sind beides Auth.Mechanismen nur wird des etwas anders übertragen. Soweit sogut. Habe mich zum testen jetzt auf LOGIN fokussiert.

Hier gehe ich ja wie folgt vor:
1) telnet mail-server 25
2) ehlo localhost
3) auth login
4) Benutzername Base 64 kodiert (printf 'benutzer@domain.de' | mmencode)

Dann erhalte ich direkt:
535 5.7.8 Error: authentication failed: generic failure

MySQL erhält nicht eine SQL-Abfrage. Gehe ich dann richtig der Annahme, dass ich by sasl2 schauen muss? In der Datei /etc/sasl2/smtpd.conf kann ich nämlich keinen Fehler finden. Hier die Datei:


pwcheck_method: saslauthd
mech_list: login plain
allow_plaintext: true
auxprop_plugin: mysql
sql_hostnames: localhost
sql_user: mail
sql_passwd: *geheim*
sql_database: mail
sql_select: select password from users where email = '%u'


Danke für eure Hilfe.

Stefan

Roger Wilco
28.09.08, 13:16
Aber wieso muss ich dann zwei Mal den gleichen Benutzernamen eingeben oder liegt dort eventuell ein Verständnis-Problem vor?
Weil das nunmal das Format ist, in dem der MTA bzw. die SASL-Bibliothek die Zugangsdaten haben möchte.


4) Benutzername Base 64 kodiert (printf 'benutzer@domain.de' | mmencode)
Wie kommst du darauf, dass das so funktioniert? Nimm wieder das richtige Format.

Stiftmaster
28.09.08, 13:27
Hi,

danke für deinen Beitrag. Wie ich darauf komme: http://de.wikipedia.org/wiki/SMTP-Auth (Beispiel)

Ich will ja LOGIN machen und dort muss ich doch erst den Benutzername angeben und anschließend das Passort, oder sehe ich das falsch? Mittlerweile scheint das auch zu klappen - hatte n' Dreher im System beim Benutzername (sorry für die Verwirrung).

Wenn ich jetzt also (wie oben) den Benutzername und dann danach das Passwort base64 codiert eingebe, dann bekomme ich anschließend auch eine MySQL-Abfrage in den Logs zu sehen, die lautet:

SELECT password FROM users WHERE email = 'benutzername'

Allerdings müsste dort benutername@domain.de stehen - denn sonst kann er den Eintrag nicht in der Datenbank finden. Irgendwo geht also das @domain.de verlohren, nur weiß ich noch nicht wo...

Einen Tipp auf Lager?

Dankend

Stefan

Roger Wilco
28.09.08, 13:34
Probier es mit \@ anstatt @.

Stiftmaster
28.09.08, 14:09
Hi,

das ganze wird natürlich in der Datei /etc/pam.d/smtp eingestellt. Hier sieht die config wie folgt aus:


auth required pam_mysql.so user=mail passwd=XX host=localhost db=mail table=users usercolumn=email passwdcolumn=password crypt=1
account sufficient pam_mysql.so user=mail passwd=XX host=localhost db=mail table=users usercolumn=email passwdcolumn=password crypt=1


Egal ob ich benutzername@domain.de oder benutzername\@domain.de eingebe - es wird immer nur der Benutzername in der SQL-Abfrage übergeben; beim ersten benutzername und beim zweiten benutzername\\

Das ist doch leicht zum verrückt werden :-) Noch n' Tipp auf Lager?

Dankend

Stefan

Stiftmaster
28.09.08, 14:47
Hi,

wenn ich beim Versand kurzfristig benutzername@domain.de in benutzername ändere, dann klappt das Versenden einwandfrei - nur blöd, dass des mit dem Login net klappt - wieso schneidet der bloß das @domain.de weg???

Bin immer noch dankbar für jeden Tipp. Bis dahin

Stefan

Stiftmaster
28.09.08, 22:15
Hi,

ich bin wohl nicht alleine mit dem Problem, wie man aus folgendem Beitrag sieht:
http://forums.vpslink.com/ubuntu/2351-saslauthd-wont-send-domain-realm-mysql.html

Allerdings gibt's auch schon eine Lösung, bei OPTIONS ein -r anfügen. Allerdings exisiertiert bei mir die Datei "/etc/default/saslauthd" gar nicht. Ebenso habe ich das gesamte /etc Verzeichnis nach OPTIONS abgesucht und keinen passenden Eintrag gefunden.

Wo um alles in der Welt ist die passende Config dafür unter SuSE 11.0. Die kann sich doch nicht einfach versteckt haben... Ich bin fest davon überzeugt, dass dies mein Problem löst. Bin also für jeden Tipp dankbar!

Bis dahin

Stefan

Roger Wilco
28.09.08, 22:32
Schau im Initskript von saslauthd nach, welche Datei als Konfiguration übergeben wird bzw. ob und falls ja aus welcher Datei zusätzliche Parameter für den Aufruf bezogen werden.

Stiftmaster
29.09.08, 09:03
Hi,

danke für deinen Beitrag. In diese Richtung habe ich mittlerweile auch schon geforscht, bin aber da auch noch nicht groß weiter gekommen. Das Start-Script von saslauthd habe ich unter /etc/init.d/saslauthd ausfindig gemacht. Der Inhalt sieht wie folgt aus:


#! /bin/sh
# Copyright (c) 2002 SuSE Linux AG Nuernberg, Germany.
#
# Author: Carsten Hoeger <choeger@suse.de>
#
# /etc/init.d/saslauthd
#
### BEGIN INIT INFO
# Provides: saslauthd
# Required-Start: $network $remote_fs
# Required-Stop:
# Default-Start: 3 5
# Default-Stop:
# Description: start the cyrus-sasl2 auth daemon
### END INIT INFO


AUTHD_BIN=/usr/sbin/saslauthd
test -x $AUTHD_BIN || exit 5

SASLAUTHD_AUTHMECH=pam
SASLAUTHD_THREADS=5
test -f /etc/sysconfig/saslauthd && . /etc/sysconfig/saslauthd

# Shell functions sourced from /etc/rc.status:
# rc_check check and set local and overall rc status
# rc_status check and set local and overall rc status
# rc_status -v ditto but be verbose in local rc status
# rc_status -v -r ditto and clear the local rc status
# rc_failed set local and overall rc status to failed
# rc_failed <num> set local and overall rc status to <num><num>
# rc_reset clear local rc status (overall remains)
# rc_exit exit appropriate to overall rc status
. /etc/rc.status

# First reset status of this service
rc_reset

# Return values acc. to LSB for all commands but status:
# 0 - success
# 1 - generic or unspecified error
# 2 - invalid or excess argument(s)
# 3 - unimplemented feature (e.g. "reload")
# 4 - insufficient privilege
# 5 - program is not installed
# 6 - program is not configured
# 7 - program is not running
#
# Note that starting an already running service, stopping
# or restarting a not-running service as well as the restart
# with force-reload (in case signalling is not supported) are
# considered a success.

case "$1" in
start)
echo -n "Starting service saslauthd"
## Start daemon with startproc(8). If this fails
## the echo return value is set appropriate.

# NOTE: startproc return 0, even if service is
# already running to match LSB spec.
/sbin/startproc $AUTHD_BIN -a $SASLAUTHD_AUTHMECH -n $SASLAUTHD_THREADS > /dev/null 2>&1

# Remember status and be verbose
rc_status -v
;;
stop)
echo -n "Shutting down service saslauthd"
## Stop daemon with killproc(8) and if this fails
## set echo the echo return value.

/sbin/killproc -TERM $AUTHD_BIN > /dev/null 2>&1

# Remember status and be verbose
rc_status -v
;;
try-restart)
## Stop the service and if this succeeds (i.e. the
## service was running before), start it again.
## Note: try-restart is not (yet) part of LSB (as of 0.7.5)
$0 status >/dev/null && $0 restart

# Remember status and be quiet
rc_status
;;
restart)
## Stop the service and regardless of whether it was
## running or not, start it again.
$0 stop
$0 start

# Remember status and be quiet
rc_status
;;
force-reload)
## Signal the daemon to reload its config. Most daemons
## do this on signal 1 (SIGHUP).
## If it does not support it, restart.

echo -n "Reload service saslauthd"
## if it supports it:
#/sbin/killproc -HUP $AUTHD_BIN
#touch /var/run/FOO.pid
#rc_status -v

# Otherwise:
$0 stop && $0 start
rc_status
;;
reload)
## Like force-reload, but if daemon does not support
## signalling, do nothing (!)

echo -n "Reload service saslauthd"
# If it supports signalling:
#/sbin/killproc -HUP $AUTHD_BIN
#touch /var/run/FOO.pid
#rc_status -v

# Otherwise if it does not support reload:
rc_failed 3
rc_status -v
;;
status)
echo -n "Checking for service saslauthd: "
## Check status with checkproc(8), if process is running
## checkproc will return with exit status 0.

# Status has a slightly different for the status command:
# 0 - service running
# 1 - service dead, but /var/run/ pid file exists
# 2 - service dead, but /var/lock/ lock file exists
# 3 - service not running

# NOTE: checkproc returns LSB compliant status values.
/sbin/checkproc $AUTHD_BIN
rc_status -v
;;
*)
echo "Usage: $0 {start|stop|status|try-restart|restart|force-reload|reload}"
exit 1
;;
esac
rc_exit

Leider kann ich daraus nicht feststellen, wie ich weiter machen soll. Habt ihr eventuell eine Idee?

Dankend

Stefan

Stiftmaster
29.09.08, 10:09
Hi,

es geht nun endlich - es lag an dem StartScript. Das "-r" muss im Bereich start wie folgt eingebaut werden:

/sbin/startproc $AUTHD_BIN -r -a $SASLAUTHD_AUTHMECH -n $SASLAUTHD_THREADS > /dev/null 2>&1

An anderen Stellen (z.B. am Ende) hat es keine Auswirkung. An dieser Stelle klappt dies ohne Probleme. Ich bin begeistert - es läuft!

Bis dahin

Stefan