| > [...]
DOMAIN(generic)dnl
Sieht zwar wissend aus, verfehlt aber den Sinn. Es steht sogar in dem entsprechenden File, dass man sich dieses auf den Namen der jeweiligen Domain copieren und dort die Domainabhängigen Konfigurationselemente eintragen soll. So macht es IMHO wenig Sinn. Die paar Teile in die Haupt- konfigurationsdatei einzutragen, würde den Überblick begünstigen...
Viele Konfigurationspezifika stehen ja auch schon in suse-linux.m4. Außerdem steht hier in meinem Büchlein: "DOMAIN - Damit werdden lokale Parameter für eine (optionale) Administrationsdomäne eingestellt: DOMAIN (domäne) . Domäne ist der Name einer Datei im Verzeichnis cf/domain. In allen Fällen außer der Datei generic sollten Sie eine eigene Domänen-Datei anlegen (siehe §19.3.3)." Ich denke mir, dass das AFAIK heisst, dass man entweder selbst eine Datei erstellen soll oder die Datei generic benutzen muss. Was genau sollte ich denn in eine eigene 'domain.m4' schreiben?
define(`STATUS_FILE', `/var/log/mail')dnl
Das ist nun ein ganz grober Schnitzer. Normalerweise kommt in dieses File der Syslog-Output für die Mail-Facility. Auf jeden Fall ist es in diesem Zusammenhang unnötig verwirrend.
Ist wahr. Habe ich dann auch bemerkt, nachdem ich OSTZPE auf suse/linux umgestellt habe...
MASQUERADE_AS(`local.jp-solution.de')dnl
Sicher?
Ja, wieso? Ich möchte u.a. mit Hilfe dieser Definition erreichen, dass aus einer Domain ns.local.jp-solution.de halt local.jp-solution.de wird. Falls du meinst, dass es diese Domain (noch) nicht gibt: Sie ist bereits registriert und wartet nur noch darauf, bei den root-DNS eingetragen zu werden.
FEATURE(smrsh, `/usr/sbin/smrsh')dnl
Gut gemacht. Allerdings eigentlich nur bei Standleitungssystemen oder größeren internen Netzen (WG? Studentenwohnheim?) sinnvoll.
Hm, ich habe diese Option aus der linux.mc übernommen. Aus der Beschreibung dort bin ich nicht ganz schlau geworden. Es klang aber recht hilfreich. Wozu genau kann ich dieses Feature denn nutzen?
FEATURE(`mailertable', `hash -o /etc/mail/mailertable.db')dnl FEATURE(`genericstable', `hash -o /etc/mail/genericstable.db')dnl FEATURE(`virtusertable', `hash -o /etc/mail/virtusertable.db')dnl FEATURE(`domaintable', `hash -o /etc/mail/domaintable.db')dnl
Sieht richtig aus. Interessant wäre nurnoch, was in /etc/mail/sendmail.cw steht. AFAIK wirkt nämlich virtuser nur auf die dort eingetragenen Domains.
Ja, richtig. Ich habe da auch schon alle meine lokalen Domains eingetragen. Zusätzlich habe ich auch schon eine Domain eingetragen, die auch in der virtusertable vorkommt. Leider ist es dann so, dass er bei einer mail an info@ebendiesedomain.de einfach nur die Domain hinten in die lokale austauscht. D.h., die mail geht an info@local.jp-solution.de. Sie sollte allerdings gleich zu julian (also zu mir) geschickt werden. Oder kann hier ein Zusammenhang mit der Definition MASQUERADE_AS bestehen?
Ich habe, u.a., in der /etc/mail/virtusertable zunächst erstmal eine Zeile eingetragen:
info@jp-solution.de julian@server.local.jp-solution.de
Ich verstehe Dein Problem nicht. Wenn Du tatsächlich "jp-solution.de" in Deiner "/etc/mail/sendmail.cw" stehen hast, sollte ein einfacher Eintrag in "/etc/aliases" mit "info: julian" reichen. Interessant wird es erst, wenn Du mehrere Domains hast und den Info-User für eine oder mehrere weitere Domains an verschieden User verteilen willst.
Hm, ich habe aber noch die Domain jpi-vertrieb.de und wenn ich dort an den Info-User schreibe, dann soll diese Mail nicht zu mir sondern an ein anderes Postfach gesendet werden. So wie du es beschreibst, würde das ja dann nicht funktionieren, da die Änderung ja in info@local.jp-solution.de wäre und somit wieder in meinem Postfach landen würde. Ciao Julian ____________________________________ ______ JP Solution Internet Services / \ D-31655 Stadthagen, Germany /___/ / / Visit: www.JP-solution.de \__/ JPs --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com