Sandy Drobic schrieb am 17.12.2006 02:00: Schläfst Du auch manchmal? Ich dachte ich wäre gestern schon spät dran. Alle Achtung, dass Du um die Uhrzeit noch antwortest. Danke.
Ja, du kannst alle Domains als virtuelle Domains anlegen.
Hört sich gut an.
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.
Ich denke, so kompliziert wird das ganze System nicht. Mailinglisten werden nicht benötigt. Und die eingehenden Mails sollten alle zum cyrus wandern.
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.
Gut, das mache ich im nächsten Schritt. Vorerst haben sich aber noch ein paar Probleme bezüglich des Relayens aufgemacht (s.u.).
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). Ergab leider keine Linderung. Habe etwas recherchiert und gesehen, dass in der main.cf der alias_maps Parameter nicht gesetzt war. Dieser hat aber die Default-Einstellung alias_maps = hash:/etc/aliases, nis:mail.aliases
Habe den jetzt auf alias_maps = hash:/etc/aliases gesetzt. Die Warnmeldung scheint jetzt nicht mehr zu kommen.
Ü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. Ja, ist mir schon oft vorgekommen. Wenn ich die Manpage nicht auf meinem Server finde such ich im Internet danach. Da werde ich meistens sofort fündig. Ist halt mal wieder so eine Newbie-Hürde.
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. Danke für den Hinweis. Es ist gut, beim Standard zu bleiben.
Wenn du noch etwas strikter sein willst, setzt du "reject_non_fqdn_recipient" und "reject_non_fqdn_sender". Das habe ich für später notiert (solange ich noch am Testen bin, lass ich das weg).
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. Hmmm...ich glaube das liegt am MS-Mailclient. Habe das ganze auch mal mit Thunderbird probiert und es hat funktioniert. Hier der Auszug aus dem Maillog:
Mail versenden mit Thunderbird: Dec 17 09:59:03 domain1 postfix/smtpd[15561]: connect from p54A8E33B.dip.t-dialin.net[84.168.xxx.xx] Dec 17 09:59:04 domain1 postfix/smtpd[15561]: 230831A4B9: client=p54A8E33B.dip.t-dialin.net[84.168.xxx.xx], sasl_method=PLAIN, sasl_username=info_wdr_de Dec 17 09:59:04 domain1 postfix/cleanup[15564]: 230831A4B9: message-id=<458506A7.2050701@domain1.de> Dec 17 09:59:04 domain1 postfix/qmgr[15393]: 230831A4B9: from=<info@domain1.de>, size=566, nrcpt=1 (queue active) Dec 17 09:59:04 domain1 postfix/smtpd[15561]: disconnect from p54A8E33B.dip.t-dialin.net[84.168.xxx.xx] Dec 17 09:59:04 domain1 postfix/smtp[15565]: 230831A4B9: to=<info@domain2.de>, relay=mail.domain2.de[62.75.209.159], delay=0, status=sent (250 2.0.0 kBH8w06t032449 Message accepted for delivery) Dec 17 09:59:04 domain1 postfix/qmgr[15393]: 230831A4B9: removed Das hat geklappt! Gleiche Einstellungen im Mailclient MS OE, Mail versenden: Dec 17 10:00:09 domain1 postfix/smtpd[15561]: connect from p54A8E33B.dip.t-dialin.net[84.168.xxx.xx] Dec 17 10:00:09 domain1 postfix/smtpd[15561]: NOQUEUE: reject: RCPT from p54A8E33B.dip.t-dialin.net[84.168.xxx.xx]: 554 <info@domain2.de>: Relay access denied; from=<info@domain1.de> to=<info@domain2.de> proto=ESMTP helo=<treebeard> Dec 17 10:00:09 domain1 postfix/smtpd[15561]: disconnect from p54A8E33B.dip.t-dialin.net[84.168.xxx.xx] Das ging schief! Obwohl in den Konteneinstellungen Server > Postausgangsserver > "Server erfordert Authentifizierung" angehakt ist. Gut, ich könnte damit leben, aber ich kann niemanden dazu zwingen auf Thunderbird umzusteigen. Dass klappt ja auch woanders. An der dynamischen Client-IP sollte es nicht liegen, denn die hat ja fast jeder, der sich ins Internet einwählt, um die Mails vom Server abzuholen. Am NON-FQDN-HELO könnte es liegen, aber ich tippe auch auf die fehlende Authentifikation. Hat OE da ein Problem mit der Authentifizierung? Habe das Häkchen dort mal entfernt und versucht die Mail zu senden, gleiches Ergebnis. Häkchen wieder drin, genauso. In den Einstellungen zur Authentifizierung habe ich beides getestet: Sowohl "Gleiche Einstellungen wie für den Posteingangsserver verwenden", als auch "Ameldung mit Kontoname und Kennwort". Wie kann ich herausfinden, an welchem Parameter es hier hakt. Jetzt wäre es prima, noch ein paar Debug-Informationen zu bekommen.
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.
Mailq zeigt eine leere Queue an. In GMX ist diese auch nie angekommen. Wahrscheinlich schwirrt die Mail im Datennirvana herum. Evtl. lag es an den Brackets oder sonstwas. Inzwischen konnte ich den GMX-Test erfolgreich durchlaufen, sowohl lokales versenden (telnet-Session), als auch remoteseitig mit Mailclient Thunderbird.
Sind die 500 Spams auf das Gesamtsystem bezogen oder allein auf deinen eigenen Account?
Das sind die Mails, die täglich in meinen Mailclient trudeln (12 Accounts). Teils bedingt durch gewisse catchall-Einstellungen. Aber das Problem werde ich erst angehen, wenn alles soweit serverseitig läuft. Thunderbird hat einen Klasse Junk-Filter und hilft hier schon zu 98% den Mist herauszufiltern. Viele Grüße Ingbert -- 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