[postfix-users] Aufbau 2 Stufiges Mail Gateway
Guten Tag
Beim Review unseres Email Gateways kam folgende Idee oder auch Problem auf.
Der Gateway in der DMZ muss eine Verbindung ins interne Netz aufmachen, um ein E-Mail zuzustellen. Bei allen anderen DMZ Services haben wir genau dies vermieden.
Die Idee ist nun, die Emails in der DMZ zu queuen, in kurzen Zeitintervallen von dort abzuholen und dann in die Mailqueue des internen Systems einzuschleusen, das dann zustellt. Im Netz hab ich hierzu late Ansaetze gesehen, die dass per Script implementiert haben. Gibt es sowas inzwischen nicht als fertiges Feature? (smtp-poll) Wie macht Ihr es denn?
Auf dem System sollen auch White-, Grey- und Blacklists sowie TLS zur Anwendung kommen. Es waere super, wenn das alles im Hausnetz passieren koennte, denn dafuer haben wir eine GUI ;-), fuer die wegen des Schluesselmanagements sowieso Lizenzen gezahlt werden muessen. Web-GUI und Schluesselmanagement sind aber irgendwie beides nix fuer die DMZ.
Vielen Dank schon jetzt fuer Eure Ideen.
Gruß Andreas
On Wed, May 02, 2012 at 05:32:42PM +0200, Andreas Reschke wrote:
Guten Tag
Beim Review unseres Email Gateways kam folgende Idee oder auch Problem auf.
Der Gateway in der DMZ muss eine Verbindung ins interne Netz aufmachen, um ein E-Mail zuzustellen. Bei allen anderen DMZ Services haben wir genau dies vermieden.
[..]
Auf dem System sollen auch White-, Grey- und Blacklists sowie TLS zur Anwendung kommen. Es waere super, wenn das alles im Hausnetz passieren koennte, denn dafuer haben wir eine GUI ;-), fuer die wegen des Schluesselmanagements sowieso Lizenzen gezahlt werden muessen. Web-GUI und Schluesselmanagement sind aber irgendwie beides nix fuer die DMZ.
Verstehe ich Dich richtig, Ihr habt im internen Netz einen Mailserver stehen der mit Gott und der Welt plaudert, der MX ist, aber Ihr macht Euch Sorgen um ein paar Verbindungen aus der DMZ heraus?
Dennis
Am Mi, 2.05.2012, 18:24 schrieb Dennis Guhl:
On Wed, May 02, 2012 at 05:32:42PM +0200, Andreas Reschke wrote:
Guten Tag
Beim Review unseres Email Gateways kam folgende Idee oder auch Problem auf.
Der Gateway in der DMZ muss eine Verbindung ins interne Netz aufmachen, um ein E-Mail zuzustellen. Bei allen anderen DMZ Services haben wir genau dies vermieden.
[..]
Auf dem System sollen auch White-, Grey- und Blacklists sowie TLS zur Anwendung kommen. Es waere super, wenn das alles im Hausnetz passieren koennte, denn dafuer haben wir eine GUI ;-), fuer die wegen des Schluesselmanagements sowieso Lizenzen gezahlt werden muessen. Web-GUI und Schluesselmanagement sind aber irgendwie beides nix fuer die DMZ.
Verstehe ich Dich richtig, Ihr habt im internen Netz einen Mailserver stehen der mit Gott und der Welt plaudert, der MX ist, aber Ihr macht Euch Sorgen um ein paar Verbindungen aus der DMZ heraus?
Dennis _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Nein, nein,
da habe ich falsch/unklar ausgedrückt. Was ich haben will: Der Mailserver in der DMZ queued ausschliesslich (nur inbound), der interne Mailserver holt sich die eingehenden Mails mit einem kurzen Intervall mit irgendeinem Polling Protokoll ab. Die Queue wird geleert. Er macht Greylisting, Whitelisting, Userüberprüfung, usw.). Falls alles korrekt ist wird die Mail intern zugestellt.
Ausgehende Emails werden dann ueber den äusseren postfix rausgeschickt. Der spielt dann auch den MX Host.
Keine Initiative von aussen nach innen und unterbinden von Tunnelbauten.
Gruß Andreas
Am 03.05.2012 15:03, schrieb Andreas Reschke:
Am Mi, 2.05.2012, 18:24 schrieb Dennis Guhl:
On Wed, May 02, 2012 at 05:32:42PM +0200, Andreas Reschke wrote:
Guten Tag
Beim Review unseres Email Gateways kam folgende Idee oder auch Problem auf.
Der Gateway in der DMZ muss eine Verbindung ins interne Netz aufmachen, um ein E-Mail zuzustellen. Bei allen anderen DMZ Services haben wir genau dies vermieden.
[..]
Auf dem System sollen auch White-, Grey- und Blacklists sowie TLS zur Anwendung kommen. Es waere super, wenn das alles im Hausnetz passieren koennte, denn dafuer haben wir eine GUI ;-), fuer die wegen des Schluesselmanagements sowieso Lizenzen gezahlt werden muessen. Web-GUI und Schluesselmanagement sind aber irgendwie beides nix fuer die DMZ.
Verstehe ich Dich richtig, Ihr habt im internen Netz einen Mailserver stehen der mit Gott und der Welt plaudert, der MX ist, aber Ihr macht Euch Sorgen um ein paar Verbindungen aus der DMZ heraus?
Dennis _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Nein, nein,
da habe ich falsch/unklar ausgedrückt. Was ich haben will: Der Mailserver in der DMZ queued ausschliesslich (nur inbound), der interne Mailserver holt sich die eingehenden Mails mit einem kurzen Intervall mit irgendeinem Polling Protokoll ab. Die Queue wird geleert.
was soll das bringen, wenn du das bremsen willst mach es mit einem slow transport
Er macht Greylisting, Whitelisting, Userüberprüfung, usw.). Falls alles korrekt ist wird die Mail intern zugestellt.
greylisting usw mach der server der mails aus dem internet empfaengt, kein anderer
Ausgehende Emails werden dann ueber den äusseren postfix rausgeschickt. Der spielt dann auch den MX Host.
Keine Initiative von aussen nach innen und unterbinden von Tunnelbauten.
Gruß Andreas
sorry aber deine Anforderung ist verwirrend formuliert
Hi,
Am 03. Mai 2012 15:03 CEST, "Andreas Reschke" postfix_ml@rirasoft.de schrieb:
da habe ich falsch/unklar ausgedrückt. Was ich haben will: Der Mailserver in der DMZ queued ausschliesslich (nur inbound), der interne Mailserver holt sich die eingehenden Mails mit einem kurzen Intervall mit irgendeinem Polling Protokoll ab. Die Queue wird geleert. Er macht Greylisting, Whitelisting, Userüberprüfung, usw.). Falls alles korrekt ist wird die Mail intern zugestellt.
Ausgehende Emails werden dann ueber den äusseren postfix rausgeschickt. Der spielt dann auch den MX Host.
Keine Initiative von aussen nach innen und unterbinden von Tunnelbauten.
Ok, das Setup haben wir so ähnlich auch, dabei holt der Server per fetchmail alle 5min die mails von einem catachall-Account ab und stellt sie dann lokal zu bzw. jagt sie durch den Postfix mit allen Folterwerkzeugen, die der so hat.
Läuft schon seit 6 Jahren recht gut ...
-------- Original-Nachricht --------
Datum: Thu, 03 May 2012 15:15:23 +0200 Von: "Martin Rabl" martin.rabl@rablnet.de An: postfix-users@de.postfix.org Betreff: Re: [postfix-users] Aufbau 2 Stufiges Mail Gateway
Hi,
Am 03. Mai 2012 15:03 CEST, "Andreas Reschke" postfix_ml@rirasoft.de schrieb:
da habe ich falsch/unklar ausgedrückt. Was ich haben will: Der Mailserver in der DMZ queued ausschliesslich (nur inbound), der interne Mailserver holt sich die eingehenden Mails mit einem kurzen Intervall mit irgendeinem Polling Protokoll ab. Die Queue wird geleert. Er macht Greylisting, Whitelisting, Userüberprüfung, usw.). Falls
alles
korrekt ist wird die Mail intern zugestellt.
Ausgehende Emails werden dann ueber den äusseren postfix rausgeschickt. Der spielt dann auch den MX Host.
Keine Initiative von aussen nach innen und unterbinden von Tunnelbauten.
Ok, das Setup haben wir so ähnlich auch, dabei holt der Server per fetchmail alle 5min die mails von einem catachall-Account ab und stellt sie dann lokal zu bzw. jagt sie durch den Postfix mit allen Folterwerkzeugen, die der so hat.
Was für Folterwerkzeuge hat Postfix? Bei einem solchen Setup hat irgend eine Folterei auf dem lokalen Postfix Server fast keinen Effekt. Oder willst Du mir sagen euer lokaler Postfix Server macht irgend welche bounces? Wohin macht er die? Und warum macht das nicht der Postfix der draussen läuft bzw von draussen erreichbar ist?
Läuft schon seit 6 Jahren recht gut ...
Definiere was Du als 'recht gut' betrachtest.
--
Mit freundlichen Grüßen, Martin Rabl
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Hi Steve (eeee),
reg dich mal wieder ab ;-)
Am 03. Mai 2012 17:10 CEST, "Steve" steeeeeveee@gmx.net schrieb:
Was für Folterwerkzeuge hat Postfix? Bei einem solchen Setup hat irgend eine Folterei auf dem lokalen Postfix Server fast keinen Effekt.
Gefoltert wird mit Amavis und Co. Fetchmail dient wirklich nur zum Holen.
Oder willst Du mir sagen euer lokaler Postfix Server macht irgend welche bounces?
Jep. Die laufen korrekt zurück. Interessanterweise ... ;-)
Wohin macht er die?
Per Login mit Submission, eingeliefert wird auf dem Relay-Host per SASL-Auth.
Und warum macht das nicht der Postfix der draussen läuft bzw von draussen erreichbar ist?
Weil der von einem Hoster ist ... ;-)
Kein schönes Setup, funktioniert aber.
Läuft schon seit 6 Jahren recht gut ...
Definiere was Du als 'recht gut' betrachtest.
Das es läuft, keine Fehler hat, eine Einbruchsversuche etc. Aus meiner Sicht ist das Ding pflegeleicht und läuft - mehr war nicht gefragt.
Um es mal genauer zu spezifizieren: der Hoster ist mit seinem Mailserver "die DMZ", bei dem wir (ein Alumni-Verein) die Mails regelmäßig pollen. Das Problem mit dem Server war: kein Zugriff von außen erlaubt, da innerhalb eines restriktiven Hochschulnetzes angesiedelt. Erlaubt war Submission auf 587, Smarthost-Relay stand nicht zur Verfügung. Mails werden entweder vom Server gleich umgeleitet oder lokal zugestellt (erst mit Courier, später mit dovecot) und können dann per Browser gelesen werden. Wie gesagt, nicht schön, funktioniert aber schon länger.
Ach ja - privat mag ichs auch lieber anders nach der reinen Lehre ... ;-)
-------- Original-Nachricht --------
Datum: Thu, 03 May 2012 17:31:31 +0200 Von: "Martin Rabl" martin.rabl@rablnet.de An: postfix-users@de.postfix.org Betreff: Re: [postfix-users] Aufbau 2 Stufiges Mail Gateway
Hi Steve (eeee),
Hallo Martin,
reg dich mal wieder ab ;-)
ich rege mich nicht auf. Warum auch?
Am 03. Mai 2012 17:10 CEST, "Steve" steeeeeveee@gmx.net schrieb:
Was für Folterwerkzeuge hat Postfix? Bei einem solchen Setup hat irgend eine Folterei auf dem lokalen Postfix Server fast keinen Effekt.
Gefoltert wird mit Amavis und Co.
Ja dieses 'und Co.' ist das was mich interessiert. Wenn Du Mails mit Amavis folterst ist das ja okay. Aber wenn Du da irgend welche Restrictions am laufen hast oder so Sachen wie Graylisting, Postscreen, etc machst (also so ziemlich alles was man normalerweise in einem 'pre-queue' Stadium macht), dann erschleicht sich mir der Sinn und Zweck nicht. Wie soll (nur so als Beispiel) Postscreen auf dem zweiten Server Sinn machen? Ich weiss nicht kann sein dass Postscreen mit XFORWARD arbeiten kann aber auch wenn es das könnte würde es meiner Meinung nach praktisch keinen Sinn machen das erst beim zweiten Server zu machen und nicht schon bei ersten.
Fetchmail dient wirklich nur zum Holen.
Oder willst Du mir sagen euer lokaler Postfix Server macht irgend welche bounces?
Jep. Die laufen korrekt zurück. Interessanterweise ... ;-)
Das ist mein Kritikpunkt. Es geht mir nicht darum dass ich daran zweifle, dass non delivery reports und bounces und ähnliches nicht von innen nach aussen den Weg finden. Das ist es nicht. Es geht mir darum, dass Du mit diesem Setup die latente Gefahr läufst unnötig NDR/Bounces/whatever zu generieren.
Wohin macht er die?
Per Login mit Submission, eingeliefert wird auf dem Relay-Host per SASL-Auth.
Und warum macht das nicht der Postfix der draussen läuft bzw von draussen erreichbar ist?
Weil der von einem Hoster ist ... ;-)
Ich bin aus der Schweiz und weiss dass wir hier andere Gesetze haben als in DE. In Deutschland wird die ganze Sache viel komplizierter sobald Du das Mail angenommen hast. Egal ob Du dann später die Mail rejectest/bounce sendest/usw... Sobald Du die angenommen hast, haftest Du unterschiedlich für die Mail als wenn Du sie im pre-queue zurück weist. Darum frage ich mich nach dem Sinn und Zweck der 'Folterei' auf dem Zweiten Server.
Kein schönes Setup, funktioniert aber.
Irgend wann mal vor Dekaden als ich noch Angst hatte meinen eigenen MTA ins Netz zu stellen (geschweige davon, dass es teuer war und ich nur über dialup ins Netz ging), habe ich das auch so gemacht. Natürlich funktioniert das. Heute würde ich das nur machen wenn man mich dazu zwingen würde so was wie Message Labs, Postini, etc zu verwenden. Wenn ich das machen würde, dann würde ich sicherlich nicht nochmals das Mail bei meinem zweiten MTA 'foltern'. Wenn ich die unbedingt nochmals foltern muss, dann ist das Setup unbrauchbar (in meinen Augen). Man 'Foltert' dort wo es Sinn macht. Auf dem zweiten macht es nur teilweise Sinn.
Läuft schon seit 6 Jahren recht gut ...
Definiere was Du als 'recht gut' betrachtest.
Das es läuft, keine Fehler hat, eine Einbruchsversuche etc. Aus meiner Sicht ist das Ding pflegeleicht und läuft - mehr war nicht gefragt.
Um es mal genauer zu spezifizieren: der Hoster ist mit seinem Mailserver "die DMZ", bei dem wir (ein Alumni-Verein) die Mails regelmäßig pollen. Das Problem mit dem Server war: kein Zugriff von außen erlaubt, da innerhalb eines restriktiven Hochschulnetzes angesiedelt. Erlaubt war Submission auf 587, Smarthost-Relay stand nicht zur Verfügung. Mails werden entweder vom Server gleich umgeleitet oder lokal zugestellt (erst mit Courier, später mit dovecot) und können dann per Browser gelesen werden. Wie gesagt, nicht schön, funktioniert aber schon länger.
Das verstehe ich absolut. Aber wenn euer Alumni-Verein REJECTS, DROP, whatever von Mails auf dem Server (der im Hochschulnetz) macht, dann hast Du meiner Meinung nach zu rechtlichen Problemen kommen in Deutschland. Wenn Du da mit einem Anti-Spam Filter Meldungen mit einem Spam/Ham Etikett versiehst oder Virus infizierte Mails in eine Quarantäne schiebst und ähnliches, dann ist das (glaube ich) schon okay. Aber beispielsweise eine Löschung ist da ganz anders. Da könntest Du Probleme bekommen.
Ach ja - privat mag ichs auch lieber anders nach der reinen Lehre ... ;-)
-- Mit freundlichen Grüßen, Martin Rabl
Grüsse aus der Schweiz,
Steve
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Hallo Steve,
eigentlich ist die Diskussion müßig, aber manchmal muß man dann doch noch dagegen halten. Ich will versuchen, höflich zu bleiben.
Am 03.05.12 18:12, schrieb Steve:
Gefoltert wird mit Amavis und Co.
Ja dieses 'und Co.' ist das was mich interessiert. Wenn Du Mails mit Amavis folterst ist das ja okay.
Aber wenn Du da irgend welche Restrictions am laufen hast oder so Sachen wie Graylisting, Postscreen, etc machst (also so ziemlich alles was man normalerweise ... usw.
Um mal klarzustellen: es ging hier in meinem Beitrag zum Subject nicht um tolle Infrastrukturmaßnahmen a la Greylisting und Co., die unbestreitbar viel bringen, sondern um eine Möglichkeit, von einem Mailserver Mails abzuholen, um sie einem anderen zuzustellen. Mein beschriebenes Setup mach das: ein Server (beim Hoster) sammelt, der eigentliche Mailserver holt ab und stellt zu. Nicht mehr und nicht weniger.
Was darüber hinaus sonst noch gefordert ist, um ein sauberes zweistufiges Setup zu erstellen - eben Greylisting, Virenscanning etc. - war nur nebensächlich interessant und tut nichts zu Sache (aka "Subject").
Das ist mein Kritikpunkt. Es geht mir nicht darum dass ich daran zweifle, dass non delivery reports und bounces und ähnliches nicht von innen nach aussen den Weg finden. Das ist es nicht. Es geht mir darum, dass Du mit diesem Setup die latente Gefahr läufst unnötig NDR/Bounces/whatever zu generieren.
Das sehe ich natürlich anders, mal abgesehen davon, das Daemon-Antworten genau dann generiert werden, wenn Mails mangels Empfänger nicht zugestellt werden - das kann man sicher auch abschalten, aber das gilt für alle Server. Bounces entstehen u. a. genau dann, wenn eine Daemon-Mail hin- und herhüpft - aber das kann man auch abfangen. Eine Anzeige wg. Computer-Sabotage bekommt man deswegen garantiert nicht.
Mit anderen Worten: was soll diese ziemlich unangebrachte, am eigentliche Thema (aka "Subject") vorbeigehende Kritik?
Ich bin aus der Schweiz und weiss dass wir hier andere Gesetze haben als in DE.
Was hat das ganze mit Gesetzen zu tun? Lass mal die Kirche im Dorf.
In Deutschland wird die ganze Sache viel komplizierter sobald Du das Mail angenommen hast. Egal ob Du dann später die Mail rejectest/bounce sendest/usw... Sobald Du die angenommen hast, haftest Du unterschiedlich für die Mail als wenn Du sie im pre-queue zurück weist.
DAS halte ich für ziemlichen Unfug. Wenn eine Mail (mit Meldung) nicht angenomemen wird, hat das meines Wissens nach keine rechtlichen "Nachteile" zur Folge - woher auch? Ich darf melden, wenn ich eine Mail nicht annehme, es ist ja auch in den RFCs beschrieben. Und rechtlich nicht zu beanstanden, da eine Statusmeldung.
Darum frage ich mich nach dem Sinn und Zweck der 'Folterei' auf dem Zweiten Server.
Ganz einfach: Virenscans und Spamdetection. Und Mails mit Viren oder Spammails werden nur markiert, und nicht aussortiert - mehr gibt es nicht. Bin doch kein Kindermädchen. Und ja: das ist rechtlich definitiv unangreifbar, da keine Kommunikationsunterdrückung.
Kein schönes Setup, funktioniert aber.
Irgend wann mal vor Dekaden als ich noch Angst hatte meinen ... Wenn ich die unbedingt nochmals foltern muss, dann ist ... das Setup unbrauchbar (in meinen Augen). Man 'Foltert' dort wo es Sinn macht. Auf dem zweiten macht es nur teilweise Sinn.
Die letzten zwei Sätze sehe ich genauso - aber es gibt wie immer mehrere Wahrheiten. Eine ist: Du kennst mein "spezielles" Setup nicht und die Beschränkungen und Anforderungen, die dazu führen. Angesichts der Constraints ist das alles richtig gut - sag ich jetzt einmal.
Aber: Pauschal über Sachen herzufallen, ohne Hintergründe und Gründe zu kennen, ist weder hilfreich noch gutes Benehmen im Sinne der Netikette, und der Erkenntnisgewinn ist nicht mal minimal.
Das verstehe ich absolut. Aber wenn euer Alumni-Verein REJECTS, DROP, whatever von Mails auf dem Server (der im Hochschulnetz) macht, dann hast Du meiner Meinung nach zu rechtlichen Problemen kommen in Deutschland.
Erstens hat keiner was von REJECTS und DROPs gesagt und zweitens: nein. Oder besser: es kommt drauf an. Hat man Nutzungsbedinungen, die genau das beschreiben, dann dürfte man aus dem Schneider sein (oder?). Mal abgesehen davon, dass das schon auch Ugly ist. Ach ja, und drittens: dem Hochschulnetz ist es herzlichst egal, was ich über SSL-Verbindungen zum Hoster hin und herschicke.
Wenn Du da mit einem Anti-Spam Filter Meldungen mit einem Spam/Ham Etikett versiehst oder Virus infizierte Mails in eine Quarantäne schiebst und ähnliches, dann ist das ...
Ich denke, Du verwechselst mich mit einem Newbie ... lassen wir es gut sein.
Viele Grüsse, und ein schönes Wochenden (allen ;-) )
Martin
-------- Original-Nachricht --------
Datum: Fri, 04 May 2012 19:25:16 +0200 Von: Martin Rabl martin.rabl@rablnet.de An: postfix-users@de.postfix.org Betreff: Re: [postfix-users] Aufbau 2 Stufiges Mail Gateway
Hallo Steve,
Hallo,
eigentlich ist die Diskussion müßig, aber manchmal muß man dann doch noch dagegen halten. Ich will versuchen, höflich zu bleiben.
dann hättest Du Deine Antwort an mich schreiben sollen und nicht die Liste damit belästigen.
Am 03.05.12 18:12, schrieb Steve:
Gefoltert wird mit Amavis und Co.
Ja dieses 'und Co.' ist das was mich interessiert. Wenn Du Mails mit Amavis folterst ist das ja okay.
Aber wenn Du da irgend welche Restrictions am laufen hast oder so Sachen wie Graylisting, Postscreen, etc machst (also so ziemlich alles was man normalerweise ... usw.
Um mal klarzustellen: es ging hier in meinem Beitrag zum Subject nicht um tolle Infrastrukturmaßnahmen a la Greylisting und Co., die unbestreitbar viel bringen, sondern um eine Möglichkeit, von einem Mailserver Mails abzuholen, um sie einem anderen zuzustellen. Mein beschriebenes Setup mach das: ein Server (beim Hoster) sammelt, der eigentliche Mailserver holt ab und stellt zu. Nicht mehr und nicht weniger.
Ich habe mich lediglich an der Wortwahl gestört. Dieses 'foltern' hat mich dazu veranlasst eine Antwort zu schreiben.
Ich denke jeder der hier auf der Liste ist und einen eigenen Server betreibt weiss, dass man so ein 0-8-15 Setup wie oben beschrieben machen kann. Ist ja nichts wildes. Ich mache Messaging seit Dekaden und habe schon unendlich viel mal ähnliche Setups gesehen.
Was darüber hinaus sonst noch gefordert ist, um ein sauberes zweistufiges Setup zu erstellen - eben Greylisting, Virenscanning etc. - war nur nebensächlich interessant und tut nichts zu Sache (aka "Subject").
Ich habe auch nicht dem anderen eine Meldung geschrieben sondern Dich darauf angesprochen dass eine 'Folterung' in dem von Dir beschriebenen Setup sinnlos ist. Für mich ist 'Foltern' ein starkes Wort. Also assoziiere ich das mit starker, schwerer, intensiver, rigoroser, etc Verarbeitung/Filterung/etc.
Das ist mein Kritikpunkt. Es geht mir nicht darum dass ich daran
zweifle,
dass non delivery reports und bounces und ähnliches nicht von innen nach aussen den Weg finden. Das ist es nicht. Es geht mir darum, dass Du mit diesem Setup die latente Gefahr läufst unnötig NDR/Bounces/whatever zu generieren.
Das sehe ich natürlich anders, mal abgesehen davon, das Daemon-Antworten genau dann generiert werden, wenn Mails mangels Empfänger nicht zugestellt werden - das kann man sicher auch abschalten, aber das gilt für alle Server. Bounces entstehen u. a. genau dann, wenn eine Daemon-Mail hin- und herhüpft - aber das kann man auch abfangen. Eine Anzeige wg. Computer-Sabotage bekommt man deswegen garantiert nicht.
Mit anderen Worten: was soll diese ziemlich unangebrachte, am eigentliche Thema (aka "Subject") vorbeigehende Kritik?
Ich bin aus der Schweiz und weiss dass wir hier andere Gesetze haben als in DE.
Was hat das ganze mit Gesetzen zu tun? Lass mal die Kirche im Dorf.
In Deutschland wird die ganze Sache viel komplizierter sobald Du das Mail angenommen hast. Egal ob Du dann später die Mail rejectest/bounce sendest/usw... Sobald Du die angenommen hast, haftest Du unterschiedlich für die Mail als wenn Du sie im pre-queue zurück weist.
DAS halte ich für ziemlichen Unfug. Wenn eine Mail (mit Meldung) nicht angenomemen wird, hat das meines Wissens nach keine rechtlichen "Nachteile" zur Folge - woher auch? Ich darf melden, wenn ich eine Mail nicht annehme, es ist ja auch in den RFCs beschrieben. Und rechtlich nicht zu beanstanden, da eine Statusmeldung.
Kann ich als Schweizer nicht beurteilen. Ich habe lediglich öfters hier in der Liste gelesen, dass es in Deutschland spezielle Gesetze dafür gibt und unter anderem das ein Grund ist gewisse Sachen anders zu lösen (z.B. in Amavis/ClamAV rejects im pre queue zu machen und nicht im after queue).
Darum frage ich mich nach dem Sinn und Zweck der 'Folterei' auf dem Zweiten Server.
Ganz einfach: Virenscans und Spamdetection. Und Mails mit Viren oder Spammails werden nur markiert, und nicht aussortiert - mehr gibt es nicht. Bin doch kein Kindermädchen. Und ja: das ist rechtlich definitiv unangreifbar, da keine Kommunikationsunterdrückung.
Kein schönes Setup, funktioniert aber.
Irgend wann mal vor Dekaden als ich noch Angst hatte meinen ... Wenn ich die unbedingt nochmals foltern muss, dann ist ... das Setup unbrauchbar (in meinen Augen). Man 'Foltert' dort wo es Sinn macht. Auf dem zweiten macht es nur teilweise Sinn.
Die letzten zwei Sätze sehe ich genauso - aber es gibt wie immer mehrere Wahrheiten. Eine ist: Du kennst mein "spezielles" Setup nicht und die Beschränkungen und Anforderungen, die dazu führen. Angesichts der Constraints ist das alles richtig gut - sag ich jetzt einmal.
Da hast Du Recht. Ich kenne es nicht.
Aber: Pauschal über Sachen herzufallen, ohne Hintergründe und Gründe zu kennen, ist weder hilfreich noch gutes Benehmen im Sinne der Netikette, und der Erkenntnisgewinn ist nicht mal minimal.
Das verstehe ich absolut. Aber wenn euer Alumni-Verein REJECTS, DROP, whatever von Mails auf dem Server (der im Hochschulnetz) macht, dann hast Du meiner Meinung nach zu rechtlichen Problemen kommen in Deutschland.
Erstens hat keiner was von REJECTS und DROPs gesagt und zweitens: nein. Oder besser: es kommt drauf an. Hat man Nutzungsbedinungen, die genau das beschreiben, dann dürfte man aus dem Schneider sein (oder?). Mal abgesehen davon, dass das schon auch Ugly ist. Ach ja, und drittens: dem Hochschulnetz ist es herzlichst egal, was ich über SSL-Verbindungen zum Hoster hin und herschicke.
Wenn Du da mit einem Anti-Spam Filter Meldungen mit einem Spam/Ham Etikett versiehst oder Virus infizierte Mails in eine Quarantäne schiebst und ähnliches, dann ist das ...
Ich denke, Du verwechselst mich mit einem Newbie ... lassen wir es gut sein.
Für mich ist es nicht relevant was Du bist. Ich habe nichts gegen Dich. Warum auch?
Dein Setup ist okay. Es funktioniert für Dich und die Anderen Mitglieder und das ist das Einzige was zählt.
Viele Grüsse, und ein schönes Wochenden (allen ;-) )
Grüsse aus der Schweiz,
Martin
Steve
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Probier mal fetchmail - der holt von innen und stellt das dann lokal dem postfix zu
Gr., Martin
--- Martin Rabl
Am 02.05.2012 um 17:32 schrieb "Andreas Reschke" postfix_ml@rirasoft.de:
Guten Tag
Beim Review unseres Email Gateways kam folgende Idee oder auch Problem auf.
Der Gateway in der DMZ muss eine Verbindung ins interne Netz aufmachen, um ein E-Mail zuzustellen. Bei allen anderen DMZ Services haben wir genau dies vermieden.
Die Idee ist nun, die Emails in der DMZ zu queuen, in kurzen Zeitintervallen von dort abzuholen und dann in die Mailqueue des internen Systems einzuschleusen, das dann zustellt. Im Netz hab ich hierzu late Ansaetze gesehen, die dass per Script implementiert haben. Gibt es sowas inzwischen nicht als fertiges Feature? (smtp-poll) Wie macht Ihr es denn?
Auf dem System sollen auch White-, Grey- und Blacklists sowie TLS zur Anwendung kommen. Es waere super, wenn das alles im Hausnetz passieren koennte, denn dafuer haben wir eine GUI ;-), fuer die wegen des Schluesselmanagements sowieso Lizenzen gezahlt werden muessen. Web-GUI und Schluesselmanagement sind aber irgendwie beides nix fuer die DMZ.
Vielen Dank schon jetzt fuer Eure Ideen.
Gruß Andreas -- Der Inhalt eines Kasten Bit sind 24 Stück, also ist ein Kasten ein Byte! E-Mail: andreas@rirasoft.de
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
* Martin Rabl martin.rabl@rablnet.de:
Probier mal fetchmail - der holt von innen und stellt das dann lokal dem postfix zu
oder getmail
p@rick
participants (6)
-
Andreas Reschke -
Dennis Guhl -
Martin Rabl -
Patrick Ben Koetter -
Robert Schetterer -
Steve