Al Bogner wrote:
Am Donnerstag, 4. Mai 2006 22:10 schrieb Sandy Drobic:
Hallo Sandy,
Hauptziel ist, dass Mails nicht selbständig, wie zB im erwähnten Fall, das "Intranet" verlassen bzw. nur an vordefinierte Domains Mails versandt werden können. Mit anderen Worten, es soll ein Mißbrauch des Mailservers durch die Konfiguration verhindert werden. Theoretisch würde es auch reichen, wenn der Mailserver nur für lokale Mails zuständig ist. Ist folgende Zusammenfassung richtig?
Im großen und ganzen ja. Ich ergänze noch. Es gibt einen lokalen DNS-Server. Die Hostnamen lauten auf rechner1.local.example.tld, rechner2.local.example.tld, usw. Der DNS-Server ist authoritativ für local.example.tld aber nicht für example.tld. Anders formuliert ein Mail an user@local.example.tld kommt nur im Intranet an. Interessanterweise habe ich bei einem Test festgeestellt, dass ein Mail an user@local.example.tld auch nicht ankommt, wenn ein externer DNS-Server für local.example.tld zuständig ist. Ich dachte nur site wird blockiert, local aber mittleweile nicht mehr. Das aber nur nebenbei.
Hm, über DNS habe ich nicht so präzise Kenntnisse, deshalb kann ich aus dem Stehgreif erst einmal nichts darüber sagen. Wird die Auflösung blockiert oder einfach gesagt, "host unknown"?
a) interner Mailserver,
es gibt mehrere interne Mailserver, d.h. Clients könnten sich auch untereinander Mails senden, wenn der "Hauptmailserver" down sein sollte.
Das kann ja über den lokalen DNS erfolgen, der sollte ja wissen, welche Server für welche Adressen Mails annehmen.
interne Maildomain ohne Internet-Routing, interne User (private IP-Adressen innerhalb der Firewall) dürfen für die interne Domain ohne Einschränkung und Anmeldung mailen.
Ja
b) Mails nach extern dürfen nur an bestimmte Domains geschickt werden,
Ja
Einschränkungen:
- evtl. sogar nur an bestimmte Emailadressen
Ja
- evtl. sogar nur mit bestimmten Absenderadressen
Die Absenderadresse ist egal. Die Absenderadressen werden auf user@example.tld umgemappt
Okay.
- evtl. nur von bestimmten Rechnern
Alle Rechner dürfen versenden
c) Lokale Anwendungen wie cron dürfen Emails schicken (sonstige Einschränkungen dafür, auch nach extern?)
Cron ist sogar ein wichtiger Punkt. Die Hauptanwendung für den Mailserver sind Warnmails und Systeminfos. "Normale" Mails der User sollen nicht über den lokalen Mailserver versandt werden.
Dann sollte auf jeden Fall darauf geachtet werden, dass die Einstellung von $myorigin der einzelnen Server stimmt, eventuell sogar eine FQDN Adresse direkt als cron MAILTO festlegen. Wertest du die Mails mit einem System wie Nagios oder BigBrother aus?
Da fällt mir noch eine Ergänzung zu den Anwendungen ein. Mit Kmail ist definiert, dass einem bestimmten Absender der lokale Mailserver zugeordnet ist. Wird eine "falsche" Absender-Email-Adresse verwendet, der ein externer Mailserver zugeordnet ist, so bounct das Mail an die interne Adresse. Das ist ja auch klar, wegen dem lokalen DNS-Server. Gibt es irgendeinen Workaround, dass das Mail trotzdem zugestellt wird? Es müsste vermutlich also der Bounce analysiert werden. Wichtig ist das aber nicht.
Das habe ich nicht ganz verstanden. (^-^) Wenn eine Absenderadresse verwendet wird, die lokal nicht existiert und nicht in der freigeschalteten Relayliste vorliegt, sollte sie gar nicht erst angenommen werden. Der Mailclient sollte also direkt die Fehlermeldung erhalten. Das wäre IMHO die sauberste Lösung.
Dieser Postfix-Mailserver soll also zB nur Mails an example1.tld und example2.tld senden, an alle _anderen_ Domains sollen _keine_ Mails versandt werden können. Ob es eine Möglichkeit gibt auch auf Email-Adressen-Ebene einzuschränken, habe ich nicht herausgefunden. Es wäre interessant zu wissen, ob man example1.tld, example2.tld, user_a@example3.tld erlauben kann, ein Versand eines Mails an user_b@example3.tld aber abgelehnt wird. Alle die von dir angeführten Möglichkeiten gibt es.
check_recipient_access hash:/etc/postfix/check_recipients
Da muss ich nachfragen, ich habe mit Postfix schon länger nichts mehr konfiguriert.
Ich lege als mit vi eine /etc/postfix/check_recipient_access an und trage dort dein u.a. angepasstes Beispiel ein.
Muss ich danach postmap /etc/postfix/check_recipient_access ausführen?
Ja! Nach jeder Änderung der Quelldatei muss die Datenbank, die Postfix eigentlich verwendet, neu erzeugt werden. Dies gilt für alle hash Datenbanken.
/etc/postfix/check_recipients: example1.tld permit example2.tld permit user_a@example3.tld permit user_b@example3.tld reject example3.tld reject
Danke für das Beispiel
Sehr wichtig, vor allem für Trockentests: du kannst mit postmap -q 'example2.tld' hash:/etc/postfix/check_recipients erst einmal ausprobieren, was als Ergebnis kommt. Leeres Ergebnis: DUNNO, Postfix wird die nächste Restriction überprüfen Ergebnis: Postfix nimmt das Ergebnis und wertet es aus. Du kannst auch statt reject, permit, ok, 450, 550 etc. eine weitere Restriktion angeben als Ergebnis. Auch das ist in den man pages dazu schön aufgeführt.
Die Priorität beim Zugriff kannst du mit "man access" unter "Email Adress Patterns" gut sehen.
Ich stelle gerade fest, ich habe da unterschiedliche Manpages. Auf einem Rechner habe ich aber deine Beispiele gefunden.
Je bestimmter ein Key ist, desto höher die Priorität. komplette Adressen werden zuerst ausgewertet, dann erst domains. Du könntest also mit der letzen Zeile (ich füge sie mal einfach ein) alle Recipients in example3 verbieten, sofern sie nicht explizit vorher genannt wurden.
Konkret sind es eine Handvoll Adressen, bei denen ich die Domains nicht erlauben kann, sondern nur zB einige GMX-Adressen. Es geht da um ein Konstrukt um über Warnmails per SMS informiert zu werden. Der Hintergrund ist immer, der lokale Mailserver sendet nur an Email-Adressen, die mehr oder weniger mein "Hoheitsgebiet" sind.
Ich baue es mal in die von dir genannte config ein (ich nenne nur die wesentlichen Teile):
Danke, ich probiere es aber erst aus, wenn ich denke, dass alles erläutert wurde, das mir vorher nebensächlich erschien.
Völlig richtig! Solange es kein dringendes Problem ist, sollte man sich so etwas ein aller Ruhe anschauen, sich überlegen, was man präzise möchte, dann überlegen, wie man das Setup überprüft und dann einen Zeitpunkt wählen, wo man etwas experimentieren kann. Sichere auf jeden fall vorher die bisher verwendeten Konfigurationsdateien, teste immer nach Änderung mit "postfix check" und beobachte das Log, wenn eine Mail abgeschickt und eine Mail eintrifft.
main.cf: inet_interfaces = 127.0.0.1 ::1 192.168.1.99 mydestination = $myhostname, localhost.$mydomain myhostname = gw.local.site # Beseitigt die Meldung vom content_filter: mynetworks = 127.0.0.1 relay_domains = example1.tld, example2.tld, example3.tld smtpd_recipient_restrictions = reject_unauth_destination, check_recipient_access hash:/etc/postfix/check_recipients, transport_maps = hash:/etc/postfix/transport
check_recipient_access übernimmt dabei die Rolle von relay_recipient_maps zur Validierung. Ansonsten sollte dann noch relay_recipient_maps mit der Liste der gültigen Adressen hinterlegt werden.
Da bleibt für mich voerst noch die Frage, ob da postmap notwendig ist.
Für jede hash Datenbank, die verändert wird. Ansonsten kommt aber auch eine Warnung im Postfix Log. Im obigen Beispiel könnte man auch noch permit_mynetworks hinzunehmen, wenn mynetworks auf localhost gesetzt ist und Anwender lokal nicht mailen können. Dann würde sich auch der content_filter nicht beschweren. (^-^)
Wenn die User für gw.local.site in passwd/alias sind, ist local_recipient_maps IMHO bereits schon aktiv.
Da verstehe ich nicht ganz was du meinst.
Für jede Adressklasse gibt es eine Liste, in der die gültigen Adressen stehen. Wenn Postfix keine Liste mit gültigen Adressen hat, kann er ungültige Adressen nicht abweisen und läuft Gefahr, zur Backscatter-Quelle zu werden. Dies hier ist die Vorgabe von Postfix (Version 2.3): local_recipient_maps = proxy:unix:passwd.byname $alias_maps relay_recipient_maps = Dabei ist zugeordnet: mydestination: local_recipient_maps relay_domains: relay_recipient_maps virtual_alias_domains: virtual_alias_maps virtual_mailbox_domains: virtual_mailbox_maps local_recipient_maps ist also schon gesetzt, während relay_recipient_maps als Default deaktiviert ist. "Postconf -n" zeigt die Abweichungen zu den Default-Werten, deshalb muss local_recipient_maps nicht angezeigt werden, ist aber trotzdem aktiv. Relay_recipient_maps muss von Hand gesetzt werden, da es als Default abgeschaltet ist. Sobald du relay_recipient_maps setzt, werden alle Empfängeradressen abgelehnt, die nicht in in dieser Liste stehen.
In /etc/aliases habe ich eine Umleitung von root auf einen User.
Das wird für eine lokale domain (in mydestination) abgefragt und richtig ausgeführt. Für eine externe Adresse müsstest du virtual verwenden, das gilt als Ausnahme für alle Klassen von Domains.
Dann wurde noch /etc/postfix/sender_canonical definiert.
Das ist ja nur für eure Umsetzung, wenn nach extern geschickt wird, nicht wahr?
Die in relay_domains aufgeführten domains werden dann auch zu einem externen Server oder einem Relayhost geschickt (nach domains getrennt möglich in transport)?
Eher nicht, aber ich weiß nicht genau was mein Hoster da für "Spielchen" treibt. AFAIK ist der nur Reseller und da ist ziemlich viel virtuell. Seit 2 Wochen werden die Mailserver des Hosters für "normale User-Mails" aber nicht mehr verwendet, sondern der des ISPs, da es ziemliche Probleme dort gibt, d.h. die Server des Hosters waren in der letzten Zeit mehrmals stundenlang down. Vielleicht findest du raus welche Firma nun pinguin.uni.cc wirklich hostet. DNS-Hoster ist mydomain.com. Dort gibt es einen A-Record auf 70.85.1.114 und der MX-Eintrag führt nicht mehr zu 70.85.1.114. Mit "ThePlanet.com" habe ich jedenfalls keinen Vertrag/Kontakt. Bei meinen Beispieldomains geht es aber nicht um pinguin.uni.cc, sondern um eine 2nd-Level-Domain.
Hauptsache, dass die Einrichtung korrekt läuft, was die Vorgaben für Mailserver betrifft. Du kannst das auf www.dnsreport.com gut prüfen. Gib dort mal deine Domain ein, dann bekommst du schnell einen Überblick, wie sauber die DNS-Konfiguration für deine Domain ist.
Wenn der Server nur die intern von ihm selbst erzeugten Mails verschicken soll, ohne auf seiner IP zu lauschen, dann ist die Nullclient-Config das Richtige: http://www.postfix.org/STANDARD_CONFIGURATION_README.html#null_client
Aber wenn du einen content_filter definiert hast, dann scheint das nicht ganz zuzutreffen.
Ja, der Rechner nimmt auch Mails entgegen und es läuft auch qpopper.
Nach deinen Erläuterungen scheint deine Konfig auch recht gut zuzutreffen. Wahrscheinlich kannst du noch ein paar Details ändern, um die Konfiguration robuster zu machen, aber das solltest du erst nach sorgfältiger Prüfung. Do not change a running system...
Das ist das seltsame Gefühl, wenn man nur Teile des Bildes sieht, aber es mehrere Möglichkeiten gibt, was verdeckt sein könnte. Es lässt einem keine Ruhe. Manchmal können die verdeckten Teile leider tatsächlich einem in den Nacken fallen.(^-°)
Ich freue mich sehr, dass du an Zusammenhänge denkst. Postfix kann extrem viel und bis jetzt war ich froh, dass es so funktionierte, d.h. der Server kann nicht als Relay mißbraucht werden und Warnmails gehen raus.
Das stimmt, Postfix ist ja relativ geradlinig zu konfigurieren, aber es gibt immer noch genügend Fettnäpfchen, in die man treten kann. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com