[Postfixbuch-users] Re: SASL/auxprop mag nicht mit/etc/postfix/sasl_passwd.db

[Olaf Lautenschlaeger]

On Wednesday, June 18, 2008 11:41 AM [GMT+1=CET],
Patrick Ben Koetter <p at state-of-mind.de> wrote:

>>> sasldb ist schon ein guter Start. Was fehlt Dir noch?
>>
>> Postfix/local_recipient_maps soll dann eben dort nachschlagen.
>
> Ja, was soll es denn dort nachschlagen?

Ähm, was habe ich denn hieran falsch verstanden:
local_recipient_maps guckt nach, ob der Teil links vom "@" bei Adressen
mit lokal zustellbaren Domains auf dem System bekannt ist. Nachgucken,
ob ein String in einer Liste steht (von Authentifizierung soweit überhaupt-
garkeine Rede).

Lt. Docs, so wie ich sie gestern gelesen habe,  liest  "l_r_m = hash:file"
die linke Seite von einer ansonsten beliebigen Tabelle, die nur eine
Struktur wie "user irgendwas" haben sollte.

> Wenn local_recipient_maps
> Authentifizierungsdaten nachschlagen soll, ist es schlicht und
> ergreifend falsch.

Was bitte macht l_r_m denn anderes, sofern noch Postfix-Defaults
eingestellt sind?!

"l_r_m = proxy:unix:passwd.byname" liest aus "/etc/postfix" (evtl.
sogar aus einer beliebigen anderen von PAM verwalteten Account-DB?),
lt. Postfix-Doc wird hierbei sogar (überflüssigerweise) der gesamte
Record aus der passwd übergeben und nicht nur die linke Seite
(mglw. also sogar die kompletten Credentials, falls mal auf einem
System noch ohne shadow-Passwörter?)

Sind das was anderes als Authentifizierungsdaten?

Und macht es irgendeinen Sinn (ausser 150%iger Sicherheit), diese
Liste physisch getrennt von der Authentifizierungs-DB vorzuhalten,
anstelle einfach die linke Seite von einer ohnehin vorhandenem
Tabelle auszulesen?

(oder willst Du mir nur sagen, dass die Festung Postfix auf gar keinen
Fall jemals auch nur in die Nähe von diesen ach so sensiblen Authen-
tifizierungsdaten gebracht werden darf? - Spaß beiseite... )

> Authentifizierungsdaten werden entweder von der Dovecot SASL
> Implementierung oder vom Cyrus SASL Framework nachgeschlagen.

Bedeutet denn nicht, dass die SASL-Settings "pwcheck_method: auxprop"
und "auxprop_plugin: sasldb" bewirken, dass
a) PAM aussen vor bleibt und somit auch
b) "proxy:unix:passwd.byname" ins Leere laufen würde, wenn
meine Mail-User keine System-Accounts haben?

Und wird nicht l_r_m vom local-Service und nicht vom SMTP[D] aus-
gewertet, so dass auch die Konfiguration in "/etc/sasl2/smtpd.conf"
hierfür irrelevant ist?

Also brauche ich eine Alternative zu "proxy:unix:passwd.byname"?!

>> Ausserdem hätte ich diese User-DB gern mit Postmap gepflegt.
>
> Das scheint mir das Motiv schlechthin zu sein.

Eigentlich möchte ich nur schnell in die Puschen kommen (dazu ist
es allerdings längst zu spät) und einen Mailserver möglichst nahtlos
migrieren.
Ein paar 10 kryptische (!)Passwörter möchte man auch nur
einmal irgendwo eintippen.
Es ist mir bewußt, dass ich mich mit der Materie insgesamt schwer
tue. Ich möchte aber etwas dazulernen und mich deshalb mit Wissenden
austauschen - das kommt mir hier, ehrlich gesagt, aber ein bisschen
kurz.

> Also:
> Authentifizierungsdaten werden nicht von Postfix und deshalb auch
> nicht von postmap gepflegt.

Gepflegt werden müssen sie VON MIR.
Warum nicht mal mit Postmap, wenn es sich (scheinbar) anbietet.
Ein Tool, welches (BDB-kompatible, hoffentlich?!) Maps generiert.

> Cyrus SASL bietet dazu für sasldb die Tolls saslpasswd2 und
> sasldblistusers2 an. Dovecot von Hand oder je nach Backend.

Jahaa. Ich geh' ja jetzt wieder brav zurück zu "/etc/sasldb2".

>> Aus ./cyrus-sasl/doc/readme.html (Read Me First):
>>
>> "The library also supports storing user secrets in either a hash
>> database (e.g. Berkeley DB, gdbm, ndbm), LDAP, or in a SQL database
>> (MySQL, Postgres)."
>>
>> Ich würde schon gerne mal jemandes Meinung hören, ob meine Vermutung
>> richtig ist, dass wahrscheinlich doch sasldb2<>BDB ist.
>
> Ja, das ist es. Mit db_dump etc. kannst Du Dein Ziel auf Deine Weise
> sicherlich erreichen.

Aah, DANKE! Das war jetzt wirklich das erste Mal, dass ich hier eine
Antwort auf eine von mir gestellte Frage bekommen habe :-)

Aber - soviel dann auch zum Thema Dokumentation.
Nein, hier noch was:

$ man db_dump
No manual entry for db_dump

Beste Grüße

Olaf Lautenschläger
--
ANOVA Multimedia Studios GmbH

fon: (+49) (0) 381 / 40 59 - 550
fax: (+49) (0) 381 / 40 59 - 551
web: www.anova.de
corporate e-mail: info at anova.de
_______________________________________

ANOVA Multimedia Studios GmbH

Geschaeftsfuehrer:
Prof. Dr. Hansgeorg Meissner,
Michael Kaeding,
Dr. Volker Gries

Firmensitz:
Joachim-Jungius-Strasse 10,
D-18059 Rostock / Germany

Registergericht:
Amtsgericht Rostock

Handelsregisternummer:
HRB 2788

UST-IdNummer:
DE 811577650

(footer size due to legal demands applying under german law)