Treebeard wrote:
Damit kann man zwar die gleiche User in mehreren Domains anlegen, aber die Cyrusverwaltung der User sieht sie als eine Domain mit vielen Usern, nicht als mehrere Domains mit internen Usern.
So wie ich das verstanden habe, wird ein System mit einer Domain als "lokale Domain" verstanden. Wenn das System für mehr als eine Domain zuständig sein sollte, werden zusätzlich zu der einen lokalen auch virtuelle Domains eingerichtet.
Nein, eine lokale Domain ist eine Domain in mydestination. diese sucht gültige Useradressen in /etc/passwd und /etc/aliases (sucht also lokale Systemuser) und verwendet den Delivery Agent "local" zur Auslieferung von Mails. Default ist dabei die Ablage in /var/spool/mail/username. Es hat nichts mit der Anzahl der Domains zu tun, sondern mit der Behandlung, wo sie ausgeliefert wird (lokal auf dem Server) und wo die User abgelegt sind.
Könnten nicht alle Domains (also auch die erste) als virtuelle Domains eingerichtet werden? Oder hängt das mit der Zustellung zusammen? Alle Domains sollten gleichwertig behandelt werden. Oder muß eine Domain als "Hauptdomain" angegeben werden?
Ja, du kannst alle Domains als virtuelle Domains anlegen.
Ich denke, ich benötige für die user auch keine gemeinsame Umgebung, d.h. alle könnten in virtuelle Domains abgelegt werden. Ergeben sich daraus irgendwelche Nachteile (z.B. bei der Administration, Anlegen der Benutzer o.ä./Mehraufwand)?
Nein, die Struktur ist nicht unbedingt aufwendiger. Man muss jedoch wissen, dass einige Sachen bei virtuellen Domains nur mit Klimmzügen bzw. gar nicht möglich sind. Dies gilt zum Beispiel für Include-Dateien von Aliases oder der Übergabe der Mail an einen Pipe-Befehlsalias. Dies ist z.B. für Mailinglisten häufig nötig. Ansonsten ist die Verwaltung nicht viel aufwendiger. Du musst bei einer virtuellen Mailbox-Domain folgendes angeben: - die Email-Adresse in virtual_mailbox_maps und als Wert die Mailboxadresse - Wenn die Mail an Cyrus weitergegeben soll, muss der Transport für die Domain gesetzt werden. Sind alle virtuellen Domains in Cyrus, kannst du direkt den virtual_transport auf Cyrus setzen.
cyrus-sasl-login wird mir per yast nicht angeboten. Steckt das in einem anderen Paket drin? Oder muss das per Hand installiert werden?
Nein, das sollte wirklich bei der Distro dabei sein. Ist es aber nicht. Habe in yast mit der Suche alles abgesucht. Ich werde wohl darauf veruciten müssen.
Grmpf, ich meinte ja LOGIN. Nimm das LOGIN solange aus der Liste der Mechanismen heraus, wie du Login nicht installiert hast. Okay, Login ist herausgenommen.
# cat /usr/lib64/sasl2/smtpd.conf pwcheck_method: saslauthd mech_list: plain
Habe es auch aus der /etc/imapd.conf herausgenommen.
OK.
Du hast in /etc/nsswitch.conf nis in passwd/user/group gesetzt. Nimm das mal raus.
Die /etc/nsswitch.conf sieht bei mir so aus:
# passwd: files nis # shadow: files nis # group: files nis
passwd: compat group: compat
hosts: files dns networks: files dns
services: files protocols: files rpc: files ethers: files netmasks: files netgroup: files nis publickey: files
bootparams: files automount: files nis aliases: files
Habe die NIS-Einträge bei netgroup und automount mal entfernt, hat aber keine Änderungen gebracht. Oder muss ein Dienst danach neu gestartet werden?
Wahrscheinlich der nscd (name server caching daemon).
Ist diese Einstellung wichtig?
Nein, es ist nur eine Warnmeldung.
BTW, wenn ich versuche die Manpage zu nsswitch.conf zu öffnen, erhalte ich eine "No manual entry for nsswitch.conf"-Meldung. Ist scheinbar nicht installiert, obwohl in der nsswitch.conf steht # For more information, please read the nsswitch.conf.5 manual page.
Kein Kommentar. (^-^) Über solche Sachen stolpert man manchmal. Teils, weil die Hilfedateien in einem getrennten Paket zur Verfügung gestellt werden, teils weil einfach ein Bug in der Dokumentation ist.
Es wird scheinbar etwas zurückgebounced. Ich vermute, dass ich Postfix jetzt beibringen muss, wohin info_wdr_de geschickt werden sollte. Wahrscheinlich eine Einstellung im mydestination-Parameter.
Jein, du hast die Mail nur an den usernamen geschickt. Verwende mal die vollständige Emailadresse info_wdr_de@tux.domain1.de.
Postfix verwendet den Wert von $myorigin, um FQDN Adressen zu machen. Setze mal
postconf -e "myorigin = $mydomain" postfix reload
Dann werden unvollständig Adressen mit "tux.domain1.de" vervollständigt.
Dann schicke noch einmal eine Mail los. Prima, klappt jetzt. Mail lässt sich nun auch vom remote Client aus abrufen.
Sehr schön. Dann hast du schon ein Basis-System, das funktioniert.
Wenn das funktioniert, können wir Postfix beibringen, smtp auth zu verwenden. Dann kannst du mit einem remote Client Mail senden und lesen.
Habe jetzt dies Einstellungen in die main.cf eingefügt:
#Authentifikation smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = smtpd_sasl_security_options = noanonymous
OK!
... 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-AUTH PLAIN 250 8BITMIME AUTH PLAIN meine64BitKodiertenLogindaten 235 Authentication successful <= Boaaa, jetzt staune ich - wer hätte das gedacht ;-) MAIL FROM: root 250 Ok RCPT TO: info_wdr_de 250 Ok
Diese beiden Befehle funktionieren nur, weil der Default auf "strict_rfc821_envelopes = no" steht. Sonst würden die Eingaben nicht akzeptiert: mail from:<root> rcpt to:<info_wdr_de> Also kein Leerzeichen zwischen dem SMTP-Befehl und dem Wert. Die Adresse wird in eckige Klammern gesetzt. Wenn du noch etwas strikter sein willst, setzt du "reject_non_fqdn_recipient" und "reject_non_fqdn_sender".
DATA 354 End data with <CR><LF>.<CR><LF> testauth . 250 Ok: queued as 641E01A4AC quit
Die Nachricht kommt auch beim Mailclient an. Das Antworten auf die Sender-Adresse klappt ebenfalls.
Sehr gut.
Beim Versenden an eine gmx-Adresse kommt allerdings ein relay-Fehler (Hier die Ausgabe von MS Outlook Express/ Thunderbird klappt auch nicht):
Folgende Ausgabe im Maillog (/var/log/mail): Dec 17 00:09:20 domain1 postfix/smtpd[14240]: 4BFCA1A4B0: reject: RCPT from p54A8DC1D.dip.t-dialin.net[84.168.xxx.xx]: 554 <blablabla@gmx.de>: Relay access denied; from=<info@domain1.de> to=<blablabla@gmx.de> proto=ESMTP helo=<treebeard>
Hier sieht die Sache aber weniger gut aus: - Dynamische Client-IP - NON-FQDN-HELO Ich sehe auch nichts von einer Authentifikation. Damit weist der Server die Mail korrekt ab, da die Empfängeradresse nicht auf dem System ist.
Das lokale versenden (s. Telnet-Session oben) habe ich nur teilweise erfolgreich an eine externe Adresse testen können. Bei GMX kam bisher nichts an, evtl. laufen dort andere Filter, als auf anderen Mailservern (Im Spamverdacht war die Mail allerdings auch nicht, evtl. ist diese aber auch noch unterwegs).
Der Befehl "mailq" zeigt dir an, welche Mails noch in der Queue sind.
Danach kommen dann Antispam-Maßnahmen, Amavisd-new, TLS, PFLogSumm.
Oh ja, da "freue" ich mich schon drauf. Bei ca. 500 Spammails pro Tag bin ich geplagter User. Zum Glück gibt es Filter. Aber wenn man das meiste mit einem reject lösen könnte wäre das schon gut.
Du kannst ca. 80-90 Prozent der Spams direkt in Postfix abblocken. Danach muss man zu Mitteln wie Greylisting, policyd-weight, sender address verification etc. greifen. Damit kommt man auf etwa 95% Rejects. Der Aufwand, die Erkennungsrate bzw. Rejectrate dann weiter zu steigern geht entweder auf Kosten von falsch abgewiesenen Mails oder der Aufwand steigt exponentiell mit jedem weiteren Prozent. Sind die 500 Spams auf das Gesamtsystem bezogen oder allein auf deinen eigenen Account? Voraussetzung für Antispam-Maßnahmen innerhalb von Postfix ist, dass die Clients sich authentifizieren und die Server, die einliefern, sauber eingerichtet sind. Wenn das nicht der Fall ist, sieht Postfix die Server in dem gleichen Licht wie die Spammer.
Wenn du dann noch Energie hast, können wir die virtuellen Domains einbauen und die Lookups/Auth über MySQL machen.
So schnell geb ich nicht auf. Aber ob das alles noch bis Weihnachten klappt? ;-)
Kann sein, dass nicht bis dahin nur das Grundsystem steht, aber das sollte seinen Dienst sauber verrichten. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org