# Postfix lokalen Versand verbieten



## tobiasholst (7. Jan. 2016)

Hi,

Eine Frage bezüglich der Absicherung von Postfix:

Wenn sich Nutzer in ISPConfig die Maildomain gmail.com anlegen und eine Catchall Adresse einrichten, würden alle Mails die vom Webserver aus an *@gmail.com gesendet werden abgefangen.

Nun weiß ich zum Beispiel aus Plesk, das der lokale Versand irgendwie unterbunden werden kann. Ich habe bereits folgendes versucht:

In der master.cf habe ich den local auskommentiert:
.....
retry  unix  -  -  -  -  -  error
discard  unix  -  -  -  -  -  discard
*#local  unix  -  n  n  -  -  local*
virtual  unix  -  n  n  -  -  virtual
lmtp  unix  -  -  -  -  -  lmtp
.......
In der main.cf habe ich folgende Zeilen geändert:
.....
mydestination =
local_recipient_maps =
local_transport = error:local mail delivery is disabled
.......

Selbstverständlich habe ich Postfix anschließend neu gestartet.

Leider kann ich aber immer noch Mails abfangen. Wie löst Ihr das ?

Vorab schon mal Danke für eure Tipps!!


----------



## Till (7. Jan. 2016)

Das Domain Modul unter System > Interface config aktivieren. Ein Kunde kann dann ja keine eigene Domains wie gmail.com anlegen sondern nur die Domains die ihm auch gehören.


----------



## tobiasholst (7. Jan. 2016)

Danke für die Antwort Till.

Wenn ich das mit dem Domain Modul richtig verstanden habe, muss ich dann aber jede Domain manuell freigeben bzw. anlegen. Das wäre in meinem Fall leider zu viel Aufwand. Die Kunden sollen unbegrenzt externe Domains anlegen dürfen (soviel wie der Webspace nun mal hergibt) und die Kunden sollen möglichst alles selbst erledigen.

Wie gesagt: Plesk hat hier eine Lösung, den lokalen Versand zu verbieten. Am besten wäre es natürlich, wenn man Postfix so konfiguieren könnte, dass es immer eine DNS Abfrage macht, wer für die Domain xxx zustädnig ist, also immer übers Internet sendet.


----------



## robotto7831a (7. Jan. 2016)

Oder Du nimmst den Vorschlag von Till und bastelst mit der API eine kleine Seite worüber die Kunden die Domains anlegen können. Und vor der Anlage prüfst Du noch ob die bekannten Mailprovider dabei sind und verbietest diese Domain.

Also Domainmodul aktivieren, Kunde legt über eine eigene Seite über die API die Domains im Domainmodul an und dann ist der Rest wie gehabt.


----------



## tobiasholst (7. Jan. 2016)

Das ist auch eine gute Idee! 

Ich schreib mir ein kleines WHMCS-Modul, über welches die Kunden externe Domains anlegen können. Diese Modul könnte dann auch gleich noch Nameserver Einträge etc. erstellen. 

Dadurch, dass ich bekannte Mail-Provider aussperre, verringer ich natürlich das Risiko. Aber 100% ist die Lösung auch nicht. 

Wenn jemand noch ne andere Idee hat? Immer her damit!


----------



## Till (7. Jan. 2016)

Zitat von tobiasholst:


> Ich schreib mir ein kleines WHMCS-Modul, über welches die Kunden externe Domains anlegen können. Diese Modul könnte dann auch gleich noch Nameserver Einträge etc. erstellen.


Was Du machen kannst ist dass Du per dns den MX der domain abfragst die der Kunde hinzufügen möchte und nur wenn der MX auf den Server verweist, kann er die Domain als mail domain anlegen.


----------



## robotto7831a (7. Jan. 2016)

Auch ein Ansatz aber das setzt voraus, dass der Kunde die Mailfunktion des Servers nutzt und keinen anderen Maildienstleister verwendet.


----------



## tobiasholst (7. Jan. 2016)

Zitat von Till:


> Was Du machen kannst ist dass Du per dns den MX der domain abfragst die der Kunde hinzufügen möchte und nur wenn der MX auf den Server verweist, kann er die Domain als mail domain anlegen.


Okay. Ich habe dazu die PHP Funktion checkdnsrr gefunden:

bool *checkdnsrr* ( string $host [, string $type = "MX" ] )
*ABER:*
Wenn ein Kunde eine externe Domain aufschaltet, ist es ja klar, dass die Domain zum Zeitpunkt der Aufschaltung noch auf einen anderen MX zeigt.


----------



## tobiasholst (7. Jan. 2016)

Zitat von robotto7831a:


> Auch ein Ansatz aber das setzt voraus, dass der Kunde die Mailfunktion des Servers nutzt und keinen anderen Maildienstleister verwendet.


Wenn er einen externen Maildienstleister verwendet, braucht er ja bei mir keine Maildomain. 

Wenn jemand weiß, wie die bei Plesk das realisiert haben, immer her damit!!!!!


----------



## robotto7831a (7. Jan. 2016)

Man könnte vielleicht folgendes machen. Ob es funktioniert weiß ich nicht.
Du benötigst zwei Server. Ein Server A wo ISPConfig, Web, Mail usw. läuft und ein Server B der nur Mailserver spielt. Server A sendet alle Mails an seinen Mailrelay Server B. Und dieser sendet dann die Mails raus. Wobei es dann natürlich vorkommt, dass die Mails wieder zu Server A kommen, da der MX auf Server A zeigt. Die Mails an gmail würden dann per MX Auflösung an gmail gesendet werden und nicht an deinen Server A zurück. Ist zwar von hinten durch die Brust ins Auge könnte aber funktionieren.

Oder Du schreibst dir ein Skript, welches regelmäßig prüft ob Maildomains bekannter Mailanbieter bei der angelegt worden sind. Dann kannst Du relativ schnell darauf reagieren.

Oder Du hängst dich mit einem Plugin in die Erstellung der Maildomain dran und Du bekommst dann eine Mail wenn eine neue Maildomain angelegt wurde oder am schönsten wäre es, wenn gmail angelegt werden soll, dass dein Plugin einen Fehler wirft und ISPConfig die Maildomain nicht anlegt.


----------



## tobiasholst (7. Jan. 2016)

Zitat von robotto7831a:


> Man könnte vielleicht folgendes machen. Ob es funktioniert weiß ich nicht.
> Du benötigst zwei Server. Ein Server A wo ISPConfig, Web, Mail usw. läuft und ein Server B der nur Mailserver spielt. Server A sendet alle Mails an seinen Mailrelay Server B. Und dieser sendet dann die Mails raus. Wobei es dann natürlich vorkommt, dass die Mails wieder zu Server A kommen, da der MX auf Server A zeigt. Die Mails an gmail würden dann per MX Auflösung an gmail gesendet werden und nicht an deinen Server A zurück. Ist zwar von hinten durch die Brust ins Auge könnte aber funktionieren.
> 
> Oder Du schreibst dir ein Skript, welches regelmäßig prüft ob Maildomains bekannter Mailanbieter bei der angelegt worden sind. Dann kannst Du relativ schnell darauf reagieren.
> ...


Das mit dem externen Mailrelay habe ich bereits geprüft. Das Problem ist hier aber auch, das der Postfix nur die Mails an den externen weitergibt, für die er nicht zuständig ist. Lokale Mails würde er weiterhin lokal versenden. 

Gibt es eine Doku zur Entwicklung eines ISPConfig Addons? Weil: Eigentlich reicht es vollkommen aus, wenn die dns records von einem ISPConfig Plugin geprüft werden. Kunde legt Maildomain an > ISPConfig prüft (per Cronjob) DNS > Sobald DNS=OK > Kunde kann Mailkonten einrichten. 

Dann würde ich mich mal ransetzen und versuchen, etwas funktionierendes zusammenzubasteln und vielleicht kann ja dann einer von euch nochmal drüber schauen. Außerdem könnte man das dann auch der Community zur Verfügung stellen. Dann geb ich auch wieder ein wenig zurück an die Community


----------



## Till (7. Jan. 2016)

Am einfachsten würde das wahrscheinlich über ein kleines script mittels remote api gehen, da es ja eh als cronjob laufen soll. Es gibt in ISPConfig 3.1 auch ein neues internes cronjob system bei dem man das per plugin realisieren kann, das kannst Du aber noch nicht mit der aktuellen version verwenden, daher wäre remote api wohl das Beste. Doku zum remote api mit beispielen ist im remote_client Verzeichnis des ispconfig tar.gz.


----------



## tobiasholst (7. Jan. 2016)

Zitat von Till:


> Am einfachsten würde das wahrscheinlich über ein kleines script mittels remote api gehen, da es ja eh als cronjob laufen soll. Es gibt in ISPConfig 3.1 auch ein neues internes cronjob system bei dem man das per plugin realisieren kann, das kannst Du aber noch nicht mit der aktuellen version verwenden, daher wäre remote api wohl das Beste. Doku zum remote api mit beispielen ist im remote_client Verzeichnis des ispconfig tar.gz.


Okay. 

Wann ungefähr wird denn die Version 3.1 erscheinen? Gibt es da schon einen Termin?


----------



## Till (7. Jan. 2016)

Wir fixen gerade die letzen sachen in der UI (Anordnung / Umbrch von Feldern etc), dann kommt noch ein test der Funktionen und dann wird die erste Beta frei gegeben. Wann das genau ist ist schwer vorherzusagen, aber wie Du an den Änderungen in git.ispconfig.org siehst sind wir gut dabei, sollte also nicht mehr allzulang dauern.

Das neue cron system findest Du übrigens unter server/lib/classes/cron.d/


----------



## tobiasholst (7. Jan. 2016)

Danke!


----------



## robotto7831a (7. Jan. 2016)

Wenn ich das richtig sehe, dann kann man am Eventbus keine Returncodes hochwerfen. Dort wird wohl nach fire and forgett gearbeitet.

Beim Actionbus geht es anscheinend.


----------



## Till (7. Jan. 2016)

Von welcher Software redest Du, ISPConfig?


----------



## robotto7831a (7. Jan. 2016)

Ja


----------



## Till (8. Jan. 2016)

Events im Server teil sind Veränderungen an den Inhalten einer MySQL Tabelle, D subscribesd Dich also z.B. auf tabelle ftp_user und Dein Code wird dann je nachdem bei insert, update oder delete aufgerufen und Du erhälts als daten jeweils den alten und neuen datensatzt, damit Du auch Operationen wie Ordner umbenennen machen kannst für die Du die vorherigen Werte benötigst. Rückmeldungen aus Deinem Code erfolgen über $app->log().

Actions im gegensatz dazu sind frei definierbare Aktionen mit denen das Interface den Server anweisen kann etwas zu tun, eine action hat einen Namen (auf den Du Dich im server subscriben kannst) und ein Feld mit dem Du beliebige Daten, (also z.B. einen Wert oder ein Array von Werten) an den Server übermitteln kannst. Actions haben ein response Feld, dies wird aber im gegensatz zu den errors der Evennts nicht automatisch angezeigt denn es dient nur dazu dass Du Werte vom Server aus zurück an das Interface geben kannst. Denk aber immer daran dass das alles nicht realtime ist, Du erhältst also die response erst nach etwa. 1 Minute.


----------



## robotto7831a (8. Jan. 2016)

Ich hatte vergessen, dass es ja bis zu eine Minute dauert bis die Aktion ausgeführt wird. Dann macht fire and forgett natürlich Sinn, da der Response erst später erfolgt und der Kunde dann eventuell schon fünf Seiten weiter ist.


----------

