From driessen at fblan.de Fri May 1 09:46:14 2015 From: driessen at fblan.de (=?utf-8?Q?Uwe_Drie=C3=9Fen?=) Date: Fri, 1 May 2015 09:46:14 +0200 Subject: [Postfixbuch-users] mail.protection.outlook.com [OT] In-Reply-To: <55428341.2090908@wdns.at> References: <01a601d08311$ae7a55c0$0b6f0140$@fblan.de> <01b701d08315$66bf9d90$343ed8b0$@fblan.de> <01c501d0831e$b86308e0$29291aa0$@fblan.de> <949F2D02-E4B2-40F7-95CF-92BE732A8AE6@kiewel-online.ch> <01e101d0834d$6d3d9fe0$47b8dfa0$@fblan.de> <55428341.2090908@wdns.at> Message-ID: <020701d083e2$e72e6790$b58b36b0$@fblan.de> Im Auftrag von Alois Kratochwill | WDNS.at Hallo Alois > > Dem nächst soll es kostenlose SSL-Zertifikate für jedermann geben > > Installation mit > > > > apt-get install lets-encrypt > > > > https://letsencrypt.org/ > > > > > > "Let?s Encrypt is a free, automated, and open certificate authority > brought to you by the Internet Security Research Group (ISRG). ISRG is a > California public benefit corporation, and is recognized by the IRS as a > tax-exempt organization under Section 501(c)(3) of the Internal Revenue > Code. > 660 York Street, San Francisco, CA 94110" > > ...mit Direktexport der Keys zur NSA oder was? ;-D Kann ich mal so nicht bestätigen. Das Zertifikat wird im Endeffekt genauso erstellt wie jetzt auch. Es erfolgt automatisch (was so einige Scripte auch schon machen) Es kostet sehr wahrscheinlich gar nichts (auch keine eigenen Daten) Es wird von einer Community betreut und die Software dazu bereitgestellt. - CA-CERT nur einfacher. > > Lieber zahle ich ? 59,-- / Jahr für eine beliebige Anzahl Class2 > Certs nach Israel. Klar die Israelis sind bei weitem nicht so neugierig :-))) > > > Schönes Wochenende > Alois > Mit freundlichen Grüßen Uwe Drießen -- Software & Computer Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: 06708660045 From max.grobecker at ml.grobecker.info Sun May 3 12:15:21 2015 From: max.grobecker at ml.grobecker.info (Max Grobecker) Date: Sun, 03 May 2015 12:15:21 +0200 Subject: [Postfixbuch-users] mail.protection.outlook.com In-Reply-To: <01a601d08311$ae7a55c0$0b6f0140$@fblan.de> References: <01a601d08311$ae7a55c0$0b6f0140$@fblan.de> Message-ID: <5545F539.6020204@ml.grobecker.info> Hallo, noch ein Hinweis zu Hotmail/Outlook.com: Ich weiß nicht, ob die Microsoft-Menschen das inzwischen in den Griff bekommen haben... Vor etwa einem Jahr habe ich noch das Phänomen gesehen, dass die Spinner bei einer Maildomain ganz offenbar erst den A-Record und erst dann die MX-Records genutzt haben. Hatte den Effekt, dass sie ständig versuchten beim Webserver anzuklopfen. Da dort aber kein von außen erreichbarer Maildienst läuft, sind die in Timeouts gerannt und haben es dennoch eine ganze Zeit lang dort versucht. Besser war sogar, als bei einem Webserver tatsächlich Port 25 nach außen offen war und der Server (korrekterweise) mit "Relay access denied" geantwortet hat. Da sind dann immer hübsch viele E-Mails von Hotmail gebounced, weil "570 Relay Access Denied" halt. Dabei habe ich aber auch bemerkt, dass trotz identischer Client-IP seitens Microsoft offenbar mehrere Mailserver sich diese IP mittels NAT zu teilen scheinen. Denn von der selben IP habe ich durchweg unterschiedliches Verhalten gesehen, was sich mir nur mit NAT erklären ließ. Ich wollte da mal irgendwann beobachten, ob man ein Muster bei den Remote-Ports feststellen kann - dann würde ich die schlechten Ports aussortieren ;-) Max Am 30.04.2015 um 08:48 schrieb Uwe Drießen: > Hallo Leute > > Hat jemand schon Erfahrungen mit mail.protection.outlook.com "gesammelt"? > > Keine Ahnung was die machen. > Absender hat nachweislich verschickt > Empfänger hat nachweislich nichts bekommen > Absender hat keinerlei Fehlermeldung bekommen > > Im serverlog meines Mailservers nicht ein einziger Zustellversuch !! > > Wir der Absender mail kommt an ! > > > Liebes Microsoft Chaos-Team das ist Unterdrückung von Post und nach > deutschem Gesetz strafbar > > § 206 Verletzung des Post- oder Fernmeldegeheimnisses Abs. 2.2 > > ...eine einem solchen Unternehmen zur Übermittlung anvertraute Sendung > unterdrückt > ...das geschäftsmäßig Post- oder Telekommunikationsdienste erbringt, wird > mit Freiheitsstrafe bis zu fünf Jahren oder mit Geldstrafe bestraft. > > Da Geldstrafen in der Regel aus der Portokasse bezahlt werden bin ich dafür > den zuständigen bei Wasser und Brot einzukerkern. > > Ich hoffe mal Bing liest mit, oder MS setzt endlich mal auf richtige > Mailserver die sowas können. > > > Mit freundlichen Grüßen > > Uwe Drießen > -- > Software & Computer > Uwe Drießen > Lembergstraße 33 > 67824 Feilbingert > > Tel.: 06708660045 > > -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 819 bytes Beschreibung: OpenPGP digital signature URL : From florian.schmidhuber at stud.fh-rosenheim.de Mon May 4 19:51:30 2015 From: florian.schmidhuber at stud.fh-rosenheim.de (Florian Schmidhuber) Date: Mon, 4 May 2015 19:51:30 +0200 Subject: [Postfixbuch-users] Postfix mit Dovecot Message-ID: Gibt es eine Möglichkeit oder macht es Sinn Postfix auf alle Domains zu relayen wenn eh die Authentifizierung über den Dovecot passiert? Oder bekomme ich hier ein Problem das die Blacklisten ein Open Relay erkennen? Dovecot prüft eh die E-Mail Adresse somit ist sichergestellt das der Benutzer existiert und stellt die E-Mail zu. Weiterer Vorteil wäre das ich bei meiner Konfiguration mit MySQL eine Verbindung weniger zu mysql habe. Der Domain check in Postfix per relay_domains ist somit ja eigentlich doppelt da eh gleich im Anschluss die Adresse geprüft wird. Da ich die Domains in einer MySQL Tabelle verwalte sind das natürlich 2 Abfragen statt einer Abfrage. Ich möchte den Mailserver gerne so performant wie nur möglich einrichten. Für Hilfe wäre ich sehr dankbar. Gruß Flo From p.heinlein at heinlein-support.de Mon May 4 20:25:37 2015 From: p.heinlein at heinlein-support.de (Peer Heinlein) Date: Mon, 04 May 2015 20:25:37 +0200 Subject: [Postfixbuch-users] Postfix mit Dovecot In-Reply-To: References: Message-ID: <5547B9A1.2020205@heinlein-support.de> Am 04.05.2015 um 19:51 schrieb Florian Schmidhuber: > Gibt es eine Möglichkeit oder macht es Sinn Postfix auf alle Domains zu relayen wenn eh die Authentifizierung über den Dovecot passiert? Oder bekomme ich hier ein Problem das die Blacklisten ein Open Relay erkennen? > Dovecot prüft eh die E-Mail Adresse somit ist sichergestellt das der Benutzer existiert und stellt die E-Mail zu. > Weiterer Vorteil wäre das ich bei meiner Konfiguration mit MySQL eine Verbindung weniger zu mysql habe. Ich empfehle das ausdrücklich. Aber nicht, daß man /alle/ User relayt, sondern daß man in Postfix die dynamische Empfängervalidierung nutzt (reject_unverified_recipient). Peer -- Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-42 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin From florian.schmidhuber at stud.fh-rosenheim.de Mon May 4 22:10:19 2015 From: florian.schmidhuber at stud.fh-rosenheim.de (Florian Schmidhuber) Date: Mon, 4 May 2015 22:10:19 +0200 Subject: [Postfixbuch-users] Postfix mit Dovecot In-Reply-To: <5547B9A1.2020205@heinlein-support.de> References: <5547B9A1.2020205@heinlein-support.de> Message-ID: Hallo Peer, vielen Dank für die schnelle Antwort. Es wird eben schon per reject_unverified_recipient über dovecot der User verified. Daher dachte ich mir eben das ich mir eventuell den relay_domains Eintrag sparen kann oder mit relay_domains = * auf alle stellen kann. Ich könnte jetzt natürlich da ich mysql verwende einfach ein (select ?lmtp:/unix/?? from virtual_domains) machen ohne WHERE dann würde immer der lmtp zurück gegeben werden auch bei Domains die ich nicht auf meinem Mailserver verwalte und würde es funktionieren. Dabei ist aber das Problem das er trotzdem die SQL Abfrage macht welche ich mir ja sparen könnte. Wie Konfiguriere ich das am saubersten? MfG Flo > On 04 May 2015, at 20:25, Peer Heinlein wrote: > > Am 04.05.2015 um 19:51 schrieb Florian Schmidhuber: > >> Gibt es eine Möglichkeit oder macht es Sinn Postfix auf alle Domains zu relayen wenn eh die Authentifizierung über den Dovecot passiert? Oder bekomme ich hier ein Problem das die Blacklisten ein Open Relay erkennen? >> Dovecot prüft eh die E-Mail Adresse somit ist sichergestellt das der Benutzer existiert und stellt die E-Mail zu. >> Weiterer Vorteil wäre das ich bei meiner Konfiguration mit MySQL eine Verbindung weniger zu mysql habe. > > > Ich empfehle das ausdrücklich. > > Aber nicht, daß man /alle/ User relayt, sondern daß man in Postfix die > dynamische Empfängervalidierung nutzt (reject_unverified_recipient). > > Peer > > > > -- > Heinlein Support GmbH > Schwedter Str. 8/9b, 10119 Berlin > > http://www.heinlein-support.de > > Tel: 030 / 405051-42 > Fax: 030 / 405051-19 > > Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht > Berlin-Charlottenburg, > Geschäftsführer: Peer Heinlein -- Sitz: Berlin > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From janikev at googlemail.com Tue May 5 14:24:41 2015 From: janikev at googlemail.com (jani kev) Date: Tue, 5 May 2015 14:24:41 +0200 Subject: [Postfixbuch-users] wildcard mx records Message-ID: Hallo liebe Liste, mir ist bei einigen Providern aufgefallen, dass sie automatisch generierte mx records nicht nur für example.com sondern auch für *.example.com setzen. Ist das Eurer Erfahrung nach problematisch, so dass man sich die Mühe machen sollte, die wildcard Einträge zu löschen? Gruß jan -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From stickybit at myhm.de Tue May 5 14:28:22 2015 From: stickybit at myhm.de (Andre) Date: Tue, 05 May 2015 14:28:22 +0200 Subject: [Postfixbuch-users] wildcard mx records In-Reply-To: References: Message-ID: <5548B766.10704@myhm.de> Hallo Jan, wenn Du keine E-Mail-Adressen an Subdomains brauchst, kannst Du die löschen. Warum sollen die problematisch sein? Gruß Andre Am 05.05.2015 um 14:24 schrieb jani kev: > Hallo liebe Liste, > > mir ist bei einigen Providern aufgefallen, dass sie automatisch > generierte mx records nicht nur für example.com > sondern auch für *.example.com setzen. > Ist das Eurer Erfahrung nach problematisch, so dass man sich die Mühe > machen sollte, die wildcard Einträge zu löschen? > Gruß > jan > > From janikev at googlemail.com Tue May 5 14:41:18 2015 From: janikev at googlemail.com (jani kev) Date: Tue, 5 May 2015 14:41:18 +0200 Subject: [Postfixbuch-users] wildcard mx records In-Reply-To: <5548B766.10704@myhm.de> References: <5548B766.10704@myhm.de> Message-ID: Problemtisch, dachte ich, vielleicht im Hinblick auf die Verletzung von irgendwelchen RFC's, so dass man eventuell geblockt/ gefiltert wird... Am 5. Mai 2015 um 14:28 schrieb Andre : > Hallo Jan, > > wenn Du keine E-Mail-Adressen an Subdomains brauchst, kannst Du die > löschen. Warum sollen die problematisch sein? > > Gruß > Andre > > Am 05.05.2015 um 14:24 schrieb jani kev: >> Hallo liebe Liste, >> >> mir ist bei einigen Providern aufgefallen, dass sie automatisch >> generierte mx records nicht nur für example.com >> sondern auch für *.example.com setzen. >> Ist das Eurer Erfahrung nach problematisch, so dass man sich die Mühe >> machen sollte, die wildcard Einträge zu löschen? >> Gruß >> jan >> >> > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users From stickybit at myhm.de Tue May 5 15:24:10 2015 From: stickybit at myhm.de (Andre) Date: Tue, 05 May 2015 15:24:10 +0200 Subject: [Postfixbuch-users] wildcard mx records In-Reply-To: References: <5548B766.10704@myhm.de> Message-ID: <5548C47A.6000702@myhm.de> > von irgendwelchen RFC's, so dass man eventuell geblockt/ gefiltert > wird... Denke ich nicht. Wie willst Du dann Mails auf Subdomains abwickeln, z.B. info at sub.example.com? Am 05.05.2015 um 14:41 schrieb jani kev: > Problemtisch, dachte ich, vielleicht im Hinblick auf die Verletzung > von irgendwelchen RFC's, so dass man eventuell geblockt/ gefiltert > wird... > > Am 5. Mai 2015 um 14:28 schrieb Andre : >> Hallo Jan, >> >> wenn Du keine E-Mail-Adressen an Subdomains brauchst, kannst Du die >> löschen. Warum sollen die problematisch sein? >> >> Gruß >> Andre >> >> Am 05.05.2015 um 14:24 schrieb jani kev: >>> Hallo liebe Liste, >>> >>> mir ist bei einigen Providern aufgefallen, dass sie automatisch >>> generierte mx records nicht nur für example.com >>> sondern auch für *.example.com setzen. >>> Ist das Eurer Erfahrung nach problematisch, so dass man sich die Mühe >>> machen sollte, die wildcard Einträge zu löschen? >>> Gruß >>> jan >>> >>> >> -- >> _______________________________________________ >> Postfixbuch-users -- http://www.postfixbuch.de >> Heinlein Professional Linux Support GmbH >> >> Postfixbuch-users at listen.jpberlin.de >> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users From janikev at googlemail.com Tue May 5 16:21:35 2015 From: janikev at googlemail.com (jani kev) Date: Tue, 5 May 2015 16:21:35 +0200 Subject: [Postfixbuch-users] wildcard mx records In-Reply-To: <5548C47A.6000702@myhm.de> References: <5548B766.10704@myhm.de> <5548C47A.6000702@myhm.de> Message-ID: Ja, das macht Sinn. Danke. Am 5. Mai 2015 um 15:24 schrieb Andre : >> von irgendwelchen RFC's, so dass man eventuell geblockt/ gefiltert >> wird... > > Denke ich nicht. Wie willst Du dann Mails auf Subdomains abwickeln, z.B. > > info at sub.example.com? > > Am 05.05.2015 um 14:41 schrieb jani kev: >> Problemtisch, dachte ich, vielleicht im Hinblick auf die Verletzung >> von irgendwelchen RFC's, so dass man eventuell geblockt/ gefiltert >> wird... >> >> Am 5. Mai 2015 um 14:28 schrieb Andre : >>> Hallo Jan, >>> >>> wenn Du keine E-Mail-Adressen an Subdomains brauchst, kannst Du die >>> löschen. Warum sollen die problematisch sein? >>> >>> Gruß >>> Andre >>> >>> Am 05.05.2015 um 14:24 schrieb jani kev: >>>> Hallo liebe Liste, >>>> >>>> mir ist bei einigen Providern aufgefallen, dass sie automatisch >>>> generierte mx records nicht nur für example.com >>>> sondern auch für *.example.com setzen. >>>> Ist das Eurer Erfahrung nach problematisch, so dass man sich die Mühe >>>> machen sollte, die wildcard Einträge zu löschen? >>>> Gruß >>>> jan >>>> >>>> >>> -- >>> _______________________________________________ >>> Postfixbuch-users -- http://www.postfixbuch.de >>> Heinlein Professional Linux Support GmbH >>> >>> Postfixbuch-users at listen.jpberlin.de >>> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users From jost+lists at dimejo.at Tue May 5 19:06:55 2015 From: jost+lists at dimejo.at (Alex JOST) Date: Tue, 05 May 2015 19:06:55 +0200 Subject: [Postfixbuch-users] Postfix mit Dovecot In-Reply-To: References: <5547B9A1.2020205@heinlein-support.de> Message-ID: <5548F8AF.2070802@dimejo.at> Am 04.05.2015 um 22:10 schrieb Florian Schmidhuber: > Hallo Peer, > > vielen Dank für die schnelle Antwort. > Es wird eben schon per reject_unverified_recipient über dovecot der User verified. > Daher dachte ich mir eben das ich mir eventuell den relay_domains Eintrag sparen kann oder mit relay_domains = * auf alle stellen kann. > Ich könnte jetzt natürlich da ich mysql verwende einfach ein (select ?lmtp:/unix/?? from virtual_domains) machen ohne WHERE dann würde immer der lmtp zurück gegeben werden auch bei Domains die ich nicht auf meinem Mailserver verwalte und würde es funktionieren. > Dabei ist aber das Problem das er trotzdem die SQL Abfrage macht welche ich mir ja sparen könnte. > Wie Konfiguriere ich das am saubersten? Du könntest aus Deiner MySQL-Datenbank auch eine Lookup Table (z.B. btree) erzeugen, die Du dann für Postfix verwendest. Das Ganze kann man dann automatisieren, sodass bei jeder Änderung der Datenbank die btree-Datei aktualisiert wird. ==> /etc/postfix/main.cf relay_transport = lmtp:/unix/? relay_domains = btree:/etc/postfix/domains_intern, btree:/etc/postfix/domains_extern transport_maps = btree:/etc/postfix/transport_maps, btree:/etc/postfix/domains_extern ==> /etc/postfix/domains_intern # Liste mit Domains für die Dovecot zuständig ist. example.com irgendeinkommentar example.net nocheinkommentar ==> /etc/postfix/domains_extern # Diese Domains sollen auf einen anderen Server geleitet werden. # Die rechte Spalte gibt das Ziel an. info.example.com smtp:[mail.example.com]:25 test.example.net smtp:[mail.example.com]:25 Auf diese Weise kannst Du die SQL-Abfragen für Domains auf ein Minimum reduzieren, und die Konfiguration von Postfix bleibt sauber und einfach. -- Alex JOST From ralf.hansen2000 at yahoo.de Tue May 5 22:52:09 2015 From: ralf.hansen2000 at yahoo.de (Ralf Hansen) Date: Tue, 05 May 2015 22:52:09 +0200 Subject: [Postfixbuch-users] Mails aus eigener DMZ Message-ID: <55492D79.3000908@yahoo.de> Hallo zusammen, ich habe da mal eine Frage. Wir betreiben in unserer DMZ sowohl eigene Server, als auch Kundensysteme (Hosting), auf dessen Applikationen (z.B. unsichere Kontaktformulare) wir keinen direkten Einfluss haben. Mails, die in der DMZ generiert werden, können natürlich auch in unser internes Netz versandt werden. Leider liegt es in der Natur der Sache, dass man Absender leicht fälschen kann. Mails aus dem Internet mit Absender @meine-firma.de weise ich direkt ab (da nur unsere Mitarbeiter von innen in unserem Namen versenden dürfen), jedoch lasse ich diese Absender aus der DMZ prinzipiell zu, da auch Verfahren unserer Firma dort angesiedelt sind und mit @meine-firma.de versenden. Wie verhindere ich nun, dass hier niemand missbräuchlich den Absender @meine-firma.de auf einem Kunden-Hosting-System in meiner DMZ einsetzt und dann auch noch Mails nach innen sendet? Hinweis: Alle Systeme nutzen den gleichen Relayhost, daher möchte ich nicht auf unserschiedlichen IPs/Ports je nach Verfahren einliefern. Für Anregungen wäre ich dankbar. Gruß ralf From t.maffert at owl3d.de Thu May 7 12:48:10 2015 From: t.maffert at owl3d.de (Tobias Maffert) Date: Thu, 7 May 2015 12:48:10 +0200 Subject: [Postfixbuch-users] smtpd_require_helo in postfix 2.9.6 Message-ID: <015901d088b3$4f755f00$ee601d00$@owl3d.de> Hallo liebe Postfixbuch Leute, ist das richtig, dass es die Einstellung „smtpd_require_helo“ in Postfix 2.9.6 nicht mehr gibt? Und gibt es dafür ne alternative? -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From news at amaltea.de Thu May 7 13:05:57 2015 From: news at amaltea.de (Paul) Date: Thu, 07 May 2015 13:05:57 +0200 Subject: [Postfixbuch-users] Mails aus eigener DMZ In-Reply-To: <55492D79.3000908@yahoo.de> References: <55492D79.3000908@yahoo.de> Message-ID: <554B4715.5090708@amaltea.de> Am 05.05.2015 um 22:52 schrieb Ralf Hansen: > Hallo zusammen, > > ich habe da mal eine Frage. > Wir betreiben in unserer DMZ sowohl eigene Server, als auch > Kundensysteme (Hosting), auf dessen Applikationen (z.B. unsichere > Kontaktformulare) wir keinen direkten Einfluss haben. > Mails, die in der DMZ generiert werden, können natürlich auch in unser > internes Netz versandt werden. Leider liegt es in der Natur der Sache, > dass man Absender leicht fälschen kann. > > Mails aus dem Internet mit Absender @meine-firma.de weise ich direkt ab > (da nur unsere Mitarbeiter von innen in unserem Namen versenden dürfen), > jedoch lasse ich diese Absender aus der DMZ prinzipiell zu, da auch > Verfahren unserer Firma dort angesiedelt sind und mit @meine-firma.de > versenden. > > Wie verhindere ich nun, dass hier niemand missbräuchlich den Absender > @meine-firma.de auf einem Kunden-Hosting-System in meiner DMZ einsetzt > und dann auch noch Mails nach innen sendet? > Hinweis: Alle Systeme nutzen den gleichen Relayhost, daher möchte ich > nicht auf unserschiedlichen IPs/Ports je nach Verfahren einliefern. > > Für Anregungen wäre ich dankbar. Viele Wege führen zum Ziel. Welche davon sinnvoll oder -frei ist, vernachlässige ich jetzt. Falls eure Anwendungen auf unterschiedlichen IPs in der DMZ laufen, kann der Relayhost entsprechend reagieren oder lass deine Anwendungen die Mails markieren und nimmst nur markierte Mails aus der DMZ an. Falls sich die Anwendungen am relayhost authentifizieren, dann könnte was mit reject_sender_login_mismatch o.ä. vielleicht helfen... Gruß, Paul > > Gruß > ralf > From kai_postfix at fuerstenberg.ws Thu May 7 13:10:46 2015 From: kai_postfix at fuerstenberg.ws (=?windows-1252?Q?Kai_F=FCrstenberg?=) Date: Thu, 07 May 2015 13:10:46 +0200 Subject: [Postfixbuch-users] smtpd_require_helo in postfix 2.9.6 In-Reply-To: <015901d088b3$4f755f00$ee601d00$@owl3d.de> References: <015901d088b3$4f755f00$ee601d00$@owl3d.de> Message-ID: <554B4836.4080808@fuerstenberg.ws> Am 07.05.2015 um 12:48 schrieb Tobias Maffert: > ist das richtig, dass es die Einstellung ?smtpd_require_helo? in Postfix > 2.9.6 nicht mehr gibt? Und gibt es dafür ne alternative? http://www.postfix.org/postconf.5.html#smtpd_helo_required -- Kai Fürstenberg PM an: kai at fuerstenberg punkt ws From t.maffert at owl3d.de Thu May 7 15:21:30 2015 From: t.maffert at owl3d.de (Tobias Maffert) Date: Thu, 7 May 2015 15:21:30 +0200 Subject: [Postfixbuch-users] smtpd_require_helo in postfix 2.9.6 In-Reply-To: <554B4836.4080808@fuerstenberg.ws> References: <015901d088b3$4f755f00$ee601d00$@owl3d.de> <554B4836.4080808@fuerstenberg.ws> Message-ID: <016601d088c8$bb462ec0$31d28c40$@owl3d.de> Ahh okay, vielen Dank. Irgendwie hatte ich Tomaten auf den Augen! ;) -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Kai Fürstenberg Gesendet: Donnerstag, 7. Mai 2015 13:11 An: Eine Diskussionsliste rund um das Postfix-Buch von Peer Heinlein. Betreff: Re: [Postfixbuch-users] smtpd_require_helo in postfix 2.9.6 Am 07.05.2015 um 12:48 schrieb Tobias Maffert: > ist das richtig, dass es die Einstellung „smtpd_require_helo“ in > Postfix > 2.9.6 nicht mehr gibt? Und gibt es dafür ne alternative? http://www.postfix.org/postconf.5.html#smtpd_helo_required -- Kai Fürstenberg PM an: kai at fuerstenberg punkt ws -- _______________________________________________ Postfixbuch-users -- http://www.postfixbuch.de Heinlein Professional Linux Support GmbH Postfixbuch-users at listen.jpberlin.de https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users From jbehrend at mpifr-bonn.mpg.de Thu May 7 16:39:17 2015 From: jbehrend at mpifr-bonn.mpg.de (Jan Behrend) Date: Thu, 07 May 2015 16:39:17 +0200 Subject: [Postfixbuch-users] =?iso-8859-1?q?=5BIT-Mitarbeiter=3A197=5D_Ver?= =?iso-8859-1?q?stecken/L=F6schen_von_Headerinformationen?= Message-ID: <1431009557.6768.10.camel@jb1.mpifr-bonn.mpg.de> Hallo Liste, wie sinnvoll ist das Verstecken (Löschen) von Headerinformationen, die intere Informationen enthalten. Wie haltet Ihr das? Unterscheidet Ihr da ausgehende und eingehende Email, etc ... Z.B.: - Interne IPs und Kryptoinfo: Received: from jb1.mpifr-bonn.mpg.de (jb1.mpifr-bonn.mpg.de [134.104.27.161]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.mpifr-bonn.mpg.de - Virenscanner/Malware-Scanner Info: X-Virus-Scanned: Debian amavisd-new at amavis.mpifr-bonn.mpg.de - Sonstige Info: X-policyd-weight: using cached result; rate: -6.1 Beschreibungen, wie das geht, gibt es viele. Wo gibt es aber Abhandlungen über die Sinnhaftigkeit? LG Jan -- MAX-PLANCK-INSTITUT fuer Radioastronomie Jan Behrend - Rechenzentrum ---------------------------------------- Auf dem Huegel 69, D-53121 Bonn Tel: +49 (228) 525 359, Fax: +49 (228) 525 229 jbehrend at mpifr-bonn.mpg.de http://www.mpifr-bonn.mpg.de -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/x-pkcs7-signature Dateigröße : 6273 bytes Beschreibung: nicht verfügbar URL : From mail at arnoldbechtoldt.com Sun May 10 13:29:53 2015 From: mail at arnoldbechtoldt.com (Arnold Bechtoldt) Date: Sun, 10 May 2015 13:29:53 +0200 Subject: [Postfixbuch-users] =?windows-1252?q?=5BIT-Mitarbeiter=3A197=5D_V?= =?windows-1252?q?erstecken/L=F6schen_von_Headerinformationen?= In-Reply-To: <1431009557.6768.10.camel@jb1.mpifr-bonn.mpg.de> References: <1431009557.6768.10.camel@jb1.mpifr-bonn.mpg.de> Message-ID: <554F4131.2040400@arnoldbechtoldt.com> > Z.B.: > - Interne IPs und Kryptoinfo: > Received: from jb1.mpifr-bonn.mpg.de (jb1.mpifr-bonn.mpg.de > [134.104.27.161]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 > bits)) (No client certificate requested) by mail.mpifr-bonn.mpg.de 134.104.27.161 ist an und für sich keine RFC1819-Adresse, also nicht privat. An die Domain jb1.mpifr-bonn.mpg.de komme ich bspw. über einen PTR RR Lookup. Protokoll und Cipher-Suite: Ist *vielleicht* eher dann zu sensitiv wenn man seine IT vernachlässigt und lange und oft auf alte verwundbare Standards zurückgreift (SSLv2 u.ä.). Wenn da aber ohnehin FWs/DMZ zwischen Internet und Host liegen, ist ja ohnehin fraglich in welchen Fällen diese Info böswillig ausgenutzt werden kann. > - Virenscanner/Malware-Scanner Info: > X-Virus-Scanned: Debian amavisd-new at amavis.mpifr-bonn.mpg.de Gleiches wie oben. Debian und amavisd-new sind denke ich nicht für ihre Unsicherheit bekannt. :) -- Arnold Bechtoldt Karlsruhe, Germany On 07.05.15 16:39, Jan Behrend wrote: > Hallo Liste, > > wie sinnvoll ist das Verstecken (Löschen) von Headerinformationen, die > intere Informationen enthalten. > Wie haltet Ihr das? Unterscheidet Ihr da ausgehende und eingehende > Email, etc ... > > > Z.B.: > - Interne IPs und Kryptoinfo: > Received: from jb1.mpifr-bonn.mpg.de (jb1.mpifr-bonn.mpg.de > [134.104.27.161]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 > bits)) (No client certificate requested) by mail.mpifr-bonn.mpg.de > > - Virenscanner/Malware-Scanner Info: > X-Virus-Scanned: Debian amavisd-new at amavis.mpifr-bonn.mpg.de > > - Sonstige Info: > X-policyd-weight: using cached result; rate: -6.1 > > > Beschreibungen, wie das geht, gibt es viele. Wo gibt es aber > Abhandlungen über die Sinnhaftigkeit? > > LG Jan > > > > -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : 0xE2356889.asc Dateityp : application/pgp-keys Dateigröße : 3120 bytes Beschreibung: nicht verfügbar URL : -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 819 bytes Beschreibung: OpenPGP digital signature URL : From max.grobecker at ml.grobecker.info Sun May 10 15:03:04 2015 From: max.grobecker at ml.grobecker.info (Max Grobecker) Date: Sun, 10 May 2015 15:03:04 +0200 Subject: [Postfixbuch-users] =?windows-1252?q?=5BIT-Mitarbeiter=3A197=5D_V?= =?windows-1252?q?erstecken/L=F6schen_von_Headerinformationen?= In-Reply-To: <1431009557.6768.10.camel@jb1.mpifr-bonn.mpg.de> References: <1431009557.6768.10.camel@jb1.mpifr-bonn.mpg.de> Message-ID: <554F5708.9010707@ml.grobecker.info> Hallo, ich bin ein Fan davon, Versionsnummern nach Möglichkeit ausblenden zu lassen. Statt beispielsweise "Debian amavisd-new at..." steht bei mir dann nur "Mailfilter at..." im Header. Da finde ich, dass es niemanden was angeht, mit welcher Software ich wie auf dem Server E-Mails scanne ;-) Meiner Meinung nach ist es ohnehin eine (wenn auch nachvollziehbare) Unsitte, dass scheinbar wirklich jede Distribution versucht ihren Marktanteil durch das Platzieren ihres Namens in irgendwelchen Versionsnummern in Mail- oder HTTP-Headern oder sonstwo zu messen. Auch da finde ich, geht es niemanden was an, welche Software ich von welcher Distribution einsetze... Das klingt jetzt nach "Security by Obscurity", darauf lege ich es aber garnicht an. Wenn man Header entfernt, um es Angreifern schwerer zu machen: Vergiss es ;-) Sobald das System im Internet steht wird es relativ zeitnah attackiert. Ob da nun Header entfernt werden oder nicht, ist erstmal egal. Wenn da interne IPs im Header stehen: Da steht ja ein NAT zwischen, was erstmal niemanden hindurch lässt. Falls jemand drin ist (wie auch immer), wird er sich nicht an Mailheadern festklammern, um zielsicher Angriffe durchzuführen. Dafür gibt es andere Wege ;-) Es *mag* vielleicht tatsächlich möglich sein, dass jemand einen Eindruck von der internen Netzwerkstruktur bekommt. Aber solange er an das Netzwerk nicht drankommt, hilft ihm das herzlich wenig. Und wenn er drankommt, ist ein obfuszierter Mailheader mit Sicherheit das geringste Hindernis. Bei ausgehenden Mails würde ich ggf. SPAM-Header (wenn das getestet wird) wieder entfernen. Einfach, weil es beim Empfänger echt blöd aussieht, wenn da eine schon auf der Kippe stehende E-Mail mit Spam-Flags deines eigenen Systems ankommt ;-) Wenn es SPAM ist, sortiere es aus und konsultiere den Absender - wenn nicht, lasse es ungetagged durch. Ich bekomme manchmal E-Mails (von Behörden), in denen im Betreff dann schon "[SPAM:high]" drin steht... Das ist dann der Moment, wo man einen Eindruck von der IT dieser Behörde bekommt ;-) Viele Grüße aus dem Tal Max Am 07.05.2015 um 16:39 schrieb Jan Behrend: > Hallo Liste, > > wie sinnvoll ist das Verstecken (Löschen) von Headerinformationen, die > intere Informationen enthalten. > Wie haltet Ihr das? Unterscheidet Ihr da ausgehende und eingehende > Email, etc ... > > > Z.B.: > - Interne IPs und Kryptoinfo: > Received: from jb1.mpifr-bonn.mpg.de (jb1.mpifr-bonn.mpg.de > [134.104.27.161]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 > bits)) (No client certificate requested) by mail.mpifr-bonn.mpg.de > > - Virenscanner/Malware-Scanner Info: > X-Virus-Scanned: Debian amavisd-new at amavis.mpifr-bonn.mpg.de > > - Sonstige Info: > X-policyd-weight: using cached result; rate: -6.1 > > > Beschreibungen, wie das geht, gibt es viele. Wo gibt es aber > Abhandlungen über die Sinnhaftigkeit? > > LG Jan > > > > -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 819 bytes Beschreibung: OpenPGP digital signature URL : From t.schneider at tms-itdienst.at Tue May 12 14:20:15 2015 From: t.schneider at tms-itdienst.at (Timm Schneider) Date: Tue, 12 May 2015 14:20:15 +0200 Subject: [Postfixbuch-users] SASL Login Message-ID: <5551EFFF.5060009@tms-itdienst.at> Liebe Listenmitglieder! Ich bekomme seit kurzem einen Haufen solche Anmeldungsversuche. Die kamen immer mal immer wieder, war nicht weiter schlimm, aber diesmal ist es fast gleichzeitig von X verschiedenen Netzen, das schaut nach Botnet aus. Habe Ihr da auch solche Logeinträge? Grüße Timm -- TMS IT-Dienst Hinterstadt 2 4840 Vöcklabruck(VB) Austria T(AT).+43.720.501 078(kostenlos per ENUM erreichbar) T(DE).+49.89.721010 77792 T(CH).+41.32.510 9875 F.+43.720.501 078 57 Das Stammzertifikat finden Sie unter www.cacert.org/index.php?id=3 -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 4267 bytes Beschreibung: S/MIME Cryptographic Signature URL : From wn at neessen.net Tue May 12 14:24:06 2015 From: wn at neessen.net (Winfried Neessen) Date: Tue, 12 May 2015 14:24:06 +0200 Subject: [Postfixbuch-users] SASL Login In-Reply-To: <5551EFFF.5060009@tms-itdienst.at> References: <5551EFFF.5060009@tms-itdienst.at> Message-ID: <63d25de1ffd6cd48ddcd1918416fe86f@neessen.net> Hi Timm, Am 2015-05-12 14:20, schrieb Timm Schneider: > Ich bekomme seit kurzem einen Haufen solche Anmeldungsversuche. > Die kamen immer mal immer wieder, war nicht weiter schlimm, aber > diesmal > ist es fast gleichzeitig von X verschiedenen Netzen, das schaut nach > Botnet aus. > Habe Ihr da auch solche Logeinträge? > Seit Jahren... taeglich so um die 1000-2000 Versuche. Winni From senior.reichhart at sdr.at Tue May 12 16:52:00 2015 From: senior.reichhart at sdr.at (sdr(DI Friedrich Reichhart)) Date: Tue, 12 May 2015 16:52:00 +0200 Subject: [Postfixbuch-users] rewrite und transport problem In-Reply-To: <066601d07627$09e24410$1da6cc30$@sdr.at> References: <066601d07627$09e24410$1da6cc30$@sdr.at> Message-ID: <09dc01d08cc3$33c60070$9b520150$@sdr.at> Hallo Gurus, leider habe ich bis heute keine Lösung des u.a. Problems. Vielleicht hat ja doch jemand von euch eine Tip? Freundliche Grüße Dipl.-Ing. Friedrich Reichhart Geschäftsführer -- ** Software Development Reichhart GmbH ** A-1220 Wien, Schachnerstrasse 53 ** Tel: +43 1 237 91 22 / Fax: +43 1 204 42 71 ** Handelsgericht Wien, Firmenbuch: FN 189969 t , UID: ATU 48408502 ** senior.reichhart at sdr.at , office at sdr.at / www.sdr.at Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von sdr(DI Friedrich Reichhart) Gesendet: Montag, 13. April 2015 22:19 An: postfixbuch-users at listen.jpberlin.de Betreff: [Postfixbuch-users] rewrite und transport problem Hallo, wir betreiben schon seit jahren einen mailserver mit postfix, cyrus-imap, mysql für eine größere anzahl von domains. Da wir die mails für die domain des mailservers auf einen exchange-server weiterleiten wollen haben wir im transport einen Eintrag Domainname.tld smtp:[exchange.domainname.tld] gemacht. Plötzlich haben wir gemerkt, dass der server versucht hat alle mails aller domains auf den exchange weiterzuleiten. Bei nachschau im maillog haben wir festgestellt, dass die einträge für alle mails lauten To= >, orig_to= >. Daraufhin haben wir testweise folgenden eintrag im transport gemacht statt Domainname.tld smtp:[exchange.domainname.tld] user at domainname.tld smtp:[exchange.domainname.tld] Die mails an user at domainname.tld landen weiterhin in der imap-mailbox am mailserver und nicht am exchange. Ich vermute dass das mit dem rewrite der mailadresse zusammenhängt. Leider habe ich bis jetzt nichts gefunden warum die Mailadressen umgeschrieben werden. Kann mir hier vielleicht jemand weiterhelfen? postconf -n address_verify_map = btree:/var/spool/postfix/verified_senders alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix content_filter = smtp-amavis:127.0.0.1:10024 daemon_directory = /usr/libexec/postfix debug_peer_level = 1 duplicate_filter_limit = 100000 mail_owner = postfix mailbox_size_limit = 1024000000 mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp mailq_path = /usr/bin/mailq manpage_directory = /usr/man message_size_limit = 102400000 mydestination = $myhostname, localhost, localhost.localdomain, localhost.$mydomain, mysql:/etc/postfix/mysql-mydestination.cf mydomain = sdr.at myhostname = mail.sdr.at mynetworks = 212.24.113.16/28, 212.24.113.143/32, 85.126.8.194/32, 80.73.240.192/27, 80.123.214.126/32, 80.123.211.78/32, 93.83.195.138, 93.82.165.91, 195.202.152.110, 80.73.242.200, 91.114.10.208/29, 212.186.235.136/29, 80.110.46.5/32, 80.73.242.214, 80.73.242.215, 77.220.109.28 myorigin = $mydomain newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.3.3/readme recipient_canonical_maps = hash:/etc/postfix/canonical relayhost = smtp01.sdr.at sample_directory = /etc/postfix sender_bcc_maps = hash:/etc/postfix/sender_bcc sender_canonical_maps = mysql:/etc/postfix/mysql-canonical.cf sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtp_tls_CAfile = /etc/pki/tls/certs/ca.pem smtp_tls_cert_file = /etc/pki/tls/certs/mail2013.sdr.at.crt smtp_tls_key_file = /etc/pki/tls/certs/mail2013_o.sdr.at.key smtp_tls_session_cache_database = btree:/var/spool/postfix/smtp_tls_session_cache smtp_use_tls = yes smtpd_banner = $myhostname ESMTP smtpd_client_connection_count_limit = 20 smtpd_client_connection_rate_limit = 30 smtpd_client_message_rate_limit = 0 smtpd_client_recipient_rate_limit = 0 smtpd_helo_required = yes smtpd_helo_restrictions = reject_unauth_pipelining smtpd_recipient_restrictions = permit_sasl_authenticated reject_non_fqdn_recipient permit_mynetworks reject_non_fqdn_sender reject_unknown_sender_domain reject_unknown_recipient_domain reject_sender_login_mismatch reject_unauth_destination check_recipient_access hash:/etc/postfix/roleaccount_exceptions reject_non_fqdn_hostname reject_invalid_hostname reject_unauth_pipelining check_helo_access regexp:/etc/postfix/helo_checks check_client_access hash:/etc/postfix/whitelist_checks check_sender_access hash:/etc/postfix/blacklist_checks, hash:/etc/postfix/check_backscatterer check_policy_service unix:postgrey/socket permit smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_exceptions_networks = 85.126.96.174/32 smtpd_sasl_local_domain = smtpd_sasl_path = smtpd smtpd_sasl_security_options = noanonymous smtpd_timeout = 300 smtpd_tls_CAfile = /etc/pki/tls/certs/ca.pem smtpd_tls_cert_file = /etc/pki/tls/certs/mail2013.sdr.at.crt smtpd_tls_key_file = /etc/pki/tls/certs/mail2013_o.sdr.at.key smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_database = btree:/var/spool/postfix/smtpd_tls_session_cache smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes soft_bounce = no tls_random_source = dev:/dev/urandom transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/virtual, mysql:/etc/postfix/mysql-virtual.cf cat virtual # @vorzugsstimme.eu user at vorzugsstimme.eu @vorzugsstimmen.eu user at vorzugsstimme.eu @vorzugsstimme.at user at vorzugsstimme.eu @vorzugsstimmen.at user at vorzugsstimme.eu cat mysql-virtual.cf # # mysql config file for alias lookups on postfix # comments are ok. # # the user name and password to log into the mysql server hosts = localhost user = **** password = ****** # the database name on the servers dbname = mail # the table name # table = virtual # # select_field = dest # where_field = alias # additional_conditions = and status = '1' # Neue Form query = SELECT dest FROM virtual WHERE alias = '%s' AND status = '1' AND alias not like '%%sdr.info' #query = SELECT dest FROM virtual WHERE alias = '%s' AND status = '1' cat mysql-canonical.cf # # mysql config file for canonical lookups on postfix # comments are ok. # # the user name and password to log into the mysql server hosts = localhost user = **** password = ****** # the database name on the servers dbname = mail # the table name # table = virtual # # select_field = alias # where_field = username # Return the first match only # additional_conditions = and status = '1' limit 1 # Neue Form query = SELECT alias FROM virtual WHERE username = '%s' AND status = '1' limit 1 expansion_limit = 1 cat canonical # @relocation-service.at @relocation-services.at @der-geometer.at @ihr-geometer.at @der-vermesser.at @ihr-geometer.at @dergeometer.com @ihr-geometer.at @dergeometer.info @ihr-geometer.at @dergeometer.net @ihr-geometer.at @dervermesser.info @ihr-geometer.at @dervermesser.net @ihr-geometer.at @ihr-vermesser.at @ihr-geometer.at @ihrgeometer.at @ihr-geometer.at @ihrvermesser.at @ihr-geometer.at @landvermesser.at @ihr-geometer.at @mein-geometer.at @ihr-geometer.at @meingeometer.at @ihr-geometer.at @zivilgeometer.co.at @ihr-geometer.at >> mysql -u root -p -e "SELECT alias FROM mail.virtual" Sind ca. 1000 Einträge Ich poste mal einen kleinen Ausschnitt und hoffe dass dieser aufschlussreich ist: +----------------------------------------------+ | alias | +----------------------------------------------+ | info.dippids.at | | info.geoinfo.at | | info.geometer.co.at | | info.grone.at | | info.ihr-geometer.at | | info.kinder-pferde.at | | info.matura98.net | | info.oehyc.at | | info.pferdecoaching.at | | info.reichhart.at | | info.schwech.at | | info.stop-fluglaerm.at | | info.vorzugsstimme.at | | info.vorzugsstimmen.at | | info at altkalksburger.org | | info at dippids.at | | info at geoinfo.at | | info at geometer.co.at | | info at grone.at | | info at ihr-geometer.at | | info at kinder-pferde.at | | info at matura98.net | | info at noetzwerk.at | | info at oehyc.at | | info at pferdecoaching.at | | info at psychotherapie-pferde.at | | info at reichhart.at | | info at schwech.at | | info at sdr.at | | info at segelgruppe.at | | info at stop-fluglaerm.at | | info at vorzugsstimme.at | | info at vorzugsstimmen.at | | info at zwa14.at | | infomails at sdr.info | Danke im Voraus und Freundliche Grüße aus Wien Dipl.-Ing. Friedrich Reichhart Geschäftsführer -- ** Software Development Reichhart GmbH ** A-1220 Wien, Schachnerstrasse 53 ** Tel: +43 1 237 91 22 / Fax: +43 1 204 42 71 ** Handelsgericht Wien, Firmenbuch: FN 189969 t , UID: ATU 48408502 ** senior.reichhart at sdr.at , office at sdr.at / www.sdr.at -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From claas.mueller at contact-software.com Fri May 15 10:46:37 2015 From: claas.mueller at contact-software.com (=?UTF-8?B?Q2xhYXMgTcO8bGxlcg==?=) Date: Fri, 15 May 2015 10:46:37 +0200 Subject: [Postfixbuch-users] Postfix und SASL Problem Message-ID: <5555B26D.9070001@contact-software.com> Hallo, ich habe Probleme damit SASL zum Laufen zu kriegen. Die User sollen via LDAP von der Windows AD Domäne authentifiziert werden. Vielleicht hat jemand einen Hinweis wo ich den Fehler suchen soll, ich hab schon ein paar Stunden Google hinter mir und verstehe die Ursache des Problems nicht. Ich werde das Gefühl nicht los, dass das Problem in der main.cf liegt. Vielen Dank! Folgende configs habe ich bisher bearbeitet: /etc/default/saslauthd START=yes DESC="SASL Authentication Daemon" NAME="saslauthd" MECHANISMS="ldap" MECH_OPTIONS="" THREADS=5 OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd" Postfix Anpassungen bzgl SASL: /etc/postfix/main.cf smtpd_sasl_path = /etc/postfix/sasl/smtpd.conf smtpd_sasl_auth_enable = yes broken_sasl_auth_clients = yes smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_invalid_hostname, reject_unknown_sender_domain /etc/postfix/sasl/smtpd.conf saslauthd_path: /var/run/saslauthd/mux pwcheck_method: saslauthd mech_list: PLAIN LOGIN log_level: 9 allow_plaintext: true ldap_servers: ldap://SERVER ldap_search_base: CN=users,DC=DOMAIN,DC=de ldap_timeout: 10 ldap_filter: sAMAccountName=%U ldap_bind_dn: CN=ldap,CN=Users,DC=DOMAIN,DC=de ldap_password: geheim ldap_deref: never ldap_restart: yes ldap_scope: sub ldap_use_sasl: no ldap_start_tls: no ldap_version: 3 ldap_auth_method: bind Fehlermeldung: May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: vstream_buf_get_ready: fd 24 got 33 May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: < cmu-vm03.DOMAIN.de[172.27.1.20]: AUTH PLAIN AGNtdQAdkdW1tZXIwZiYp May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: xsasl_cyrus_server_create: SASL service=smtp, realm=(null) May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: name_mask: noanonymous May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: xsasl_cyrus_server_first: sasl_method PLAIN, init_response AGNtdQdAkdW1tZXIwZiYp May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: xsasl_cyrus_server_first: decoded initial response May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: warning: SASL authentication failure: Password verification failed May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: warning: cmu-vm03.DOMAIN.de[172.27.1.20]: SASL PLAIN authentication failed: authentication failure May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: > cmu-vm03.DOMAIN.de[172.27.1.20]: 535 5.7.8 Error: authentication failed: authentication failure May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: watchdog_pat: 0x7f2d9fc6cae0 May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: vstream_fflush_some: fd 24 flush 64 May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: vstream_buf_get_ready: fd 24 got 12 May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: < cmu-vm03.DOMAIN.de[172.27.1.20]: AUTH LOGIN May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: xsasl_cyrus_server_create: SASL service=smtp, realm=(null) May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: name_mask: noanonymous May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: xsasl_cyrus_server_first: sasl_method LOGIN May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: xsasl_cyrus_server_auth_response: uncoded server challenge: Username: May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: > cmu-vm03.DOMAIN.de[172.27.1.20]: 334 VXNlcmd5hbWU6 May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: vstream_fflush_some: fd 24 flush 18 May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: vstream_buf_get_ready: fd 24 got 6 May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: < cmu-vm03.DOMAIN.de[172.27.1.20]: Y211 May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: xsasl_cyrus_server_next: decoded response: cmu May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: xsasl_cyrus_server_auth_response: uncoded server challenge: Password: May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: > cmu-vm03.DOMAIN.de[172.27.1.20]: 334 UGFzc3ddvcmQ6 May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: vstream_fflush_some: fd 24 flush 18 May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: vstream_buf_get_ready: fd 24 got 18 May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: < cmu-vm03.DOMAIN.de[172.27.1.20]: JHVtbdWVyMGYdmKQ== May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: xsasl_cyrus_server_next: decoded response: PASSWORD May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: warning: cmu-vm03.DOMAIN.de[172.27.1.20]: SASL LOGIN authentication failed: authentication failure May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: > cmu-vm03.DOMAIN.de[172.27.1.20]: 535 5.7.8 Error: authentication failed: authentication failure May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: watchdog_pat: 0x7f2d9fc6cae0 May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: vstream_fflush_some: fd 24 flush 64 From klaus at tachtler.net Fri May 15 11:20:10 2015 From: klaus at tachtler.net (Klaus Tachtler) Date: Fri, 15 May 2015 11:20:10 +0200 Subject: [Postfixbuch-users] Postfix und SASL Problem - p.s. ... In-Reply-To: <5555B26D.9070001@contact-software.com> Message-ID: <20150515112010.Horde.DF9ghhXvkdjw2cDFoDqWBoL@buero.tachtler.net> Hallo Claas, > Hallo, > ich habe Probleme damit SASL zum Laufen zu kriegen. > > Die User sollen via LDAP von der Windows AD Domäne authentifiziert werden. > Vielleicht hat jemand einen Hinweis wo ich den Fehler suchen soll, > ich hab schon ein paar Stunden Google hinter mir und verstehe die > Ursache des Problems nicht. Ich werde das Gefühl nicht los, dass das > Problem in der main.cf liegt. > > May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: > warning: SASL authentication failure: Password verification failed > May 15 10:37:04 de-bre-mail05 postfix/submission/smtpd[6915]: > warning: cmu-vm03.DOMAIN.de[172.27.1.20]: SASL PLAIN authentication > failed: authentication failure Was ergibt: testsaslauthd -u -p Grüße Klaus. -- ------------------------------------------ e-Mail : klaus at tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------ From klaus at tachtler.net Fri May 15 11:13:19 2015 From: klaus at tachtler.net (Klaus Tachtler) Date: Fri, 15 May 2015 11:13:19 +0200 Subject: [Postfixbuch-users] Postfix und SASL Problem In-Reply-To: <5555B26D.9070001@contact-software.com> Message-ID: <20150515111319.Horde.baBSUkIMOWRSoJUoinJ4w0s@buero.tachtler.net> Hallo Claas, > Hallo, > ich habe Probleme damit SASL zum Laufen zu kriegen. > > Die User sollen via LDAP von der Windows AD Domäne authentifiziert werden. > Vielleicht hat jemand einen Hinweis wo ich den Fehler suchen soll, > ich hab schon ein paar Stunden Google hinter mir und verstehe die > Ursache des Problems nicht. Ich werde das Gefühl nicht los, dass das > Problem in der main.cf liegt. Ist das %U hier richtig? > ldap_filter: sAMAccountName=%U Siehe auch: ldap_filter (default: uid=%u) %u %u is replaced by the complete user string. %U If the string is an address (%u), %U will be replaced by the local part of that address. Grüße Klaus. -- ------------------------------------------ e-Mail : klaus at tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------ From ad+lists at uni-x.org Fri May 15 16:18:25 2015 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Fri, 15 May 2015 16:18:25 +0200 Subject: [Postfixbuch-users] Postfix und SASL Problem In-Reply-To: <5555B26D.9070001@contact-software.com> References: <5555B26D.9070001@contact-software.com> Message-ID: <55560031.5030107@uni-x.org> Am 15.05.2015 um 10:46 schrieb Claas Müller: > Hallo, > ich habe Probleme damit SASL zum Laufen zu kriegen. > > Die User sollen via LDAP von der Windows AD Domäne authentifiziert werden. > Vielleicht hat jemand einen Hinweis wo ich den Fehler suchen soll, ich > hab schon ein paar Stunden Google hinter mir und verstehe die Ursache > des Problems nicht. Ich werde das Gefühl nicht los, dass das Problem in > der main.cf liegt. > > Vielen Dank! > > Folgende configs habe ich bisher bearbeitet: > > /etc/default/saslauthd > START=yes > DESC="SASL Authentication Daemon" > NAME="saslauthd" > MECHANISMS="ldap" > MECH_OPTIONS="" > THREADS=5 > OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd" > > > Postfix Anpassungen bzgl SASL: > /etc/postfix/main.cf > > smtpd_sasl_path = /etc/postfix/sasl/smtpd.conf > smtpd_sasl_auth_enable = yes > broken_sasl_auth_clients = yes > > smtpd_recipient_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > reject_unauth_destination, > reject_invalid_hostname, > reject_unknown_sender_domain > > > /etc/postfix/sasl/smtpd.conf > saslauthd_path: /var/run/saslauthd/mux > pwcheck_method: saslauthd > mech_list: PLAIN LOGIN > log_level: 9 > allow_plaintext: true > ldap_servers: ldap://SERVER > ldap_search_base: CN=users,DC=DOMAIN,DC=de > ldap_timeout: 10 > ldap_filter: sAMAccountName=%U > ldap_bind_dn: CN=ldap,CN=Users,DC=DOMAIN,DC=de > ldap_password: geheim > ldap_deref: never > ldap_restart: yes > ldap_scope: sub > ldap_use_sasl: no > ldap_start_tls: no > ldap_version: 3 > ldap_auth_method: bind [ ... ] Du vermischst hier unterschiedliche cyrus-sasl Setupmethoden. Wenn Du saslauthd mit mechanism ldap verwenden willst, dann erstelle eine /etc/saslauthd.conf Dtei mit den ldap_* Einstellungen, die Du in die smtpd.conf gesetzt hast. Alternativ verzichte auf den saslauthd und nutze auxprop mit dem LDAPDB Plugin. Gruß Alexander From ralf.hansen2000 at yahoo.de Fri May 15 17:56:13 2015 From: ralf.hansen2000 at yahoo.de (Ralf Hansen) Date: Fri, 15 May 2015 17:56:13 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES Message-ID: <5556171D.5020000@yahoo.de> Hallo zusammen, ich bin schon seit Tagen dabei aber bekomme es trotz Geduld und Google einfach nicht hin. Ich verwende Postfix 2.9.4 in einem Multi-Instance-Setup auf SLES 11.3 (kein chroot). Innerhalb unseres Firmennetzes werden selbst signierte Zertifikate unserer eigenen CA eingesetzt. Wenn ich vom Mailserver "mailsrv" eine Mail an 10.100.120.251 sende, erhalte ich eine "Untrusted TLS connection". May 15 17:39:33 mailsrv postfix-instanz01/smtp[47812]: Untrusted TLS connection established to 10.100.120.251[10.100.120.251]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits) Ich würde aber gerne eine "Trusted Connection" erreichen. Folgendes habe ich versucht: Das Zertifikat "meineRootCA.pem" in /etc/ssl/certs/meineRootCA.pem abgelegt. # Neu hashen der Zertifikate c_rehash /etc/ssl/certs/ Danach ergibt ein manueller Test openssl s_client -starttls smtp -connect 10.100.120.251:25 auch die Ausgabe "Verify return code: 0 (ok)", d.h. das System scheint das Zertifikat der Root-CA anerkannt zu haben. Postfix main.cf --------------- smtp_tls_security_level = may smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtp_tls_loglevel = 1 smtp_tls_CAfile = /etc/ssl/certs/meineRootCA.pem smtp_tls_CApath = /etc/ssl/certs/ Trotz Postfix-restart, weiterhin ein "Untrusted TLS connection established". Auch wenn ich die Zertifikate ins Postfix-Verzeichnis kopiere und die Pfade der main.cf dorthin anpasse ändert sich nichts. Das Relaying in der Transport-Map erfolgt auf eine Ziel-IP statt eines DNS-Namens. Ich hatte schon die Befürchtung dass es daran liegen könnte und habe einen entsprechenden /etc/hosts Eintrag erstellt und in der transport-Datei auf den DNS-Namen verwiesen, aber auch kein Erfolg... :-( Warum vertraut mein System mitterweile unserer Root-CA, aber Postfix nicht? Was kann ich noch tun? Danke im Voraus Ralf -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From info at rolandschnabel.de Fri May 15 18:52:11 2015 From: info at rolandschnabel.de (Roland Schnabel) Date: Fri, 15 May 2015 18:52:11 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <5556171D.5020000@yahoo.de> References: <5556171D.5020000@yahoo.de> Message-ID: <5556243B.6090408@rolandschnabel.de> Hallo Ralf, ich würde mal folgende Punkte prüfen: 1. "tls_append_default_CA = yes" beim SMTP-Client setzen. Das hatte bei mir mal ähnliche Probleme verursacht. 2. Ist der DNS-Name im Server-Zertifikat (ggf. unter Alternate DNS-Names) auch derjenige, den der SMTP-Client per DNS auflösen kann? (sprich: dig -x 10.100.120.251) 3. Bei der Ausgabe von "openssl s_client ..." auf dem SMTP-Client nochmal GENAU die gesamte Zertifikatskette prüfen. Die wird gleich am Anfang ausgegeben. Falls dort Fehler auftreten, gibt das ähnliche Probleme. 4. Sicherstellen dass das Zertifikatsverzeichnis auch wirklich vom Postfix gelesen werden kann (s. Chroot-Umgebung von Postfix, selinux, Apparmor, etc.). Viele Grüße, Roland On 15.05.2015 17:56, Ralf Hansen wrote: > > Hallo zusammen, > > > ich bin schon seit Tagen dabei aber bekomme es trotz Geduld und Google > einfach nicht hin. > Ich verwende Postfix 2.9.4 in einem Multi-Instance-Setup auf SLES 11.3 > (kein chroot). > > Innerhalb unseres Firmennetzes werden selbst signierte Zertifikate > unserer eigenen CA eingesetzt. > > Wenn ich vom Mailserver "mailsrv" eine Mail an 10.100.120.251 sende, > erhalte ich eine "Untrusted TLS connection". > > May 15 17:39:33 mailsrv postfix-instanz01/smtp[47812]: Untrusted TLS > connection established to 10.100.120.251[10.100.120.251]:25: TLSv1 > with cipher ADH-AES256-SHA (256/256 bits) > > Ich würde aber gerne eine "Trusted Connection" erreichen. > > Folgendes habe ich versucht: > > Das Zertifikat "meineRootCA.pem" in /etc/ssl/certs/meineRootCA.pem > abgelegt. > > # Neu hashen der Zertifikate > > c_rehash /etc/ssl/certs/ > > Danach ergibt ein manueller Test > > openssl s_client -starttls smtp -connect 10.100.120.251:25 > > auch die Ausgabe "Verify return code: 0 (ok)", d.h. das System scheint > das Zertifikat der Root-CA anerkannt zu haben. > > Postfix main.cf > > --------------- > > smtp_tls_security_level = may > > smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache > > smtp_tls_loglevel = 1 > > smtp_tls_CAfile = /etc/ssl/certs/meineRootCA.pem > > smtp_tls_CApath = /etc/ssl/certs/ > > > > Trotz Postfix-restart, weiterhin ein "Untrusted TLS connection > established". > > Auch wenn ich die Zertifikate ins Postfix-Verzeichnis kopiere und die > Pfade der main.cf dorthin anpasse ändert sich nichts. > > > Das Relaying in der Transport-Map erfolgt auf eine Ziel-IP statt eines > DNS-Namens. > > Ich hatte schon die Befürchtung dass es daran liegen könnte und habe > einen entsprechenden /etc/hosts Eintrag erstellt und in der > transport-Datei auf den DNS-Namen verwiesen, aber auch kein Erfolg... :-( > > Warum vertraut mein System mitterweile unserer Root-CA, aber Postfix > nicht? > > Was kann ich noch tun? > > Danke im Voraus > > Ralf > > > -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 4258 bytes Beschreibung: S/MIME Cryptographic Signature URL : From andreas.schulze at datev.de Fri May 15 19:44:28 2015 From: andreas.schulze at datev.de (Andreas Schulze) Date: Fri, 15 May 2015 19:44:28 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <5556171D.5020000@yahoo.de> References: <5556171D.5020000@yahoo.de> Message-ID: <20150515174427.GA21980@spider.services.datevnet.de> Am 15.05.2015 17:56 schrieb Ralf Hansen: > smtp_tls_CAfile = /etc/ssl/certs/meineRootCA.pem > smtp_tls_CApath = /etc/ssl/certs/ entweder oder ... > Warum vertraut mein System mitterweile unserer Root-CA, aber Postfix nicht? > Was kann ich noch tun? ich hatte auf der Mailserverkonferenz einen Vortrag: https://www.heinlein-support.de/mk/2014/vortrag/tls-fuer-mailserver-richtig-aufsetzen das wird Dein aktuells Prolem nicht gleich lösen aber könnte dennoch helfen :-) Andreas -- Andreas Schulze Internetdienste | P252 DATEV eG 90329 Nürnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196 E-Mail info at datev.de | Internet www.datev.de Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg Nr.70 Vorstand Prof. Dieter Kempf (Vorsitzender) Dr. Robert Mayr (stellv. Vorsitzender) Eckhard Schwarzer (stellv. Vorsitzender) Dr. Peter Krug Jörg Rabe von Pappenheim Vorsitzender des Aufsichtsrates: Dirk Schmale From christian.garling at cg-networks.de Fri May 15 20:56:00 2015 From: christian.garling at cg-networks.de (Christian Garling) Date: Fri, 15 May 2015 20:56:00 +0200 Subject: [Postfixbuch-users] Spam Abwehr - aktuelle Techniken? Message-ID: <55564140.9010500@cg-networks.de> Guten Abend, wir betreiben aktuell noch ein Postfix Setup, welches zur Spam Abwehr u.a. postgrey und policyd-weight nutzt. Leider laufen wir insbesondere beim Greylisting in immer mehr Probleme. Viele unsere Kunden haben ihre Mailserver in der Cloud stehen, weshalb die Absender-Server stark alternierend sind. Eingehende Mails haben teilweise 2 Tage Verzögerung, weil postgrey auf ein immer neues Triple stößt und mit reason=new ablehnt. Ich will jetzt gerade gar nicht konkret wissen, wie man das löst, sondern ob Greylisting heute noch Beachtung findet. Ergänzend interessiert mich, wie heute state-of-the-art Spam-Abwehr aussieht. Gibt es neue Tools / Techniken die man sich unbedingt ansehen sollte? Viele Grüße, Christian Garling From florian.schmidhuber at stud.fh-rosenheim.de Sat May 16 13:03:13 2015 From: florian.schmidhuber at stud.fh-rosenheim.de (Florian Schmidhuber) Date: Sat, 16 May 2015 13:03:13 +0200 Subject: [Postfixbuch-users] =?utf-8?q?Postfix_relay=5Frestrictions_f?= =?utf-8?q?=C3=BCr_sender?= Message-ID: Hallo zusammen, meine Installation akzeptiert aktuell das Versenden von allen E-Mail Adressen. Also angenommen die E-Mail Adresse info at example.com ist auf meinem Server und DNS zeigt auch auf meinen Server. Wenn dieser User sich jetzt in Roundcube einloggt und hier eine Identität anlegt als test at test.de (Identitäten anlegen habe ich normal gesperrt nur jetzt zu Testzwecken aktiviert!) und unter dieser Identität eine E-Mail versenden möchte funktioniert das. Da gegen dieses Problem ja eigentlich SPF eine gute Abhilfe ist ist das jetzt wie ich finde nicht das Problem. Was ich allerdings sicherstellen möchte ist das wenn auf dem Mailserver auch noch die Domain @heise.de eingerichtet ist von einem anderen Benutzer, das info at example.com nicht per Identität als @heise.de versenden kann, da dann ja natürlich auch SPF nicht Alarm schlägt weil es ja vom richtigen Server versendet wurde. Nach langer Suche in der Doku und etlichen Varianten die ich probiert habe bekomme ich es einfach nicht so hin wie ich es mir wünsche. Hat hier irgendjemand einen Tipp für mich wie ich dies am besten mache? Ich würde mir gerne reject_sender_login_mismatch sparen wenn es geht da aktuell Postfix nur von den Domains bescheid weis und alles weitere wie Authentifizierung von Dovecot gemacht wird. Ich möchte hier eine doppelt und dreifache Abfrage der MySQL Datenbank verhindern um den Mailserver so performant wie möglich zu betreiben. Anbei noch meine postfix main.cf: # See /usr/share/postfix/main.cf.dist for a commented, more complete version # Debian specific: Specifying a file name will cause the first # line of that file to be used as the name. The Debian default # is /etc/mailname. #myorigin = /etc/mailname smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) biff = no # appending .domain is the MUA's job. append_dot_mydomain = no # Disable Mailbox Size Limit mailbox_size_limit = 0 # Increase Message Size Limit message_size_limit = 104857600 # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h readme_directory = no # helo vom client erfordert smtpd_helo_required = yes ##### TLS settings ###### tls_ssl_options = NO_COMPRESSION tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA ### outgoing connections ### smtp_tls_security_level=may smtp_tls_protocols = !SSLv2, !SSLv3 smtp_tls_ciphers = high smtp_tls_loglevel = 1 smtp_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtp_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtp_tls_session_cache_database = btree:$data_directory/smtp_scache ### incoming connections ### smtpd_tls_auth_only = yes smtpd_tls_security_level=may smtpd_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_ciphers = high smtpd_tls_loglevel = 0 smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtpd_tls_session_cache_database = btree:$data_directory/smtpd_scache # SASL Auth smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous broken_sasl_auth_clients = yes # Network myhostname = mailserver.example.com myorigin = mailserver.example.com mydestination = localhost mailserver.example.com mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 recipient_delimiter = + inet_interfaces = all inet_protocols = all unverified_recipient_reject_code = 550 smtpd_relay_restrictions = reject_non_fqdn_recipient reject_non_fqdn_sender reject_unknown_sender_domain reject_unknown_recipient_domain reject_unverified_recipient reject_unlisted_sender reject_unlisted_recipient permit_sasl_authenticated permit_mynetworks check_policy_service inet:127.0.0.1:10023 reject_invalid_hostname reject_unknown_helo_hostname reject_unauth_destination reject_sender_login_mismatch reject_multi_recipient_bounce reject_non_fqdn_helo_hostname reject_invalid_helo_hostname check_policy_service unix:private/quota-status permit # MySQL Connection virtual_alias_maps = proxy:mysql:/etc/postfix/virtual/mysql-virtual-user-aliases.cf, proxy:mysql:/etc/postfix/virtual/mysql-virtual-domain-aliases.cf relay_domains = proxy:mysql:/etc/postfix/virtual/mysql-virtual-mailbox-domains.cf transport_maps = proxy:mysql:/etc/postfix/virtual/mysql-virtual-transports.cf, $relay_domains Gruß Flo -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From news at amaltea.de Sat May 16 21:41:27 2015 From: news at amaltea.de (Paul) Date: Sat, 16 May 2015 21:41:27 +0200 Subject: [Postfixbuch-users] =?windows-1252?q?Postfix_relay=5Frestrictions?= =?windows-1252?q?_f=FCr_sender?= In-Reply-To: References: Message-ID: <55579D67.2080709@amaltea.de> Am 16.05.2015 um 13:03 schrieb Florian Schmidhuber: > Hallo zusammen, > > meine Installation akzeptiert aktuell das Versenden von allen E-Mail > Adressen. > Also angenommen die E-Mail Adresse info at example.com > ist auf meinem Server und DNS zeigt auch auf > meinen Server. > Wenn dieser User sich jetzt in Roundcube einloggt und hier eine > Identität anlegt als test at test.de (Identitäten > anlegen habe ich normal gesperrt nur jetzt zu Testzwecken aktiviert!) > und unter dieser Identität eine E-Mail versenden möchte funktioniert das. > Da gegen dieses Problem ja eigentlich SPF eine gute Abhilfe ist ist das > jetzt wie ich finde nicht das Problem. Nein, SPF hilft dir hierbei gar nicht. Vermutlich hast Du SPF mißverstanden. > Was ich allerdings sicherstellen möchte ist das wenn auf dem Mailserver > auch noch die Domain @heise.de eingerichtet ist von > einem anderen Benutzer, das info at example.com > nicht per Identität als @heise.de > versenden kann, da dann ja natürlich auch SPF nicht > Alarm schlägt weil es ja vom richtigen Server versendet wurde. > Nach langer Suche in der Doku und etlichen Varianten die ich probiert > habe bekomme ich es einfach nicht so hin wie ich es mir wünsche. > Hat hier irgendjemand einen Tipp für mich wie ich dies am besten mache? > > Ich würde mir gerne reject_sender_login_mismatch sparen wenn es geht da > aktuell Postfix nur von den Domains bescheid weis und alles weitere wie > Authentifizierung von Dovecot gemacht wird. > Ich möchte hier eine doppelt und dreifache Abfrage der MySQL Datenbank > verhindern um den Mailserver so performant wie möglich zu betreiben. > > Anbei noch meine postfix main.cf: Hab grad keine Zeit, deine Konfig zu durchblicken, aber ich schätze, dass du keinen Performanceunterschied feststellen wirst, wenn du es mit reject_sender_login_mismatch machst, es sei denn Du hast du wirklich, wirklich, wirklich viel Traffic und nur ne 486er Kiste? ;-) reject_sender_login_mismatch ist genau für dein Problem gemacht und daher solltest du es benutzen. Viele Grüße Paul > # See /usr/share/postfix/main.cf.dist for a commented, more complete version > > # Debian specific: Specifying a file name will cause the first > # line of that file to be used as the name. The Debian default > # is /etc/mailname. > #myorigin = /etc/mailname > > smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) > biff = no > > # appending .domain is the MUA's job. > append_dot_mydomain = no > > # Disable Mailbox Size Limit > mailbox_size_limit = 0 > > # Increase Message Size Limit > message_size_limit = 104857600 > > # Uncomment the next line to generate "delayed mail" warnings > #delay_warning_time = 4h > > readme_directory = no > > # helo vom client erfordert > smtpd_helo_required = yes > > ##### TLS settings ###### > tls_ssl_options = NO_COMPRESSION > tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA > > ### outgoing connections ### > smtp_tls_security_level=may > smtp_tls_protocols = !SSLv2, !SSLv3 > smtp_tls_ciphers = high > smtp_tls_loglevel = 1 > smtp_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem > smtp_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key > smtp_tls_session_cache_database = btree:$data_directory/smtp_scache > > ### incoming connections ### > smtpd_tls_auth_only = yes > smtpd_tls_security_level=may > smtpd_tls_protocols = !SSLv2, !SSLv3 > smtpd_tls_ciphers = high > smtpd_tls_loglevel = 0 > smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem > smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key > smtpd_tls_session_cache_database = btree:$data_directory/smtpd_scache > > # SASL Auth > smtpd_sasl_type = dovecot > smtpd_sasl_path = private/auth > smtpd_sasl_auth_enable = yes > smtpd_sasl_security_options = noanonymous, noplaintext > smtpd_sasl_tls_security_options = noanonymous > broken_sasl_auth_clients = yes > > # Network > myhostname = mailserver.example.com > myorigin = mailserver.example.com > mydestination = localhost mailserver.example.com > > mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 > recipient_delimiter = + > inet_interfaces = all > inet_protocols = all > unverified_recipient_reject_code = 550 > > smtpd_relay_restrictions = > reject_non_fqdn_recipient > reject_non_fqdn_sender > reject_unknown_sender_domain > reject_unknown_recipient_domain > reject_unverified_recipient > reject_unlisted_sender > reject_unlisted_recipient > permit_sasl_authenticated > permit_mynetworks > check_policy_service inet:127.0.0.1:10023 > reject_invalid_hostname > reject_unknown_helo_hostname > reject_unauth_destination > reject_sender_login_mismatch > reject_multi_recipient_bounce > reject_non_fqdn_helo_hostname > reject_invalid_helo_hostname > check_policy_service unix:private/quota-status > permit > > # MySQL Connection > virtual_alias_maps = > proxy:mysql:/etc/postfix/virtual/mysql-virtual-user-aliases.cf, > proxy:mysql:/etc/postfix/virtual/mysql-virtual-domain-aliases.cf > relay_domains = > proxy:mysql:/etc/postfix/virtual/mysql-virtual-mailbox-domains.cf > transport_maps = > proxy:mysql:/etc/postfix/virtual/mysql-virtual-transports.cf, $relay_domains > > Gruß > Flo > > From florian.schmidhuber at stud.fh-rosenheim.de Sat May 16 21:46:58 2015 From: florian.schmidhuber at stud.fh-rosenheim.de (Florian Schmidhuber) Date: Sat, 16 May 2015 21:46:58 +0200 Subject: [Postfixbuch-users] =?utf-8?q?Postfix_relay=5Frestrictions_f?= =?utf-8?q?=C3=BCr_sender?= In-Reply-To: <55579D67.2080709@amaltea.de> References: <55579D67.2080709@amaltea.de> Message-ID: <046E6E16-9BFB-4EFF-A40C-55785BAA8017@stud.fh-rosenheim.de> Hallo Paul, Wieso mittels SPF kann ich ja definieren welche IP Adressen für diese Domain valide Sender sind. Ich erstelle also bei meiner Domain einen SPF Record welcher beschreibt das nur mein Mailserver mit der z.B. 192.168.0.1 autorisiert ist für diese Domain zu senden. Das nicht jeder SPF prüft und SPF Records setzt ist dann wieder eine andere Sache. Ok dann verwende ich dafür einfach reject_sender_login_mismatch Danke Gruß Flo > On 16 May 2015, at 21:41, Paul wrote: > > Am 16.05.2015 um 13:03 schrieb Florian Schmidhuber: >> Hallo zusammen, >> >> meine Installation akzeptiert aktuell das Versenden von allen E-Mail >> Adressen. >> Also angenommen die E-Mail Adresse info at example.com >> > ist auf meinem Server und DNS zeigt auch auf >> meinen Server. >> Wenn dieser User sich jetzt in Roundcube einloggt und hier eine >> Identität anlegt als test at test.de > (Identitäten >> anlegen habe ich normal gesperrt nur jetzt zu Testzwecken aktiviert!) >> und unter dieser Identität eine E-Mail versenden möchte funktioniert das. > >> Da gegen dieses Problem ja eigentlich SPF eine gute Abhilfe ist ist das >> jetzt wie ich finde nicht das Problem. > > Nein, SPF hilft dir hierbei gar nicht. Vermutlich hast Du SPF > mißverstanden. > >> Was ich allerdings sicherstellen möchte ist das wenn auf dem Mailserver >> auch noch die Domain @heise.de > eingerichtet ist von >> einem anderen Benutzer, das info at example.com >> > nicht per Identität als @heise.de >> > versenden kann, da dann ja natürlich auch SPF nicht >> Alarm schlägt weil es ja vom richtigen Server versendet wurde. >> Nach langer Suche in der Doku und etlichen Varianten die ich probiert >> habe bekomme ich es einfach nicht so hin wie ich es mir wünsche. >> Hat hier irgendjemand einen Tipp für mich wie ich dies am besten mache? >> >> Ich würde mir gerne reject_sender_login_mismatch sparen wenn es geht da >> aktuell Postfix nur von den Domains bescheid weis und alles weitere wie >> Authentifizierung von Dovecot gemacht wird. >> Ich möchte hier eine doppelt und dreifache Abfrage der MySQL Datenbank >> verhindern um den Mailserver so performant wie möglich zu betreiben. >> >> Anbei noch meine postfix main.cf: > > Hab grad keine Zeit, deine Konfig zu durchblicken, aber ich schätze, > dass du keinen Performanceunterschied feststellen wirst, wenn du es mit > reject_sender_login_mismatch machst, es sei denn Du hast du wirklich, > wirklich, wirklich viel Traffic und nur ne 486er Kiste? ;-) > > reject_sender_login_mismatch ist genau für dein Problem gemacht und > daher solltest du es benutzen. > > Viele Grüße > Paul > > >> # See /usr/share/postfix/main.cf.dist for a commented, more complete version >> >> # Debian specific: Specifying a file name will cause the first >> # line of that file to be used as the name. The Debian default >> # is /etc/mailname. >> #myorigin = /etc/mailname >> >> smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) >> biff = no >> >> # appending .domain is the MUA's job. >> append_dot_mydomain = no >> >> # Disable Mailbox Size Limit >> mailbox_size_limit = 0 >> >> # Increase Message Size Limit >> message_size_limit = 104857600 >> >> # Uncomment the next line to generate "delayed mail" warnings >> #delay_warning_time = 4h >> >> readme_directory = no >> >> # helo vom client erfordert >> smtpd_helo_required = yes >> >> ##### TLS settings ###### >> tls_ssl_options = NO_COMPRESSION >> tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA >> >> ### outgoing connections ### >> smtp_tls_security_level=may >> smtp_tls_protocols = !SSLv2, !SSLv3 >> smtp_tls_ciphers = high >> smtp_tls_loglevel = 1 >> smtp_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem >> smtp_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key >> smtp_tls_session_cache_database = btree:$data_directory/smtp_scache >> >> ### incoming connections ### >> smtpd_tls_auth_only = yes >> smtpd_tls_security_level=may >> smtpd_tls_protocols = !SSLv2, !SSLv3 >> smtpd_tls_ciphers = high >> smtpd_tls_loglevel = 0 >> smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem >> smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key >> smtpd_tls_session_cache_database = btree:$data_directory/smtpd_scache >> >> # SASL Auth >> smtpd_sasl_type = dovecot >> smtpd_sasl_path = private/auth >> smtpd_sasl_auth_enable = yes >> smtpd_sasl_security_options = noanonymous, noplaintext >> smtpd_sasl_tls_security_options = noanonymous >> broken_sasl_auth_clients = yes >> >> # Network >> myhostname = mailserver.example.com > >> myorigin = mailserver.example.com > >> mydestination = localhost mailserver.example.com >> > >> mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 >> recipient_delimiter = + >> inet_interfaces = all >> inet_protocols = all >> unverified_recipient_reject_code = 550 >> >> smtpd_relay_restrictions = >> reject_non_fqdn_recipient >> reject_non_fqdn_sender >> reject_unknown_sender_domain >> reject_unknown_recipient_domain >> reject_unverified_recipient >> reject_unlisted_sender >> reject_unlisted_recipient >> permit_sasl_authenticated >> permit_mynetworks >> check_policy_service inet:127.0.0.1:10023 >> reject_invalid_hostname >> reject_unknown_helo_hostname >> reject_unauth_destination >> reject_sender_login_mismatch >> reject_multi_recipient_bounce >> reject_non_fqdn_helo_hostname >> reject_invalid_helo_hostname >> check_policy_service unix:private/quota-status >> permit >> >> # MySQL Connection >> virtual_alias_maps = >> proxy:mysql:/etc/postfix/virtual/mysql-virtual-user-aliases.cf, >> proxy:mysql:/etc/postfix/virtual/mysql-virtual-domain-aliases.cf >> relay_domains = >> proxy:mysql:/etc/postfix/virtual/mysql-virtual-mailbox-domains.cf >> transport_maps = >> proxy:mysql:/etc/postfix/virtual/mysql-virtual-transports.cf, $relay_domains >> >> Gruß >> Flo >> >> > > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From django at nausch.org Mon May 18 13:01:34 2015 From: django at nausch.org (Django [BOfH]) Date: Mon, 18 May 2015 13:01:34 +0200 Subject: [Postfixbuch-users] Spam Abwehr - aktuelle Techniken? In-Reply-To: <55564140.9010500@cg-networks.de> References: <55564140.9010500@cg-networks.de> Message-ID: <5559C68E.2070409@nausch.org> HI Christian, Am 15.05.2015 um 20:56 schrieb Christian Garling: > Ergänzend > interessiert mich, wie heute state-of-the-art Spam-Abwehr aussieht. Definiere "state-of-the-art" doch mal etwas genauer. Für meinen Teil würde ich das hier mal betrahcten, wenn es in diese Richjtung gehen sollte: https://dokuwiki.nausch.org/doku.php/centos:mail_c7:start Gibt > es neue Tools / Techniken die man sich unbedingt ansehen sollte? Ich nehme nunmehr Postscreen statt postgrey und policyd-weight: https://dokuwiki.nausch.org/doku.php/centos:mail_c7:start#spam-_und_virenschutz_mechanismen_unter_centos_7x Servus Django -- "Bonnie & Clyde der Postmaster-Szene!" approved by Postfix-God http://wetterstation-pliening.info http://dokuwiki.nausch.org http://wiki.piratenpartei.de/Benutzer:Django From ml2013 at andreas-ziegler.de Tue May 19 00:24:49 2015 From: ml2013 at andreas-ziegler.de (Andreas Ziegler) Date: Tue, 19 May 2015 00:24:49 +0200 Subject: [Postfixbuch-users] Spam Abwehr - aktuelle Techniken? In-Reply-To: <5559C68E.2070409@nausch.org> References: <55564140.9010500@cg-networks.de> <5559C68E.2070409@nausch.org> Message-ID: <555A66B1.7010602@andreas-ziegler.de> Hi Django, Am 18.05.2015 um 13:01 schrieb Django [BOfH]: > Ich nehme nunmehr Postscreen statt postgrey und policyd-weight: > https://dokuwiki.nausch.org/doku.php/centos:mail_c7:start#spam-_und_virenschutz_mechanismen_unter_centos_7x was bei der Empfehlung zu postscreen immer wieder vergessen wird: man braucht eine separate IP für die authentifizierten Nutzer, sofern man nicht allen Port 25 austreiben kann. Zweiteres dürfte für viele Provider ziemlicher Aufwand sein und vielleicht sogar zu mancher Kündigung führen, ersteres würde die schon knappe Ressource IPv4 weiter verknappen. Für größere Setups, am Besten auf der grünen Wiese, mag postscreen super sein - keine Frage. Aber in unserer Server-/Kundenstruktur z.B. nicht mit vertretbarem Aufwand umsetzbar. Servus Andreas From django at nausch.org Wed May 20 09:01:47 2015 From: django at nausch.org (django at nausch.org) Date: Wed, 20 May 2015 09:01:47 +0200 Subject: [Postfixbuch-users] Spam Abwehr - aktuelle Techniken? In-Reply-To: <555A66B1.7010602@andreas-ziegler.de> References: <55564140.9010500@cg-networks.de> <5559C68E.2070409@nausch.org> <555A66B1.7010602@andreas-ziegler.de> Message-ID: <20150520090147.Horde.8MFuH29ME1mDTv_vEzOuLVp@xn--bro-hoa.nausch.org> Griasde Andreas, Quoting Andreas Ziegler : > was bei der Empfehlung zu postscreen immer wieder vergessen wird: > man braucht eine separate IP für die authentifizierten Nutzer, sofern > man nicht allen Port 25 austreiben kann. Wieviele der cashcows in Deinem Umfeld nutzen Port 25 zum Einliefern der MUAs nun genau? > Für größere Setups, am Besten auf der grünen Wiese, mag postscreen super > sein - keine Frage. Warum nur "grüne Wiese"? Ich habe alle meine Installation während des laufenden Betriebs umgestellt. Mit ausreichender Kommunikation im Vorfeld, stellen meine Endnutzer um - Mecker gab es bis auf ein paar einschlägige Kandidaten die immer was zum Aussetzenn haben, so gut wie nicht. BTW, die Supportaufwendungen die durch die VoIP-Umstellung der T-Post und ausrollen neuer Router sind erheblich mehr! > Aber in unserer Server-/Kundenstruktur z.B. nicht mit vertretbarem > Aufwand umsetzbar. Das wiederum kannst nur Du bewerte. Ich habe nur einen Vorschlag gemacht, wie man es sehr gut machen kann und nicht wie man es machen muss. ;) Servus Django -- http://dokuwiki.nausch.org http://wetterstation-pliening.info http://ebersberger-liedersammlung.de From meinpapierkorb123 at gmail.com Wed May 20 15:10:50 2015 From: meinpapierkorb123 at gmail.com (Mein Papierkorb) Date: Wed, 20 May 2015 15:10:50 +0200 Subject: [Postfixbuch-users] Mailversand aus Mobilfunknetz Message-ID: <555C87DA.2040806@gmail.com> Hallo zusammen, ich habe aktuell das Problem, dass ein user über meinen Server keine Mails mehr versenden kann. Grund ist, dass die IP seines Mobiltelefons auf der Blacklist zen.spamhaus.org steht. Auch ein Neustart des Telefons half nichts - auch die neue IP steht auf der Blacklist. Es handelt sich um dynamische IP-Adressen der Telekom / T-Mobile. z.B. 79.222.92.82 80.187.109.161 Mich wundert gerade ein wenig, warum der User nicht durchgelassen wird, weil der Absatz "Eigene Nutzer mit Verschlüsselung durchlassen" ja vor den RBLs steht (siehe unten). Dies ist in meinen Augen auch die einzig richtige Vorgehensweise: Authentifizierte User durchlassen, noch vor der RBL Prüfung. So hätte ich es auch gerne. Ich dachte auch der Server sei so konfiguriert - ich hatte auch noch nie solche Probleme, und der Server läuft schon einige jahre so. Scheint nun aber nicht der Fall zu sein. Wie bekomme ich das nun also hin? Wo steckt der Fehler? Weiss jemand Rat? Die aktuelle Konfig: smtpd_recipient_restrictions = #Postmaster und Abuse in jedem Fall annehmen check_recipient_access hash:/etc/postfix/whitelisting #Pruefen mit internen, billigen Mitteln Formalkriterien reject_non_fqdn_sender, reject_non_fqdn_recipient, #Pruefen mit externen, teuren Mitteln ob Domains existieren reject_unknown_sender_domain, reject_unknown_recipient_domain, #Eigene Nutzer mit Verschluesselung durchlassen permit_sasl_authenticated, permit_tls_clientcerts, permit_mynetworks #Greylisting durchfuehren check_policy_service inet:127.0.0.1:10023, #Realtime Blackhole Lists reject_rbl_client zen.spamhaus.org, reject_rbl_client b.barracudacentral.org, reject_rbl_client ix.dnsbl.manitu.net, #Missbrauch als OpenRelay unterbinden reject_unauth_destination, #implizite Standardeinstellung zum Ende permit **************** Auszug aus dem Logfile: server6 postfix/smtpd[24008]: connect from p4FDE5C52.dip0.t-ipconnect.de[79.222.92.82] server6 postgrey[2617]: action=greylist, reason=new, client_name=p4FDE5C52.dip0.t-ipconnect.de, client_address=79.222.92.82, sender=... recipient=... server6 postfix/smtpd[24008]: NOQUEUE: reject: RCPT from p4FDE5C52.dip0.t-ipconnect.de[79.222.92.82]: 554 5.7.1 Service unavailable; Client host [79.222.92.82] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=79.222.92.82; from=<...> to=<...> proto=ESMTP helo=<[192.168.178.21]> server6 postfix/smtpd[24008]: disconnect from p4FDE5C52.dip0.t-ipconnect.de[79.222.92.82] **************** Vielen Dank vorab! Gruß, Markus From kai_postfix at fuerstenberg.ws Wed May 20 15:17:57 2015 From: kai_postfix at fuerstenberg.ws (=?windows-1252?Q?Kai_F=FCrstenberg?=) Date: Wed, 20 May 2015 15:17:57 +0200 Subject: [Postfixbuch-users] Mailversand aus Mobilfunknetz In-Reply-To: <555C87DA.2040806@gmail.com> References: <555C87DA.2040806@gmail.com> Message-ID: <555C8985.1050704@fuerstenberg.ws> Am 20.05.2015 um 15:10 schrieb Mein Papierkorb: > Dies ist in meinen Augen auch die einzig richtige Vorgehensweise: > Authentifizierte User durchlassen, noch vor der RBL Prüfung. > So hätte ich es auch gerne. Ich dachte auch der Server sei so > konfiguriert - ich hatte auch noch nie solche Probleme, und der Server > läuft schon einige jahre so. Scheint nun aber nicht der Fall zu sein. > Wie bekomme ich das nun also hin? Wo steckt der Fehler? Weiss jemand Rat? ich würde den Fehler auf dem Handy suchen. Offenbar erfolgt hier keine Authentifizierung. -- Kai Fürstenberg PM an: kai at fuerstenberg punkt ws From wn at neessen.net Wed May 20 15:18:19 2015 From: wn at neessen.net (Winfried Neessen) Date: Wed, 20 May 2015 15:18:19 +0200 Subject: [Postfixbuch-users] Mailversand aus Mobilfunknetz In-Reply-To: <555C87DA.2040806@gmail.com> References: <555C87DA.2040806@gmail.com> Message-ID: Hi Markus, Am 2015-05-20 15:10, schrieb Mein Papierkorb: > Mich wundert gerade ein wenig, warum der User nicht durchgelassen wird, > weil der Absatz "Eigene Nutzer mit Verschlüsselung durchlassen" ja vor > den RBLs steht (siehe unten). > Was meinst Du mit "eigene Nutzer mit Verschluesselung"? User die sich via SASL authenzifiziert haben? Falls ja siehe unten. > **************** > Auszug aus dem Logfile: > server6 postfix/smtpd[24008]: connect from > p4FDE5C52.dip0.t-ipconnect.de[79.222.92.82] > server6 postgrey[2617]: action=greylist, reason=new, > client_name=p4FDE5C52.dip0.t-ipconnect.de, > client_address=79.222.92.82, sender=... recipient=... > server6 postfix/smtpd[24008]: NOQUEUE: reject: RCPT from > p4FDE5C52.dip0.t-ipconnect.de[79.222.92.82]: > 554 5.7.1 Service unavailable; Client host [79.222.92.82] blocked > using zen.spamhaus.org; > http://www.spamhaus.org/query/bl?ip=79.222.92.82 [1]; from=<...> > to=<...> proto=ESMTP > helo=<[192.168.178.21]> > server6 postfix/smtpd[24008]: disconnect from > p4FDE5C52.dip0.t-ipconnect.de[79.222.92.82] > **************** > Scheinbar hat hier naemlich keine Authentifizierung stattgefunden. Ich wuerde hier einen Log Eintrag in dieser Form erwarten: ,--- | postfix/smtpd[37897]: B313CDE09781: client=p4FDE5C52.dip0.t-ipconnect.de[79.222.92.82], | sasl_method=LOGIN, sasl_username=mysender at address.com `--- Winni From andreas.schulze at datev.de Wed May 20 15:23:14 2015 From: andreas.schulze at datev.de (Andreas Schulze) Date: Wed, 20 May 2015 15:23:14 +0200 Subject: [Postfixbuch-users] Mailversand aus Mobilfunknetz In-Reply-To: <555C87DA.2040806@gmail.com> References: <555C87DA.2040806@gmail.com> Message-ID: <20150520132314.GA2913@spider.services.datevnet.de> Am 20.05.2015 15:10 schrieb Mein Papierkorb: > Dies ist in meinen Augen auch die einzig richtige Vorgehensweise: > Authentifizierte User durchlassen, noch vor der RBL Prüfung. pruefe, dass Auth wirklich stattfindet: - postconf -e "debug_peer_list = 79.222.92.82"; postfix reload - Mail versenden - postconf -e "debug_peer_list ="; postfix reload - log ansehen... -- Andreas Schulze Internetdienste | P252 DATEV eG 90329 Nürnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196 E-Mail info at datev.de | Internet www.datev.de Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg Nr.70 Vorstand Prof. Dieter Kempf (Vorsitzender) Dr. Robert Mayr (stellv. Vorsitzender) Eckhard Schwarzer (stellv. Vorsitzender) Dr. Peter Krug Jörg Rabe von Pappenheim Vorsitzender des Aufsichtsrates: Dirk Schmale From postfixbuch-users at 0xaffe.de Wed May 20 15:18:50 2015 From: postfixbuch-users at 0xaffe.de (Mathias Jeschke) Date: Wed, 20 May 2015 15:18:50 +0200 Subject: [Postfixbuch-users] Mailversand aus Mobilfunknetz In-Reply-To: <555C87DA.2040806@gmail.com> References: <555C87DA.2040806@gmail.com> Message-ID: <555C89BA.7030205@0xaffe.de> Hallo Papierkorb, Am 20.05.15 um 15:10 schrieb Mein Papierkorb: > Mich wundert gerade ein wenig, warum der User nicht durchgelassen wird, > weil der Absatz "Eigene Nutzer mit Verschlüsselung durchlassen" ja vor > den RBLs steht (siehe unten). Weil der Nutzer sich nicht per SMTP-Auth an Deinem Server anmeldet. Viele Grüße, Mathias. From gregor at a-mazing.de Wed May 20 15:17:33 2015 From: gregor at a-mazing.de (Gregor Hermens) Date: Wed, 20 May 2015 15:17:33 +0200 Subject: [Postfixbuch-users] Mailversand aus Mobilfunknetz In-Reply-To: <555C87DA.2040806@gmail.com> References: <555C87DA.2040806@gmail.com> Message-ID: <201505201517.34137@office.a-mazing.net> Hallo Markus, Am Mittwoch, 20. Mai 2015 schrieb Mein Papierkorb: > Mich wundert gerade ein wenig, warum der User nicht durchgelassen wird, > weil der Absatz "Eigene Nutzer mit Verschlüsselung durchlassen" ja vor > den RBLs steht (siehe unten). > > **************** > Auszug aus dem Logfile: > server6 postfix/smtpd[24008]: connect from > p4FDE5C52.dip0.t-ipconnect.de[79.222.92.82] > server6 postgrey[2617]: action=greylist, reason=new, > client_name=p4FDE5C52.dip0.t-ipconnect.de, client_address=79.222.92.82, > sender=... recipient=... > server6 postfix/smtpd[24008]: NOQUEUE: reject: RCPT from > p4FDE5C52.dip0.t-ipconnect.de[79.222.92.82]: 554 5.7.1 Service > unavailable; Client host [79.222.92.82] blocked using zen.spamhaus.org; > http://www.spamhaus.org/query/bl?ip=79.222.92.82; from=<...> to=<...> > proto=ESMTP helo=<[192.168.178.21]> > server6 postfix/smtpd[24008]: disconnect from > p4FDE5C52.dip0.t-ipconnect.de[79.222.92.82] > **************** ich sehe hier keine Authentifizierung, also macht dein Postfix wohl alles richtig...? Gruß, Gregor -- @mazing fon +49 8142 6528665 Gregor Hermens fax +49 8142 6528669 Brucker Strasse 12 gregor.hermens at a-mazing.de D-82216 Gernlinden http://www.a-mazing.de/ From klaus at tachtler.net Wed May 20 16:46:25 2015 From: klaus at tachtler.net (Klaus Tachtler) Date: Wed, 20 May 2015 16:46:25 +0200 Subject: [Postfixbuch-users] Mailversand aus Mobilfunknetz In-Reply-To: <555C87DA.2040806@gmail.com> Message-ID: <20150520164625.Horde.06RXUrZGKfHpaPFrG8LOXWK@buero.tachtler.net> Hallo, suche mal in einer Suchmaschine Deines Vertrauens nach: submission Port 587 hier geht es um einen Zugriff auf Deinen e-Mail-Server nicht über Port 25 ohne Authentifizierung, SONDERN über z.B. Port 587 und "Anmeldung" das DU es wirklich bist, dann kann Dir die IP-Adresse egal sein, da Du Dich ja "Ausweisen" kannst. Mal ganz einfach und platt erklärt! Grüße Klaus. > Hallo zusammen, > > ich habe aktuell das Problem, dass ein user über meinen Server keine > Mails mehr versenden kann. > Grund ist, dass die IP seines Mobiltelefons auf der Blacklist > zen.spamhaus.org steht. > Auch ein Neustart des Telefons half nichts - auch die neue IP steht > auf der Blacklist. > Es handelt sich um dynamische IP-Adressen der Telekom / T-Mobile. > z.B. > 79.222.92.82 > 80.187.109.161 > > Mich wundert gerade ein wenig, warum der User nicht durchgelassen > wird, weil der Absatz "Eigene Nutzer mit Verschlüsselung > durchlassen" ja vor den RBLs steht (siehe unten). > > Dies ist in meinen Augen auch die einzig richtige Vorgehensweise: > Authentifizierte User durchlassen, noch vor der RBL Prüfung. > So hätte ich es auch gerne. Ich dachte auch der Server sei so > konfiguriert - ich hatte auch noch nie solche Probleme, und der > Server läuft schon einige jahre so. Scheint nun aber nicht der Fall > zu sein. > Wie bekomme ich das nun also hin? Wo steckt der Fehler? Weiss jemand Rat? > > Die aktuelle Konfig: > smtpd_recipient_restrictions = > #Postmaster und Abuse in jedem Fall annehmen > check_recipient_access hash:/etc/postfix/whitelisting > #Pruefen mit internen, billigen Mitteln Formalkriterien > reject_non_fqdn_sender, > reject_non_fqdn_recipient, > #Pruefen mit externen, teuren Mitteln ob Domains existieren > reject_unknown_sender_domain, > reject_unknown_recipient_domain, > #Eigene Nutzer mit Verschluesselung durchlassen > permit_sasl_authenticated, > permit_tls_clientcerts, > permit_mynetworks > #Greylisting durchfuehren > check_policy_service inet:127.0.0.1:10023, > #Realtime Blackhole Lists > reject_rbl_client zen.spamhaus.org, > reject_rbl_client b.barracudacentral.org, > reject_rbl_client ix.dnsbl.manitu.net, > #Missbrauch als OpenRelay unterbinden > reject_unauth_destination, > #implizite Standardeinstellung zum Ende > permit > > > **************** > Auszug aus dem Logfile: > server6 postfix/smtpd[24008]: connect from > p4FDE5C52.dip0.t-ipconnect.de[79.222.92.82] > server6 postgrey[2617]: action=greylist, reason=new, > client_name=p4FDE5C52.dip0.t-ipconnect.de, > client_address=79.222.92.82, sender=... recipient=... > server6 postfix/smtpd[24008]: NOQUEUE: reject: RCPT from > p4FDE5C52.dip0.t-ipconnect.de[79.222.92.82]: 554 5.7.1 Service > unavailable; Client host [79.222.92.82] blocked using > zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=79.222.92.82; > from=<...> to=<...> proto=ESMTP helo=<[192.168.178.21]> > server6 postfix/smtpd[24008]: disconnect from > p4FDE5C52.dip0.t-ipconnect.de[79.222.92.82] > **************** > > Vielen Dank vorab! > > Gruß, > Markus > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users ----- Ende der Nachricht von Mein Papierkorb ----- -- ------------------------------------------ e-Mail : klaus at tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------ From atann at alphasrv.net Wed May 20 16:40:18 2015 From: atann at alphasrv.net (Andre Tann) Date: Wed, 20 May 2015 16:40:18 +0200 Subject: [Postfixbuch-users] Mailversand aus Mobilfunknetz In-Reply-To: <555C87DA.2040806@gmail.com> References: <555C87DA.2040806@gmail.com> Message-ID: <555C959A.1000809@alphasrv.net> Moin, ergänzend zu den anderen Beiträgen noch folgender Gedanke: Am 20.05.2015 um 15:10 schrieb Mein Papierkorb: > server6 postfix/smtpd[24008]: connect from > p4FDE5C52.dip0.t-ipconnect.de[79.222.92.82] > server6 postgrey[2617]: action=greylist, reason=new, > client_name=p4FDE5C52.dip0.t-ipconnect.de, client_address=79.222.92.82, > sender=... recipient=... Hieran siehst Du, daß der User sich nicht authentifiziert, denn Du hast: > #Eigene Nutzer mit Verschluesselung durchlassen > permit_sasl_authenticated, > permit_tls_clientcerts, > permit_mynetworks > #Greylisting durchfuehren > check_policy_service inet:127.0.0.1:10023, Wäre er authentifiziert, dann käme er gar nicht bis zum Greylisting. Viele Grüße! -- Andre Tann From listserv at xtlv.cn Wed May 20 23:05:14 2015 From: listserv at xtlv.cn (Mario Arnold) Date: Wed, 20 May 2015 23:05:14 +0200 Subject: [Postfixbuch-users] smtpd Ciphers-Optionen Message-ID: <555CF70A.307@xtlv.cn> Hallo, ich hätte bzgl. der beiden folgenden Optionen, den genauen Unterschied verstanden. Vielleicht könnte mir das jemand erklären. smtpd_tls_exclude_ciphers smtpd_tls_mandatory_exclude_ciphers Vielen Dank schon mal. Mario -- Persönlich IS0-Zertifiziert in angewandter Kompetenzsimulation. From andreas.schulze at datev.de Thu May 21 07:22:13 2015 From: andreas.schulze at datev.de (Andreas Schulze) Date: Thu, 21 May 2015 07:22:13 +0200 Subject: [Postfixbuch-users] smtpd Ciphers-Optionen In-Reply-To: <555CF70A.307@xtlv.cn> References: <555CF70A.307@xtlv.cn> Message-ID: <20150521052213.GA3529@spider.services.datevnet.de> Am 20.05.2015 23:05 schrieb Mario Arnold: > ich hätte bzgl. der beiden folgenden Optionen, den genauen Unterschied verstanden. > Vielleicht könnte mir das jemand erklären. > > smtpd_tls_exclude_ciphers Cipher, die bei opportinistischem TLS nicht verwendet werden http://www.postfix.org/postconf.5.html#smtpd_tls_exclude_ciphers > smtpd_tls_mandatory_exclude_ciphers Cipher, die bei erzwungenem TLS (smtpd_tls_security_level = encrypt) nicht verwendet werden http://www.postfix.org/postconf.5.html#smtpd_tls_mandatory_exclude_ciphers -- Andreas Schulze Internetdienste | P252 DATEV eG 90329 Nürnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196 E-Mail info at datev.de | Internet www.datev.de Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg Nr.70 Vorstand Prof. Dieter Kempf (Vorsitzender) Dr. Robert Mayr (stellv. Vorsitzender) Eckhard Schwarzer (stellv. Vorsitzender) Dr. Peter Krug Jörg Rabe von Pappenheim Vorsitzender des Aufsichtsrates: Dirk Schmale From ralf.hansen2000 at yahoo.de Thu May 21 10:59:17 2015 From: ralf.hansen2000 at yahoo.de (Ralf Hansen) Date: Thu, 21 May 2015 10:59:17 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <5556243B.6090408@rolandschnabel.de> References: <5556171D.5020000@yahoo.de> <5556243B.6090408@rolandschnabel.de> Message-ID: <555D9E65.40304@yahoo.de> Hallo Roland, vielen Dank für die ausführlichen Tipps. Vermutlich liegt mein Problem an der Reverse-DNS-Auflösung (sprich: dig -x 10.100.120.251). Es gibt in diesem Umfeld kein DNS/Reverse-DNS und ich kenne keinen Weg, meinen Host hier zu überlisten, da die /etc/hosts Datei ja nur vorwärts-Auflösung macht. Dann kann ich da vermutlich nichts tun oder hat noch jemand ne Idee? Die Zertifikatskette ist soweit schlüssig und alle Zertifikate sind eingebunden, daher ergibt der manuelle Test mit "openssl s_client" auch keine Fehler. ("Verify return code: 0 (ok)"), aber vermutlich wird hier nicht reverse-DNS geprüft. Postfix läuft nicht im chroot... Schöne Grüße, Ralf Am 15.05.2015 um 18:52 schrieb Roland Schnabel: > Hallo Ralf, > > ich würde mal folgende Punkte prüfen: > > 1. > "tls_append_default_CA = yes" beim SMTP-Client setzen. Das hatte bei > mir mal ähnliche Probleme verursacht. > > 2. > Ist der DNS-Name im Server-Zertifikat (ggf. unter Alternate DNS-Names) > auch derjenige, den der SMTP-Client per DNS auflösen kann? (sprich: > dig -x 10.100.120.251) > > 3. > Bei der Ausgabe von "openssl s_client ..." auf dem SMTP-Client nochmal > GENAU die gesamte Zertifikatskette prüfen. Die wird gleich am Anfang > ausgegeben. Falls dort Fehler auftreten, gibt das ähnliche Probleme. > > 4. > Sicherstellen dass das Zertifikatsverzeichnis auch wirklich vom > Postfix gelesen werden kann (s. Chroot-Umgebung von Postfix, selinux, > Apparmor, etc.). > > Viele Grüße, > Roland > > > -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From p at sys4.de Thu May 21 11:29:42 2015 From: p at sys4.de (Patrick Ben Koetter) Date: Thu, 21 May 2015 11:29:42 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <555D9E65.40304@yahoo.de> References: <5556171D.5020000@yahoo.de> <5556243B.6090408@rolandschnabel.de> <555D9E65.40304@yahoo.de> Message-ID: <20150521092942.GE14670@sys4.de> Hat Dein smtp-Client Zugriff auf die Zertifikate über smtp_tls_CAfile? Wenn nicht, dann kann er sein gegenüber nicht identifizieren und loggt "untrusted". p at rick * Ralf Hansen : > Hallo Roland, > > vielen Dank für die ausführlichen Tipps. > > Vermutlich liegt mein Problem an der Reverse-DNS-Auflösung (sprich: > dig -x 10.100.120.251). > Es gibt in diesem Umfeld kein DNS/Reverse-DNS und ich kenne keinen > Weg, meinen Host hier zu überlisten, da die /etc/hosts Datei ja nur > vorwärts-Auflösung macht. > Dann kann ich da vermutlich nichts tun oder hat noch jemand ne Idee? > > Die Zertifikatskette ist soweit schlüssig und alle Zertifikate sind > eingebunden, daher ergibt der manuelle Test mit "openssl s_client" > auch keine Fehler. ("Verify return code: 0 (ok)"), > aber vermutlich wird hier nicht reverse-DNS geprüft. > > Postfix läuft nicht im chroot... > > Schöne Grüße, Ralf > > > > Am 15.05.2015 um 18:52 schrieb Roland Schnabel: > >Hallo Ralf, > > > >ich würde mal folgende Punkte prüfen: > > > >1. > >"tls_append_default_CA = yes" beim SMTP-Client setzen. Das hatte > >bei mir mal ähnliche Probleme verursacht. > > > >2. > >Ist der DNS-Name im Server-Zertifikat (ggf. unter Alternate > >DNS-Names) auch derjenige, den der SMTP-Client per DNS auflösen > >kann? (sprich: dig -x 10.100.120.251) > > > >3. > >Bei der Ausgabe von "openssl s_client ..." auf dem SMTP-Client > >nochmal GENAU die gesamte Zertifikatskette prüfen. Die wird gleich > >am Anfang ausgegeben. Falls dort Fehler auftreten, gibt das > >ähnliche Probleme. > > > >4. > >Sicherstellen dass das Zertifikatsverzeichnis auch wirklich vom > >Postfix gelesen werden kann (s. Chroot-Umgebung von Postfix, > >selinux, Apparmor, etc.). > > > >Viele Grüße, > >Roland > > > > > > > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From ralf.hansen2000 at yahoo.de Thu May 21 12:29:51 2015 From: ralf.hansen2000 at yahoo.de (Ralf Hansen) Date: Thu, 21 May 2015 12:29:51 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <20150521092942.GE14670@sys4.de> References: <5556171D.5020000@yahoo.de> <5556243B.6090408@rolandschnabel.de> <555D9E65.40304@yahoo.de> <20150521092942.GE14670@sys4.de> Message-ID: <555DB39F.1070807@yahoo.de> Hallo patrick, in der Datei "/etc/ssl/certs/alle-meine-certs.pem" sind alle Zertifikate (Root und Intermediate-CA) aneinandergehängt. relayhost = 10.100.120.251 smtp_tls_CAfile = /etc/ssl/certs/alle-meine-certs.pem smtp_tls_loglevel = 1 smtp_tls_security_level = may und trotzdem erhalte ich: May 21 12:11:47 maschine postfix-instanz-01/smtp[40223]: Untrusted TLS connection established to 10.100.120.251[10.100.120.251]:25: TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits) Ich gehe auch davon aus, dass der Postfix die Datei korrekt einlesen kann, denn wenn ich den Pfad bewusst falsch setze, kommt die Meldung "cannot load Certificate Authority data". Im Zertifikat des Relayhosts (10.100.120.251) steht als CN: interner-server.mein-netz.de Aber selbst bei Einrichtung eine Eintrages in /etc/hosts 10.100.120.251 interner-server.mein-netz.de und Nutzung von relayhost = interner-server.mein-netz.de erhalte ich eine Untrusted TLS connection? Gruß Ralf Am 21.05.2015 um 11:29 schrieb Patrick Ben Koetter: > Hat Dein smtp-Client Zugriff auf die Zertifikate über smtp_tls_CAfile? Wenn > nicht, dann kann er sein gegenüber nicht identifizieren und loggt "untrusted". > > p at rick > > From mail at f4bs.eu Thu May 21 19:15:13 2015 From: mail at f4bs.eu (Fabian Schirmer) Date: Thu, 21 May 2015 19:15:13 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <555DB39F.1070807@yahoo.de> References: <5556171D.5020000@yahoo.de> <5556243B.6090408@rolandschnabel.de> <555D9E65.40304@yahoo.de> <20150521092942.GE14670@sys4.de> <555DB39F.1070807@yahoo.de> Message-ID: <555E12A1.2030309@f4bs.eu> Hallo zusammen, stört sich hier denn niemand am Anonymous DH Keyexchange? > TLSv1 with cipher *ADH*-CAMELLIA256-SHA (256/256 bits) MfG Fabian -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From info at rolandschnabel.de Thu May 21 20:13:21 2015 From: info at rolandschnabel.de (Roland Schnabel) Date: Thu, 21 May 2015 20:13:21 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <555DB39F.1070807@yahoo.de> References: <5556171D.5020000@yahoo.de> <5556243B.6090408@rolandschnabel.de> <555D9E65.40304@yahoo.de> <20150521092942.GE14670@sys4.de> <555DB39F.1070807@yahoo.de> Message-ID: <555E2041.3040701@rolandschnabel.de> On 21.05.2015 12:29, Ralf Hansen wrote: > > Aber selbst bei Einrichtung eine Eintrages in /etc/hosts > 10.100.120.251 interner-server.mein-netz.de > > und Nutzung von > relayhost = interner-server.mein-netz.de > > erhalte ich eine Untrusted TLS connection? > Postfix ignoriert /etc/hosts per Default: smtp_host_lookup = dns -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 4258 bytes Beschreibung: S/MIME Cryptographic Signature URL : From meinpapierkorb123 at gmail.com Thu May 21 21:04:36 2015 From: meinpapierkorb123 at gmail.com (Mein Papierkorb) Date: Thu, 21 May 2015 21:04:36 +0200 Subject: [Postfixbuch-users] Mailversand aus Mobilfunknetz In-Reply-To: <555C959A.1000809@alphasrv.net> References: <555C87DA.2040806@gmail.com> <555C959A.1000809@alphasrv.net> Message-ID: <555E2C44.3030003@gmail.com> Hallo zusammen, vielen Dank für die schnelle Hilfe! Daran hats gelegen! Gruß, Markus Am 20.05.2015 um 16:40 schrieb Andre Tann: > Moin, > > ergänzend zu den anderen Beiträgen noch folgender Gedanke: > > Am 20.05.2015 um 15:10 schrieb Mein Papierkorb: > >> server6 postfix/smtpd[24008]: connect from >> p4FDE5C52.dip0.t-ipconnect.de[79.222.92.82] >> server6 postgrey[2617]: action=greylist, reason=new, >> client_name=p4FDE5C52.dip0.t-ipconnect.de, client_address=79.222.92.82, >> sender=... recipient=... > Hieran siehst Du, daß der User sich nicht authentifiziert, denn Du hast: > >> #Eigene Nutzer mit Verschluesselung durchlassen >> permit_sasl_authenticated, >> permit_tls_clientcerts, >> permit_mynetworks >> #Greylisting durchfuehren >> check_policy_service inet:127.0.0.1:10023, > Wäre er authentifiziert, dann käme er gar nicht bis zum Greylisting. > > Viele Grüße! > From w.flamme at web.de Fri May 22 07:49:57 2015 From: w.flamme at web.de (Werner Flamme) Date: Fri, 22 May 2015 07:49:57 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <555D9E65.40304@yahoo.de> References: <5556171D.5020000@yahoo.de> <5556243B.6090408@rolandschnabel.de> <555D9E65.40304@yahoo.de> Message-ID: <555EC385.30204@web.de> Ralf Hansen [21.05.2015 10:59]: > Hallo Roland, > > vielen Dank für die ausführlichen Tipps. > > Vermutlich liegt mein Problem an der Reverse-DNS-Auflösung (sprich: dig > -x 10.100.120.251). > Es gibt in diesem Umfeld kein DNS/Reverse-DNS und ich kenne keinen Weg, > meinen Host hier zu überlisten, da die /etc/hosts Datei ja nur > vorwärts-Auflösung macht. > Dann kann ich da vermutlich nichts tun oder hat noch jemand ne Idee? Ich löse das (unter SLES 11 + 12) mit DNSmasq. Das liest per default die /etc/hosts und stellt die Einträge forward und reverse zur Verfügung :). Habe dann nur als 1. Nameserver 127.0.0.1 eingetragen. DNSmasq ist im SLES-Pool enthalten, es gab zuletzt Updates auf Version dnsmasq-2.71-0.11.1.x86_64.rpm. HDH, Werner -- From w.flamme at web.de Fri May 22 07:53:25 2015 From: w.flamme at web.de (Werner Flamme) Date: Fri, 22 May 2015 07:53:25 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <555E2041.3040701@rolandschnabel.de> References: <5556171D.5020000@yahoo.de> <5556243B.6090408@rolandschnabel.de> <555D9E65.40304@yahoo.de> <20150521092942.GE14670@sys4.de> <555DB39F.1070807@yahoo.de> <555E2041.3040701@rolandschnabel.de> Message-ID: <555EC455.7070801@web.de> Roland Schnabel [21.05.2015 20:13]: > > On 21.05.2015 12:29, Ralf Hansen wrote: >> >> Aber selbst bei Einrichtung eine Eintrages in /etc/hosts >> 10.100.120.251 interner-server.mein-netz.de >> >> und Nutzung von >> relayhost = interner-server.mein-netz.de >> >> erhalte ich eine Untrusted TLS connection? >> > > Postfix ignoriert /etc/hosts per Default: > smtp_host_lookup = dns Trusted oder nicht hat nichts mit DNS zu tun, sondern damit, ob die Zertifikatskette anerkannt wird. Das Root-Zertifikat der Kette sollte in dem Verzeichnis liegen, das mit smtp_tls_CApath definiert wird (für ausgehende Verbindungen; für eingehende ist es smtpd_tls_CApath). HDH, Werner -- From lists at xunil.at Fri May 22 10:45:49 2015 From: lists at xunil.at (Stefan G. Weichinger) Date: Fri, 22 May 2015 10:45:49 +0200 Subject: [Postfixbuch-users] postscreen und MS Office Message-ID: <555EECBD.2020008@xunil.at> Ich sehe hier Probleme mit postscreen und Mails von emea01-db3-obe.outbound.protection.outlook.com Diese(r) Server kommt andauernd mit anderen IPs daher, ich hab schon versucht, ganze Subnetze in postscreen_access.cidr frei zu schalten, aber da kommt man wohl nicht hinter her. Kennt jemand die Problematik und hat einen schlauen Tip? Eine Domain aus postscreen ausnehmen geht ja nicht, oder? danke, Grüße, Stefan From andreas.schulze at datev.de Fri May 22 12:04:01 2015 From: andreas.schulze at datev.de (Andreas Schulze) Date: Fri, 22 May 2015 12:04:01 +0200 Subject: [Postfixbuch-users] postscreen und MS Office In-Reply-To: <555EECBD.2020008@xunil.at> References: <555EECBD.2020008@xunil.at> Message-ID: <20150522100401.GA27556@spider.services.datevnet.de> Am 22.05.2015 10:45 schrieb Stefan G. Weichinger: > Ich sehe hier Probleme mit postscreen und Mails von > > emea01-db3-obe.outbound.protection.outlook.com > > Diese(r) Server kommt andauernd mit anderen IPs daher, ich hab schon > versucht, ganze Subnetze in postscreen_access.cidr frei zu schalten, > aber da kommt man wohl nicht hinter her. > > Kennt jemand die Problematik und hat einen schlauen Tip? da ist kein Problem, was *Du* lösen kannst/musst. Microsoft wird doch hoffentlich Mailserver betreiben. Und die kommen per Definition damit klar. Wenn nicht, ist das ein Problem des Versenders. Es ist das gute Recht eines Versenders, für jede Mail eine neue QuellIP zu benutzen. Ob es hilfreich ist, muss der Versender für sich abwägen :-) > Eine Domain aus postscreen ausnehmen geht ja nicht, oder? nein, denn postscreen kennt nur IP-Adressen. -- Andreas Schulze Internetdienste | P252 DATEV eG 90329 Nürnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196 E-Mail info at datev.de | Internet www.datev.de Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg Nr.70 Vorstand Prof. Dieter Kempf (Vorsitzender) Dr. Robert Mayr (stellv. Vorsitzender) Eckhard Schwarzer (stellv. Vorsitzender) Dr. Peter Krug Jörg Rabe von Pappenheim Vorsitzender des Aufsichtsrates: Dirk Schmale From daniel at ist-immer-online.de Fri May 22 13:06:57 2015 From: daniel at ist-immer-online.de (Daniel) Date: Fri, 22 May 2015 13:06:57 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <555EC455.7070801@web.de> References: <5556171D.5020000@yahoo.de> <5556243B.6090408@rolandschnabel.de> <555D9E65.40304@yahoo.de> <20150521092942.GE14670@sys4.de> <555DB39F.1070807@yahoo.de> <555E2041.3040701@rolandschnabel.de> <555EC455.7070801@web.de> Message-ID: <001c01d0947f$6b994a70$42cbdf50$@ist-immer-online.de> Guten Tag, ich habe ein ähnliches Anliegen. Im Maillog steht beim Versenden von Mails z.B.: postfix/smtp: Untrusted TLS connection established to mail.x.de[x.x.x.x]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Darauf hin habe ich habe ich mal main.cf geschaut nach dem in den Mail vom Werner bei den genannten Parameter. Dort habe ich nur gefunden: smtpd_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem smtpd_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key Dieses bezieht sich dann ja wohl nur für eingehende Verbindung, also müsste ich z.B. smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key hinzufügen damit auch für ausgehende Verbindung Zertifikat verwendet wird und das untrustet verschwindet? Bin noch dabei mich mit ganzen Materie stärker vertraut zumachen. Gruß Daniel -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Werner Flamme Gesendet: Freitag, 22. Mai 2015 07:53 An: postfixbuch-users at listen.jpberlin.de Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES Roland Schnabel [21.05.2015 20:13]: > > On 21.05.2015 12:29, Ralf Hansen wrote: >> >> Aber selbst bei Einrichtung eine Eintrages in /etc/hosts >> 10.100.120.251 interner-server.mein-netz.de >> >> und Nutzung von >> relayhost = interner-server.mein-netz.de >> >> erhalte ich eine Untrusted TLS connection… >> > > Postfix ignoriert /etc/hosts per Default: > smtp_host_lookup = dns Trusted oder nicht hat nichts mit DNS zu tun, sondern damit, ob die Zertifikatskette anerkannt wird. Das Root-Zertifikat der Kette sollte in dem Verzeichnis liegen, das mit smtp_tls_CApath definiert wird (für ausgehende Verbindungen; für eingehende ist es smtpd_tls_CApath). HDH, Werner -- -- _______________________________________________ Postfixbuch-users -- http://www.postfixbuch.de Heinlein Professional Linux Support GmbH Postfixbuch-users at listen.jpberlin.de https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users From p at sys4.de Fri May 22 13:26:45 2015 From: p at sys4.de (Patrick Ben Koetter) Date: Fri, 22 May 2015 13:26:45 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <001c01d0947f$6b994a70$42cbdf50$@ist-immer-online.de> References: <5556171D.5020000@yahoo.de> <5556243B.6090408@rolandschnabel.de> <555D9E65.40304@yahoo.de> <20150521092942.GE14670@sys4.de> <555DB39F.1070807@yahoo.de> <555E2041.3040701@rolandschnabel.de> <555EC455.7070801@web.de> <001c01d0947f$6b994a70$42cbdf50$@ist-immer-online.de> Message-ID: <20150522112644.GC24854@sys4.de> * Daniel : > Guten Tag, > > ich habe ein ähnliches Anliegen. > > Im Maillog steht beim Versenden von Mails z.B.: > postfix/smtp: Untrusted TLS connection established to mail.x.de[x.x.x.x]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 > (256/256 bits) > > Darauf hin habe ich habe ich mal main.cf geschaut nach dem in den Mail vom Werner bei den genannten Parameter. > > Dort habe ich nur gefunden: > smtpd_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > smtpd_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > > Dieses bezieht sich dann ja wohl nur für eingehende Verbindung, also müsste ich z.B. > smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > > hinzufügen damit auch für ausgehende Verbindung Zertifikat verwendet wird und das untrustet verschwindet? Nein. Mit Deiner Änderung könnte der Postfix smtp-Client sich einem Server gegenüber ausweisen, wenn - das Zertifikat für Client Usage geeignet ist - der Server das Client-Zertifikat anfragt Du musst smtp_tls_CAfile setzen, damit der Client die Zertifikate anderer SMTP-Server verifizieren kann, z.B.: smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt p at rick > > Bin noch dabei mich mit ganzen Materie stärker vertraut zumachen. > > Gruß Daniel > > > -----Ursprüngliche Nachricht----- > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Werner Flamme > Gesendet: Freitag, 22. Mai 2015 07:53 > An: postfixbuch-users at listen.jpberlin.de > Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > > Roland Schnabel [21.05.2015 20:13]: > > > > On 21.05.2015 12:29, Ralf Hansen wrote: > >> > >> Aber selbst bei Einrichtung eine Eintrages in /etc/hosts > >> 10.100.120.251 interner-server.mein-netz.de > >> > >> und Nutzung von > >> relayhost = interner-server.mein-netz.de > >> > >> erhalte ich eine Untrusted TLS connection > >> > > > > Postfix ignoriert /etc/hosts per Default: > > smtp_host_lookup = dns > > Trusted oder nicht hat nichts mit DNS zu tun, sondern damit, ob die > Zertifikatskette anerkannt wird. Das Root-Zertifikat der Kette sollte in > dem Verzeichnis liegen, das mit smtp_tls_CApath definiert wird (für > ausgehende Verbindungen; für eingehende ist es smtpd_tls_CApath). > > HDH, Werner > > -- > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users > > > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From daniel at ist-immer-online.de Fri May 22 13:56:49 2015 From: daniel at ist-immer-online.de (Daniel) Date: Fri, 22 May 2015 13:56:49 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <20150522112644.GC24854@sys4.de> References: <5556171D.5020000@yahoo.de> <5556243B.6090408@rolandschnabel.de> <555D9E65.40304@yahoo.de> <20150521092942.GE14670@sys4.de> <555DB39F.1070807@yahoo.de> <555E2041.3040701@rolandschnabel.de> <555EC455.7070801@web.de> <001c01d0947f$6b994a70$42cbdf50$@ist-immer-online.de> <20150522112644.GC24854@sys4.de> Message-ID: <005801d09486$62c328b0$28497a10$@ist-immer-online.de> Hallo Patrick, danke für die Antwort, leider klappt es nicht., weiterhin untrustet zum externen Mailrelay. Ich habe probiert smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt und dann noch smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt Weitere Optionen mit smtp_ in der main.cf sind: smtp_tls_security_level = may smtp_tls_loglevel = 1 smtp_tls_fingerprint_digest = sha1 smtp_tls_note_starttls_offer = yes smtp_host_lookup = dns, native smtp_use_tls = yes Gruß Daniel -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter Gesendet: Freitag, 22. Mai 2015 13:27 An: postfixbuch-users at listen.jpberlin.de Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES * Daniel : > Guten Tag, > > ich habe ein ähnliches Anliegen. > > Im Maillog steht beim Versenden von Mails z.B.: > postfix/smtp: Untrusted TLS connection established to mail.x.de[x.x.x.x]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 > (256/256 bits) > > Darauf hin habe ich habe ich mal main.cf geschaut nach dem in den Mail vom Werner bei den genannten Parameter. > > Dort habe ich nur gefunden: > smtpd_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > smtpd_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > > Dieses bezieht sich dann ja wohl nur für eingehende Verbindung, also müsste ich z.B. > smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > > hinzufügen damit auch für ausgehende Verbindung Zertifikat verwendet wird und das untrustet verschwindet? Nein. Mit Deiner Änderung könnte der Postfix smtp-Client sich einem Server gegenüber ausweisen, wenn - das Zertifikat für Client Usage geeignet ist - der Server das Client-Zertifikat anfragt Du musst smtp_tls_CAfile setzen, damit der Client die Zertifikate anderer SMTP-Server verifizieren kann, z.B.: smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt p at rick > > Bin noch dabei mich mit ganzen Materie stärker vertraut zumachen. > > Gruß Daniel > > > -----Ursprüngliche Nachricht----- > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Werner Flamme > Gesendet: Freitag, 22. Mai 2015 07:53 > An: postfixbuch-users at listen.jpberlin.de > Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > > Roland Schnabel [21.05.2015 20:13]: > > > > On 21.05.2015 12:29, Ralf Hansen wrote: > >> > >> Aber selbst bei Einrichtung eine Eintrages in /etc/hosts > >> 10.100.120.251 interner-server.mein-netz.de > >> > >> und Nutzung von > >> relayhost = interner-server.mein-netz.de > >> > >> erhalte ich eine Untrusted TLS connection… > >> > > > > Postfix ignoriert /etc/hosts per Default: > > smtp_host_lookup = dns > > Trusted oder nicht hat nichts mit DNS zu tun, sondern damit, ob die > Zertifikatskette anerkannt wird. Das Root-Zertifikat der Kette sollte in > dem Verzeichnis liegen, das mit smtp_tls_CApath definiert wird (für > ausgehende Verbindungen; für eingehende ist es smtpd_tls_CApath). > > HDH, Werner > > -- > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users > > > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein -- _______________________________________________ Postfixbuch-users -- http://www.postfixbuch.de Heinlein Professional Linux Support GmbH Postfixbuch-users at listen.jpberlin.de https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users From atann at alphasrv.net Fri May 22 13:57:08 2015 From: atann at alphasrv.net (Andre Tann) Date: Fri, 22 May 2015 13:57:08 +0200 Subject: [Postfixbuch-users] postscreen und MS Office In-Reply-To: <555EECBD.2020008@xunil.at> References: <555EECBD.2020008@xunil.at> Message-ID: <555F15F4.10307@alphasrv.net> Moin, Am 22.05.2015 um 10:45 schrieb Stefan G. Weichinger: > Ich sehe hier Probleme mit postscreen und Mails von > > emea01-db3-obe.outbound.protection.outlook.com > > Diese(r) Server kommt andauernd mit anderen IPs daher, ich hab schon > versucht, ganze Subnetze in postscreen_access.cidr frei zu schalten, > aber da kommt man wohl nicht hinter her. > > Kennt jemand die Problematik und hat einen schlauen Tip? Das Problem kenn ich. Es gibt im Grunde zwei Möglichkeiten: 1. Du hast viel Traffic von /.*outbound\.protection\.outlook\.com/. Dann erledigt sich das von alleine, weil irgendwann alle gewhitelistet sind. Bis dahin allerdings werden die User jammern, weil es Verzögerungen von einem Tag oder mehr geben kann. 2. Du whitelistest /.*outbound\.protection\.outlook\.com/ bei postscreen: /etc/postfix/main.cf: postscreen_access_list = ..., pcre:/etc/postfix/postscreen_access.pcre /etc/postfix/postscreen_access.pcre: /.*outbound\.protection\.outlook\.com/ permit => ungetestet aus dem Kopf geschrieben. Damit winkst Du alle outbound Server durch. Das sind IIRC 120 Stück oder so. Wenn man drauf warten will, daß die wirklich alle mal gewhitelistet sind, dann braucht man schon einiges an Verkehr von dort. -- Andre Tann From lists at xunil.at Fri May 22 14:31:05 2015 From: lists at xunil.at (Stefan G. Weichinger) Date: Fri, 22 May 2015 14:31:05 +0200 Subject: [Postfixbuch-users] postscreen und MS Office In-Reply-To: <555F15F4.10307@alphasrv.net> References: <555EECBD.2020008@xunil.at> <555F15F4.10307@alphasrv.net> Message-ID: <555F2189.7000205@xunil.at> On 22.05.2015 13:57, Andre Tann wrote: > Das Problem kenn ich. Es gibt im Grunde zwei Möglichkeiten: > > 1. Du hast viel Traffic von /.*outbound\.protection\.outlook\.com/. Dann > erledigt sich das von alleine, weil irgendwann alle gewhitelistet sind. > Bis dahin allerdings werden die User jammern, weil es Verzögerungen von > einem Tag oder mehr geben kann. > > 2. Du whitelistest /.*outbound\.protection\.outlook\.com/ bei postscreen: > > /etc/postfix/main.cf: > postscreen_access_list = ..., pcre:/etc/postfix/postscreen_access.pcre > > /etc/postfix/postscreen_access.pcre: > /.*outbound\.protection\.outlook\.com/ permit > > > => ungetestet aus dem Kopf geschrieben. > > Damit winkst Du alle outbound Server durch. Das sind IIRC 120 Stück oder > so. Wenn man drauf warten will, daß die wirklich alle mal gewhitelistet > sind, dann braucht man schon einiges an Verkehr von dort. Ah, super, danke ... ich hab das mal auf einem meiner Server eingebaut und sehe mir das an. Ist nicht viel Traffic von dort, daher greift auch das Auto-Whitelisting nicht wirklich (entries veralten, bevor wieder was kommt). Aber der eine Absender, um den es geht, will ich eben definitiv schnell in der Inbox haben und nicht verzögern. Danke, Stefan From p at sys4.de Fri May 22 14:53:16 2015 From: p at sys4.de (Patrick Ben Koetter) Date: Fri, 22 May 2015 14:53:16 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <005801d09486$62c328b0$28497a10$@ist-immer-online.de> References: <5556171D.5020000@yahoo.de> <5556243B.6090408@rolandschnabel.de> <555D9E65.40304@yahoo.de> <20150521092942.GE14670@sys4.de> <555DB39F.1070807@yahoo.de> <555E2041.3040701@rolandschnabel.de> <555EC455.7070801@web.de> <001c01d0947f$6b994a70$42cbdf50$@ist-immer-online.de> <20150522112644.GC24854@sys4.de> <005801d09486$62c328b0$28497a10$@ist-immer-online.de> Message-ID: <20150522125315.GA30226@sys4.de> * Daniel : > Hallo Patrick, > > danke für die Antwort, leider klappt es nicht., weiterhin untrustet zum externen Mailrelay. > > Ich habe probiert > smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt Das server-ca.crt weist wen aus? Ist das die CA mit der das Zertifikat des "externen Mailrelay" signiert wurde? > und dann noch > smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt > > Weitere Optionen mit smtp_ in der main.cf sind: > smtp_tls_security_level = may > smtp_tls_loglevel = 1 > smtp_tls_fingerprint_digest = sha1 > smtp_tls_note_starttls_offer = yes > smtp_host_lookup = dns, native > smtp_use_tls = yes Mach mal: openssl s_client -starttls smtp -CAfile /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt -connect $externesMailrelay:25 Und sende den output hier her. p at rick > > Gruß Daniel > > -----Ursprüngliche Nachricht----- > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter > Gesendet: Freitag, 22. Mai 2015 13:27 > An: postfixbuch-users at listen.jpberlin.de > Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > > * Daniel : > > Guten Tag, > > > > ich habe ein ähnliches Anliegen. > > > > Im Maillog steht beim Versenden von Mails z.B.: > > postfix/smtp: Untrusted TLS connection established to mail.x.de[x.x.x.x]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 > > (256/256 bits) > > > > Darauf hin habe ich habe ich mal main.cf geschaut nach dem in den Mail vom Werner bei den genannten Parameter. > > > > Dort habe ich nur gefunden: > > smtpd_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > > smtpd_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > > > > Dieses bezieht sich dann ja wohl nur für eingehende Verbindung, also müsste ich z.B. > > smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > > smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > > > > hinzufügen damit auch für ausgehende Verbindung Zertifikat verwendet wird und das untrustet verschwindet? > > > Nein. Mit Deiner Änderung könnte der Postfix smtp-Client sich einem Server > gegenüber ausweisen, wenn > > - das Zertifikat für Client Usage geeignet ist > - der Server das Client-Zertifikat anfragt > > Du musst smtp_tls_CAfile setzen, damit der Client die Zertifikate anderer > SMTP-Server verifizieren kann, z.B.: > > smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt > > p at rick > > > > > > > Bin noch dabei mich mit ganzen Materie stärker vertraut zumachen. > > > > Gruß Daniel > > > > > > -----Ursprüngliche Nachricht----- > > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Werner Flamme > > Gesendet: Freitag, 22. Mai 2015 07:53 > > An: postfixbuch-users at listen.jpberlin.de > > Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > > > > Roland Schnabel [21.05.2015 20:13]: > > > > > > On 21.05.2015 12:29, Ralf Hansen wrote: > > >> > > >> Aber selbst bei Einrichtung eine Eintrages in /etc/hosts > > >> 10.100.120.251 interner-server.mein-netz.de > > >> > > >> und Nutzung von > > >> relayhost = interner-server.mein-netz.de > > >> > > >> erhalte ich eine Untrusted TLS connection > > >> > > > > > > Postfix ignoriert /etc/hosts per Default: > > > smtp_host_lookup = dns > > > > Trusted oder nicht hat nichts mit DNS zu tun, sondern damit, ob die > > Zertifikatskette anerkannt wird. Das Root-Zertifikat der Kette sollte in > > dem Verzeichnis liegen, das mit smtp_tls_CApath definiert wird (für > > ausgehende Verbindungen; für eingehende ist es smtpd_tls_CApath). > > > > HDH, Werner > > > > -- > > -- > > _______________________________________________ > > Postfixbuch-users -- http://www.postfixbuch.de > > Heinlein Professional Linux Support GmbH > > > > Postfixbuch-users at listen.jpberlin.de > > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users > > > > > > -- > > _______________________________________________ > > Postfixbuch-users -- http://www.postfixbuch.de > > Heinlein Professional Linux Support GmbH > > > > Postfixbuch-users at listen.jpberlin.de > > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users > > -- > [*] sys4 AG > > https://sys4.de, +49 (89) 30 90 46 64 > Franziskanerstraße 15, 81669 München > > Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 > Vorstand: Patrick Ben Koetter, Marc Schiffbauer > Aufsichtsratsvorsitzender: Florian Kirstein > > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users > > > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From andreas.schulze at datev.de Fri May 22 15:15:22 2015 From: andreas.schulze at datev.de (Schulze, Andreas) Date: Fri, 22 May 2015 15:15:22 +0200 Subject: [Postfixbuch-users] postscreen und MS Office In-Reply-To: <555F15F4.10307@alphasrv.net> References: <555EECBD.2020008@xunil.at> <555F15F4.10307@alphasrv.net> Message-ID: <20150522151522.Horde.gYfoqaddoIKVx8YF-pzATDh@idvwebmail02.services.datev.de> Andre Tann: > /etc/postfix/postscreen_access.pcre: > /.*outbound\.protection\.outlook\.com/ permit sieht schön aus aber ich bin mir nicht sicher ob das klappt. http://www.postfix.org/postconf.5.html#postscreen_access_list liest sich so, dass da nur IP-Adressen verarbeitet werden. kann das mal jemand testen? Andreas -- DATEV eG 90329 Nürnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196 E-Mail info at datev.de | Internet www.datev.de Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg Nr.70 Vorstand Prof. Dieter Kempf (Vorsitzender) Dr. Robert Mayr (stellv. Vorsitzender) Eckhard Schwarzer (stellv. Vorsitzender) Dr. Peter Krug Jörg Rabe von Pappenheim Vorsitzender des Aufsichtsrates: Dirk Schmale From Ralf.Hildebrandt at charite.de Fri May 22 15:20:58 2015 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Fri, 22 May 2015 15:20:58 +0200 Subject: [Postfixbuch-users] postscreen und MS Office In-Reply-To: <20150522151522.Horde.gYfoqaddoIKVx8YF-pzATDh@idvwebmail02.services.datev.de> References: <555EECBD.2020008@xunil.at> <555F15F4.10307@alphasrv.net> <20150522151522.Horde.gYfoqaddoIKVx8YF-pzATDh@idvwebmail02.services.datev.de> Message-ID: <20150522132058.GM8953@charite.de> * Schulze, Andreas : > > Andre Tann: > > >/etc/postfix/postscreen_access.pcre: > > /.*outbound\.protection\.outlook\.com/ permit > > sieht schön aus aber ich bin mir nicht sicher ob das klappt. > > http://www.postfix.org/postconf.5.html#postscreen_access_list > liest sich so, dass da nur IP-Adressen verarbeitet werden. > > kann das mal jemand testen? Ja, nur IPs -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt at charite.de | http://www.charite.de From daniel at ist-immer-online.de Fri May 22 16:18:57 2015 From: daniel at ist-immer-online.de (Daniel) Date: Fri, 22 May 2015 16:18:57 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <20150522125315.GA30226@sys4.de> References: <5556171D.5020000@yahoo.de> <5556243B.6090408@rolandschnabel.de> <555D9E65.40304@yahoo.de> <20150521092942.GE14670@sys4.de> <555DB39F.1070807@yahoo.de> <555E2041.3040701@rolandschnabel.de> <555EC455.7070801@web.de> <001c01d0947f$6b994a70$42cbdf50$@ist-immer-online.de> <20150522112644.GC24854@sys4.de> <005801d09486$62c328b0$28497a10$@ist-immer-online.de> <20150522125315.GA30226@sys4.de> Message-ID: <000601d0949a$3e2f5c30$ba8e1490$@ist-immer-online.de> Hi Patrick, denke der Fehler ist so schon korrekt mit untrustet, und mein Denkfehler war wohl in der schnelle, dass ich mein eigenes Zertifikat angeben muss, und nicht mit dem vom Zielserver (Mailrelay) also lasse ich es wie es war. Würde der Mailserver direkt versenden, müsste ich wohl Path angeben, und für sämtliche Servern wie Telekom, Google, 1&1, GMX und co entsprechend dann hinterlegen in dem Ordner, oder? Gruß Daniel -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter Gesendet: Freitag, 22. Mai 2015 14:53 An: postfixbuch-users at listen.jpberlin.de Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES * Daniel : > Hallo Patrick, > > danke für die Antwort, leider klappt es nicht., weiterhin untrustet zum externen Mailrelay. > > Ich habe probiert > smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt Das server-ca.crt weist wen aus? Ist das die CA mit der das Zertifikat des "externen Mailrelay" signiert wurde? > und dann noch > smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt > > Weitere Optionen mit smtp_ in der main.cf sind: > smtp_tls_security_level = may > smtp_tls_loglevel = 1 > smtp_tls_fingerprint_digest = sha1 > smtp_tls_note_starttls_offer = yes > smtp_host_lookup = dns, native > smtp_use_tls = yes Mach mal: openssl s_client -starttls smtp -CAfile /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt -connect $externesMailrelay:25 Und sende den output hier her. p at rick > > Gruß Daniel > > -----Ursprüngliche Nachricht----- > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter > Gesendet: Freitag, 22. Mai 2015 13:27 > An: postfixbuch-users at listen.jpberlin.de > Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > > * Daniel : > > Guten Tag, > > > > ich habe ein ähnliches Anliegen. > > > > Im Maillog steht beim Versenden von Mails z.B.: > > postfix/smtp: Untrusted TLS connection established to mail.x.de[x.x.x.x]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 > > (256/256 bits) > > > > Darauf hin habe ich habe ich mal main.cf geschaut nach dem in den Mail vom Werner bei den genannten Parameter. > > > > Dort habe ich nur gefunden: > > smtpd_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > > smtpd_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > > > > Dieses bezieht sich dann ja wohl nur für eingehende Verbindung, also müsste ich z.B. > > smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > > smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > > > > hinzufügen damit auch für ausgehende Verbindung Zertifikat verwendet wird und das untrustet verschwindet? > > > Nein. Mit Deiner Änderung könnte der Postfix smtp-Client sich einem Server > gegenüber ausweisen, wenn > > - das Zertifikat für Client Usage geeignet ist > - der Server das Client-Zertifikat anfragt > > Du musst smtp_tls_CAfile setzen, damit der Client die Zertifikate anderer > SMTP-Server verifizieren kann, z.B.: > > smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt > > p at rick > > > > > > > Bin noch dabei mich mit ganzen Materie stärker vertraut zumachen. > > > > Gruß Daniel > > > > > > -----Ursprüngliche Nachricht----- > > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Werner Flamme > > Gesendet: Freitag, 22. Mai 2015 07:53 > > An: postfixbuch-users at listen.jpberlin.de > > Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > > > > Roland Schnabel [21.05.2015 20:13]: > > > > > > On 21.05.2015 12:29, Ralf Hansen wrote: > > >> > > >> Aber selbst bei Einrichtung eine Eintrages in /etc/hosts > > >> 10.100.120.251 interner-server.mein-netz.de > > >> > > >> und Nutzung von > > >> relayhost = interner-server.mein-netz.de > > >> > > >> erhalte ich eine Untrusted TLS connection… > > >> > > > > > > Postfix ignoriert /etc/hosts per Default: > > > smtp_host_lookup = dns > > > > Trusted oder nicht hat nichts mit DNS zu tun, sondern damit, ob die > > Zertifikatskette anerkannt wird. Das Root-Zertifikat der Kette sollte in > > dem Verzeichnis liegen, das mit smtp_tls_CApath definiert wird (für > > ausgehende Verbindungen; für eingehende ist es smtpd_tls_CApath). > > > > HDH, Werner From atann at alphasrv.net Fri May 22 17:17:47 2015 From: atann at alphasrv.net (Andre Tann) Date: Fri, 22 May 2015 17:17:47 +0200 Subject: [Postfixbuch-users] postscreen und MS Office In-Reply-To: <20150522151522.Horde.gYfoqaddoIKVx8YF-pzATDh@idvwebmail02.services.datev.de> References: <555EECBD.2020008@xunil.at> <555F15F4.10307@alphasrv.net> <20150522151522.Horde.gYfoqaddoIKVx8YF-pzATDh@idvwebmail02.services.datev.de> Message-ID: <555F4504.9060104@alphasrv.net> Moin, Am 22.05.2015 um 15:15 schrieb Schulze, Andreas: > sieht schön aus aber ich bin mir nicht sicher ob das klappt. > > http://www.postfix.org/postconf.5.html#postscreen_access_list > liest sich so, dass da nur IP-Adressen verarbeitet werden. Man soll eben doch nicht aus dem Kopf hinschreiben :( Hab das wohl mit postgrey verwechselt. Dann wird man wohl das hier nutzen müssen: https://mail.live.com/mail/ipspace.aspx Bei mir whitelisten sich die Dinger erfreulicherweise selbst. Aber am Anfang haben die User schon gut gejammert. Und die Verzögerung postscreen => postgrey ist echt nicht unerheblich. -- Andre Tann From p at sys4.de Fri May 22 18:01:08 2015 From: p at sys4.de (Patrick Ben Koetter) Date: Fri, 22 May 2015 18:01:08 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <000601d0949a$3e2f5c30$ba8e1490$@ist-immer-online.de> References: <555D9E65.40304@yahoo.de> <20150521092942.GE14670@sys4.de> <555DB39F.1070807@yahoo.de> <555E2041.3040701@rolandschnabel.de> <555EC455.7070801@web.de> <001c01d0947f$6b994a70$42cbdf50$@ist-immer-online.de> <20150522112644.GC24854@sys4.de> <005801d09486$62c328b0$28497a10$@ist-immer-online.de> <20150522125315.GA30226@sys4.de> <000601d0949a$3e2f5c30$ba8e1490$@ist-immer-online.de> Message-ID: <20150522160108.GA9710@sys4.de> * Daniel : > Hi Patrick, > > denke der Fehler ist so schon korrekt mit untrustet, und mein Denkfehler war wohl in der schnelle, dass ich mein eigenes Zertifikat > angeben muss, und nicht mit dem vom Zielserver (Mailrelay) > > also lasse ich es wie es war. Würde der Mailserver direkt versenden, müsste ich wohl Path angeben, und für sämtliche Servern wie > Telekom, Google, 1&1, GMX und co entsprechend dann hinterlegen in dem Ordner, oder? Genau. Wenn Du willst, dann kannst Du über smtp_tls_policy_maps das Zertifikat Deines Relayserver pinnen (fingerprint). Dann gilt er als Verified. p at rick > > Gruß Daniel > > -----Ursprüngliche Nachricht----- > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter > Gesendet: Freitag, 22. Mai 2015 14:53 > An: postfixbuch-users at listen.jpberlin.de > Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > > * Daniel : > > Hallo Patrick, > > > > danke für die Antwort, leider klappt es nicht., weiterhin untrustet zum externen Mailrelay. > > > > Ich habe probiert > > smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt > > Das server-ca.crt weist wen aus? Ist das die CA mit der das Zertifikat des > "externen Mailrelay" signiert wurde? > > > und dann noch > > smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > > smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > > smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt > > > > Weitere Optionen mit smtp_ in der main.cf sind: > > smtp_tls_security_level = may > > smtp_tls_loglevel = 1 > > smtp_tls_fingerprint_digest = sha1 > > smtp_tls_note_starttls_offer = yes > > smtp_host_lookup = dns, native > > smtp_use_tls = yes > > Mach mal: > > openssl s_client -starttls smtp -CAfile /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt -connect $externesMailrelay:25 > > Und sende den output hier her. > > p at rick > > > > > > > > Gruß Daniel > > > > -----Ursprüngliche Nachricht----- > > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter > > Gesendet: Freitag, 22. Mai 2015 13:27 > > An: postfixbuch-users at listen.jpberlin.de > > Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > > > > * Daniel : > > > Guten Tag, > > > > > > ich habe ein ähnliches Anliegen. > > > > > > Im Maillog steht beim Versenden von Mails z.B.: > > > postfix/smtp: Untrusted TLS connection established to mail.x.de[x.x.x.x]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 > > > (256/256 bits) > > > > > > Darauf hin habe ich habe ich mal main.cf geschaut nach dem in den Mail vom Werner bei den genannten Parameter. > > > > > > Dort habe ich nur gefunden: > > > smtpd_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > > > smtpd_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > > > > > > Dieses bezieht sich dann ja wohl nur für eingehende Verbindung, also müsste ich z.B. > > > smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > > > smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > > > > > > hinzufügen damit auch für ausgehende Verbindung Zertifikat verwendet wird und das untrustet verschwindet? > > > > > > Nein. Mit Deiner Änderung könnte der Postfix smtp-Client sich einem Server > > gegenüber ausweisen, wenn > > > > - das Zertifikat für Client Usage geeignet ist > > - der Server das Client-Zertifikat anfragt > > > > Du musst smtp_tls_CAfile setzen, damit der Client die Zertifikate anderer > > SMTP-Server verifizieren kann, z.B.: > > > > smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt > > > > p at rick > > > > > > > > > > > > Bin noch dabei mich mit ganzen Materie stärker vertraut zumachen. > > > > > > Gruß Daniel > > > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Werner Flamme > > > Gesendet: Freitag, 22. Mai 2015 07:53 > > > An: postfixbuch-users at listen.jpberlin.de > > > Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > > > > > > Roland Schnabel [21.05.2015 20:13]: > > > > > > > > On 21.05.2015 12:29, Ralf Hansen wrote: > > > >> > > > >> Aber selbst bei Einrichtung eine Eintrages in /etc/hosts > > > >> 10.100.120.251 interner-server.mein-netz.de > > > >> > > > >> und Nutzung von > > > >> relayhost = interner-server.mein-netz.de > > > >> > > > >> erhalte ich eine Untrusted TLS connection > > > >> > > > > > > > > Postfix ignoriert /etc/hosts per Default: > > > > smtp_host_lookup = dns > > > > > > Trusted oder nicht hat nichts mit DNS zu tun, sondern damit, ob die > > > Zertifikatskette anerkannt wird. Das Root-Zertifikat der Kette sollte in > > > dem Verzeichnis liegen, das mit smtp_tls_CApath definiert wird (für > > > ausgehende Verbindungen; für eingehende ist es smtpd_tls_CApath). > > > > > > HDH, Werner > > > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From daniel at ist-immer-online.de Fri May 22 18:43:05 2015 From: daniel at ist-immer-online.de (Daniel) Date: Fri, 22 May 2015 18:43:05 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <20150522160108.GA9710@sys4.de> References: <555D9E65.40304@yahoo.de> <20150521092942.GE14670@sys4.de> <555DB39F.1070807@yahoo.de> <555E2041.3040701@rolandschnabel.de> <555EC455.7070801@web.de> <001c01d0947f$6b994a70$42cbdf50$@ist-immer-online.de> <20150522112644.GC24854@sys4.de> <005801d09486$62c328b0$28497a10$@ist-immer-online.de> <20150522125315.GA30226@sys4.de> <000601d0949a$3e2f5c30$ba8e1490$@ist-immer-online.de> <20150522160108.GA9710@sys4.de> Message-ID: <000d01d094ae$60387f00$20a97d00$@ist-immer-online.de> Hi Patrick, danke, hat geklappt im Test mit nem Synology Server und posteo als Mailrelay. Konkret in /volume1/@appstore/MailServer/etc/template/main.template smtp_tls_security_level = may ersetzt durch smtp_tls_security_level = fingerprint smtp_tls_fingerprint_cert_match = 3A:89:D8:AD:DC:A7:23:5C:8F:44:E9:DD:2E:85:6A:31:D2:D3:C9:70 Fingerprints kann man sich auch z.B. https://de.ssl-tools.net/mailservers/posteo.de hier entnehmen. Rest wie smtp_tls_fingerprint_digest = sha1 passte schon im Template. Wenn man mit Path arbeitet, kann man den postfix sagen, soll die Certs selbst dort sammeln und speichern, oder müsste ich mir für sätmliche große Server wenn dann Cert dort einfügen bzw. die fingerprints? Gruß Daniel -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter Gesendet: Freitag, 22. Mai 2015 18:01 An: postfixbuch-users at listen.jpberlin.de Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES * Daniel : > Hi Patrick, > > denke der Fehler ist so schon korrekt mit untrustet, und mein Denkfehler war wohl in der schnelle, dass ich mein eigenes Zertifikat > angeben muss, und nicht mit dem vom Zielserver (Mailrelay) > > also lasse ich es wie es war. Würde der Mailserver direkt versenden, müsste ich wohl Path angeben, und für sämtliche Servern wie > Telekom, Google, 1&1, GMX und co entsprechend dann hinterlegen in dem Ordner, oder? Genau. Wenn Du willst, dann kannst Du über smtp_tls_policy_maps das Zertifikat Deines Relayserver pinnen (fingerprint). Dann gilt er als Verified. p at rick > > Gruß Daniel > > -----Ursprüngliche Nachricht----- > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter > Gesendet: Freitag, 22. Mai 2015 14:53 > An: postfixbuch-users at listen.jpberlin.de > Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > > * Daniel : > > Hallo Patrick, > > > > danke für die Antwort, leider klappt es nicht., weiterhin untrustet zum externen Mailrelay. > > > > Ich habe probiert > > smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt > > Das server-ca.crt weist wen aus? Ist das die CA mit der das Zertifikat des > "externen Mailrelay" signiert wurde? > > > und dann noch > > smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > > smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > > smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt > > > > Weitere Optionen mit smtp_ in der main.cf sind: > > smtp_tls_security_level = may > > smtp_tls_loglevel = 1 > > smtp_tls_fingerprint_digest = sha1 > > smtp_tls_note_starttls_offer = yes > > smtp_host_lookup = dns, native > > smtp_use_tls = yes > > Mach mal: > > openssl s_client -starttls smtp -CAfile /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt -connect $externesMailrelay:25 > > Und sende den output hier her. > > p at rick > > > > > > > > Gruß Daniel > > > > -----Ursprüngliche Nachricht----- > > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter > > Gesendet: Freitag, 22. Mai 2015 13:27 > > An: postfixbuch-users at listen.jpberlin.de > > Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > > > > * Daniel : > > > Guten Tag, > > > > > > ich habe ein ähnliches Anliegen. > > > > > > Im Maillog steht beim Versenden von Mails z.B.: > > > postfix/smtp: Untrusted TLS connection established to mail.x.de[x.x.x.x]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 > > > (256/256 bits) > > > > > > Darauf hin habe ich habe ich mal main.cf geschaut nach dem in den Mail vom Werner bei den genannten Parameter. > > > > > > Dort habe ich nur gefunden: > > > smtpd_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > > > smtpd_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > > > > > > Dieses bezieht sich dann ja wohl nur für eingehende Verbindung, also müsste ich z.B. > > > smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > > > smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > > > > > > hinzufügen damit auch für ausgehende Verbindung Zertifikat verwendet wird und das untrustet verschwindet? > > > > > > Nein. Mit Deiner Änderung könnte der Postfix smtp-Client sich einem Server > > gegenüber ausweisen, wenn > > > > - das Zertifikat für Client Usage geeignet ist > > - der Server das Client-Zertifikat anfragt > > > > Du musst smtp_tls_CAfile setzen, damit der Client die Zertifikate anderer > > SMTP-Server verifizieren kann, z.B.: > > > > smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt > > > > p at rick > > > > > > > > > > > > Bin noch dabei mich mit ganzen Materie stärker vertraut zumachen. > > > > > > Gruß Daniel > > > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Werner Flamme > > > Gesendet: Freitag, 22. Mai 2015 07:53 > > > An: postfixbuch-users at listen.jpberlin.de > > > Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > > > > > > Roland Schnabel [21.05.2015 20:13]: > > > > > > > > On 21.05.2015 12:29, Ralf Hansen wrote: > > > >> > > > >> Aber selbst bei Einrichtung eine Eintrages in /etc/hosts > > > >> 10.100.120.251 interner-server.mein-netz.de > > > >> > > > >> und Nutzung von > > > >> relayhost = interner-server.mein-netz.de > > > >> > > > >> erhalte ich eine Untrusted TLS connection… > > > >> > > > > > > > > Postfix ignoriert /etc/hosts per Default: > > > > smtp_host_lookup = dns > > > > > > Trusted oder nicht hat nichts mit DNS zu tun, sondern damit, ob die > > > Zertifikatskette anerkannt wird. Das Root-Zertifikat der Kette sollte in > > > dem Verzeichnis liegen, das mit smtp_tls_CApath definiert wird (für > > > ausgehende Verbindungen; für eingehende ist es smtpd_tls_CApath). > > > > > > HDH, Werner > > > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein -- _______________________________________________ Postfixbuch-users -- http://www.postfixbuch.de Heinlein Professional Linux Support GmbH Postfixbuch-users at listen.jpberlin.de https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users From lists at xunil.at Fri May 22 19:34:14 2015 From: lists at xunil.at (Stefan G. Weichinger) Date: Fri, 22 May 2015 19:34:14 +0200 Subject: [Postfixbuch-users] postscreen und MS Office In-Reply-To: <555F4504.9060104@alphasrv.net> References: <555EECBD.2020008@xunil.at> <555F15F4.10307@alphasrv.net> <20150522151522.Horde.gYfoqaddoIKVx8YF-pzATDh@idvwebmail02.services.datev.de> <555F4504.9060104@alphasrv.net> Message-ID: <555F6896.8010709@xunil.at> Am 2015-05-22 um 17:17 schrieb Andre Tann: > Dann wird man wohl das hier nutzen müssen: > > https://mail.live.com/mail/ipspace.aspx > > Bei mir whitelisten sich die Dinger erfreulicherweise selbst. Aber am > Anfang haben die User schon gut gejammert. Und die Verzögerung > postscreen => postgrey ist echt nicht unerheblich. ich sehe hier immer mehrere Stunden Delay. Aber ich will nicht auf postscreen verzichten, nur weil ein Kollege per microsoft sendet ... (das sind seltene, aber dann wichtige Infos ... die ich flott sehen will) Ergo werde ich jetzt obige Liste einbauen, auch wenn es mir widerstrebt ;) danke, Stefan From lists at xunil.at Fri May 22 19:39:02 2015 From: lists at xunil.at (Stefan G. Weichinger) Date: Fri, 22 May 2015 19:39:02 +0200 Subject: [Postfixbuch-users] postscreen und MS Office In-Reply-To: <555F4504.9060104@alphasrv.net> References: <555EECBD.2020008@xunil.at> <555F15F4.10307@alphasrv.net> <20150522151522.Horde.gYfoqaddoIKVx8YF-pzATDh@idvwebmail02.services.datev.de> <555F4504.9060104@alphasrv.net> Message-ID: <555F69B6.2080707@xunil.at> Am 2015-05-22 um 17:17 schrieb Andre Tann: > Dann wird man wohl das hier nutzen müssen: > > https://mail.live.com/mail/ipspace.aspx Zusatz: ich hatte gestern Einträge von einer IP, die in der genannten Liste *nicht* drin ist ... und was ist mit denen, die per IPv6 daher kommen? Das ist ein wenig mühsam. From p at sys4.de Fri May 22 21:32:37 2015 From: p at sys4.de (Patrick Ben Koetter) Date: Fri, 22 May 2015 21:32:37 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <000d01d094ae$60387f00$20a97d00$@ist-immer-online.de> References: <555DB39F.1070807@yahoo.de> <555E2041.3040701@rolandschnabel.de> <555EC455.7070801@web.de> <001c01d0947f$6b994a70$42cbdf50$@ist-immer-online.de> <20150522112644.GC24854@sys4.de> <005801d09486$62c328b0$28497a10$@ist-immer-online.de> <20150522125315.GA30226@sys4.de> <000601d0949a$3e2f5c30$ba8e1490$@ist-immer-online.de> <20150522160108.GA9710@sys4.de> <000d01d094ae$60387f00$20a97d00$@ist-immer-online.de> Message-ID: <20150522193237.GB14875@sys4.de> * Daniel : > Hi Patrick, > > danke, hat geklappt im Test mit nem Synology Server und posteo als Mailrelay. > > Konkret in /volume1/@appstore/MailServer/etc/template/main.template > smtp_tls_security_level = may > > ersetzt durch > smtp_tls_security_level = fingerprint > smtp_tls_fingerprint_cert_match = 3A:89:D8:AD:DC:A7:23:5C:8F:44:E9:DD:2E:85:6A:31:D2:D3:C9:70 > > Fingerprints kann man sich auch z.B. https://de.ssl-tools.net/mailservers/posteo.de hier entnehmen. > > Rest wie smtp_tls_fingerprint_digest = sha1 passte schon im Template. > > Wenn man mit Path arbeitet, kann man den postfix sagen, soll die Certs selbst dort sammeln und speichern, oder müsste ich mir für > sätmliche große Server wenn dann Cert dort einfügen bzw. die fingerprints? Bei Trust willst Du Postfix nicht selber sammeln lassen. Wie sollte er denn herausfinden, ob er dem was er gefunden hat, trusten soll? Das geht mit DANE TLS, aber nicht mit statischen Cert Stores im Filesystem wie z.b. einer Datei auf die Du mit CApath verweist. Wenn Du sämtliche Server verifzieren willst, dann musst Du das entweder von Hand machen oder DANE einsetzen. Das geht dann automatisch - vorausgesetzt das Ziel bietet DNSSEC und TLSA RRs an. Deine Beispieldomain posteo.de unterstützt DANE, wie Du dem DANE Validator entnehmen kannst: https://dane.sys4.de/smtp/posteo.de p at rick > > Gruß Daniel > -----Ursprüngliche Nachricht----- > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter > Gesendet: Freitag, 22. Mai 2015 18:01 > An: postfixbuch-users at listen.jpberlin.de > Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > > * Daniel : > > Hi Patrick, > > > > denke der Fehler ist so schon korrekt mit untrustet, und mein Denkfehler war wohl in der schnelle, dass ich mein eigenes > Zertifikat > > angeben muss, und nicht mit dem vom Zielserver (Mailrelay) > > > > also lasse ich es wie es war. Würde der Mailserver direkt versenden, müsste ich wohl Path angeben, und für sämtliche Servern wie > > Telekom, Google, 1&1, GMX und co entsprechend dann hinterlegen in dem Ordner, oder? > > Genau. > > Wenn Du willst, dann kannst Du über smtp_tls_policy_maps das Zertifikat Deines > Relayserver pinnen (fingerprint). Dann gilt er als Verified. > > p at rick > > > > > > > Gruß Daniel > > > > -----Ursprüngliche Nachricht----- > > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter > > Gesendet: Freitag, 22. Mai 2015 14:53 > > An: postfixbuch-users at listen.jpberlin.de > > Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > > > > * Daniel : > > > Hallo Patrick, > > > > > > danke für die Antwort, leider klappt es nicht., weiterhin untrustet zum externen Mailrelay. > > > > > > Ich habe probiert > > > smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt > > > > Das server-ca.crt weist wen aus? Ist das die CA mit der das Zertifikat des > > "externen Mailrelay" signiert wurde? > > > > > und dann noch > > > smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > > > smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > > > smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt > > > > > > Weitere Optionen mit smtp_ in der main.cf sind: > > > smtp_tls_security_level = may > > > smtp_tls_loglevel = 1 > > > smtp_tls_fingerprint_digest = sha1 > > > smtp_tls_note_starttls_offer = yes > > > smtp_host_lookup = dns, native > > > smtp_use_tls = yes > > > > Mach mal: > > > > openssl s_client -starttls smtp -CAfile /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt -connect $externesMailrelay:25 > > > > Und sende den output hier her. > > > > p at rick > > > > > > > > > > > > > > Gruß Daniel > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter > > > Gesendet: Freitag, 22. Mai 2015 13:27 > > > An: postfixbuch-users at listen.jpberlin.de > > > Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > > > > > > * Daniel : > > > > Guten Tag, > > > > > > > > ich habe ein ähnliches Anliegen. > > > > > > > > Im Maillog steht beim Versenden von Mails z.B.: > > > > postfix/smtp: Untrusted TLS connection established to mail.x.de[x.x.x.x]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 > > > > (256/256 bits) > > > > > > > > Darauf hin habe ich habe ich mal main.cf geschaut nach dem in den Mail vom Werner bei den genannten Parameter. > > > > > > > > Dort habe ich nur gefunden: > > > > smtpd_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > > > > smtpd_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > > > > > > > > Dieses bezieht sich dann ja wohl nur für eingehende Verbindung, also müsste ich z.B. > > > > smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > > > > smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > > > > > > > > hinzufügen damit auch für ausgehende Verbindung Zertifikat verwendet wird und das untrustet verschwindet? > > > > > > > > > Nein. Mit Deiner Änderung könnte der Postfix smtp-Client sich einem Server > > > gegenüber ausweisen, wenn > > > > > > - das Zertifikat für Client Usage geeignet ist > > > - der Server das Client-Zertifikat anfragt > > > > > > Du musst smtp_tls_CAfile setzen, damit der Client die Zertifikate anderer > > > SMTP-Server verifizieren kann, z.B.: > > > > > > smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt > > > > > > p at rick > > > > > > > > > > > > > > > > > Bin noch dabei mich mit ganzen Materie stärker vertraut zumachen. > > > > > > > > Gruß Daniel > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Werner Flamme > > > > Gesendet: Freitag, 22. Mai 2015 07:53 > > > > An: postfixbuch-users at listen.jpberlin.de > > > > Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > > > > > > > > Roland Schnabel [21.05.2015 20:13]: > > > > > > > > > > On 21.05.2015 12:29, Ralf Hansen wrote: > > > > >> > > > > >> Aber selbst bei Einrichtung eine Eintrages in /etc/hosts > > > > >> 10.100.120.251 interner-server.mein-netz.de > > > > >> > > > > >> und Nutzung von > > > > >> relayhost = interner-server.mein-netz.de > > > > >> > > > > >> erhalte ich eine Untrusted TLS connection > > > > >> > > > > > > > > > > Postfix ignoriert /etc/hosts per Default: > > > > > smtp_host_lookup = dns > > > > > > > > Trusted oder nicht hat nichts mit DNS zu tun, sondern damit, ob die > > > > Zertifikatskette anerkannt wird. Das Root-Zertifikat der Kette sollte in > > > > dem Verzeichnis liegen, das mit smtp_tls_CApath definiert wird (für > > > > ausgehende Verbindungen; für eingehende ist es smtpd_tls_CApath). > > > > > > > > HDH, Werner > > > > > > -- > > _______________________________________________ > > Postfixbuch-users -- http://www.postfixbuch.de > > Heinlein Professional Linux Support GmbH > > > > Postfixbuch-users at listen.jpberlin.de > > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users > > -- > [*] sys4 AG > > https://sys4.de, +49 (89) 30 90 46 64 > Franziskanerstraße 15, 81669 München > > Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 > Vorstand: Patrick Ben Koetter, Marc Schiffbauer > Aufsichtsratsvorsitzender: Florian Kirstein > > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users > > > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From driessen at fblan.de Fri May 22 21:48:40 2015 From: driessen at fblan.de (=?iso-8859-1?Q?Uwe_Drie=DFen?=) Date: Fri, 22 May 2015 21:48:40 +0200 Subject: [Postfixbuch-users] postscreen und MS Office In-Reply-To: <555F2189.7000205@xunil.at> References: <555EECBD.2020008@xunil.at> <555F15F4.10307@alphasrv.net> <555F2189.7000205@xunil.at> Message-ID: <000a01d094c8$4ddca420$e995ec60$@fblan.de> Im Auftrag von Stefan G. Weichinger > Ist nicht viel Traffic von dort, daher greift auch das Auto-Whitelisting > nicht wirklich (entries veralten, bevor wieder was kommt). > > Aber der eine Absender, um den es geht, will ich eben definitiv schnell > in der Inbox haben und nicht verzögern. > Dann schieb ihn um alle Tests drum herum wenn er dir so wichtig ist. Ich habe diese Diskussion auch gerade mit einem "Welt-Unternehmen" die alle Ihre Mails seit etwa Februar nur noch über MS abwickeln. Die bekommen immer mal wieder den 4XX Fehler zu sehen und regen sich drüber auf :-)) Der Empfänger gab grünes Licht das da eh nur unwichtiges Zeug kommt das er nicht sehen möchte :-)) Was ich bis jetzt gesehen habe ist das die Mails versucht werden zuzustellen und bei einem 4XX Fehler an die Nächste Maschine weitergeleitet werden. Die nächste Zustellung erfolgt dann allerdings nicht nach 10 min sondern Stunden später. Bei 120 Servern die nur alle paar Stunden versuchen die Mail loszuwerden da kommen wir dann irgendwann auch mal auf 1200 Stunden. Ich kann nichts dafür das MS das künstlich solange verzögert. Ein Schelm wer Böses dabei denkt. Nach 4 Wochen hatte weder der Absender eine Fehlermeldung noch war die Mail beim Empfänger angekommen.(das finde ich viel bedenklicher) Bevor einer da auf falsche Gedanken kommt nein die Mail war uns niemals versucht worden zuzustellen. Zusätzlich : Auf Zertifikate welche nicht auf der richtigen IP / Domain liegen reagiert MS (als einziger) mit dem Abbruch der Verbindung. Sie hätten gerne ein Whitelisting. Ich hab das abgelehnt weil feindliche Server werden niemals white gelistet.(und mit MS Betriebssystem schon gar nicht) Und ob die Mails von denen nun heute oder morgen oder überübermorgen ankommen kann mein Kunde gut mit leben. Mit freundlichen Grüßen Uwe Drießen -- Software & Computer Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: 06708660045 From driessen at fblan.de Fri May 22 21:53:25 2015 From: driessen at fblan.de (=?iso-8859-1?Q?Uwe_Drie=DFen?=) Date: Fri, 22 May 2015 21:53:25 +0200 Subject: [Postfixbuch-users] postscreen und MS Office In-Reply-To: <555F69B6.2080707@xunil.at> References: <555EECBD.2020008@xunil.at> <555F15F4.10307@alphasrv.net> <20150522151522.Horde.gYfoqaddoIKVx8YF-pzATDh@idvwebmail02.services.datev.de> <555F4504.9060104@alphasrv.net> <555F69B6.2080707@xunil.at> Message-ID: <000b01d094c8$f73a2f60$e5ae8e20$@fblan.de> Im Auftrag von Stefan G. Weichinger > > Am 2015-05-22 um 17:17 schrieb Andre Tann: > > > Dann wird man wohl das hier nutzen müssen: > > > > https://mail.live.com/mail/ipspace.aspx > > Zusatz: ich hatte gestern Einträge von einer IP, die in der genannten > Liste *nicht* drin ist ... > > und was ist mit denen, die per IPv6 daher kommen? > > Das ist ein wenig mühsam. > Deswegen lasse ich das, das ist ein Hausgemachtes Problem von Microsoft, müssen die anders organisieren. Aber wie immer für den richtigen Preis bin ich durchaus käuflich :-))) Sag deinem Kumpel er soll ein anständiges Mailkonto bei einem zuverlässigen Provider einrichten dann geht das auch mit der Kommunikation Mit freundlichen Grüßen Uwe Drießen -- Software & Computer Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: 06708660045 From cs.mlists+postfix at mailbox.org Fri May 22 22:06:17 2015 From: cs.mlists+postfix at mailbox.org (Clemens =?utf-8?Q?Sch=C3=BCller?=) Date: Fri, 22 May 2015 22:06:17 +0200 Subject: [Postfixbuch-users] postscreen und MS Office In-Reply-To: <000b01d094c8$f73a2f60$e5ae8e20$@fblan.de> ("Uwe \=\?utf-8\?Q\?Dr\?\= \=\?utf-8\?Q\?ie\=C3\=9Fen\=22's\?\= message of "Fri, 22 May 2015 21:53:25 +0200") References: <555EECBD.2020008@xunil.at> <555F15F4.10307@alphasrv.net> <20150522151522.Horde.gYfoqaddoIKVx8YF-pzATDh@idvwebmail02.services.datev.de> <555F4504.9060104@alphasrv.net> <555F69B6.2080707@xunil.at> <000b01d094c8$f73a2f60$e5ae8e20$@fblan.de> Message-ID: <878ucgbcna.fsf@cougar.home.aneadesign.com> Servus! Am 22. Mai. 2015 um 21:53 schrieb Uwe Drießen: > > Deswegen lasse ich das, das ist ein Hausgemachtes Problem von Microsoft, > müssen die anders organisieren. > Aber wie immer für den richtigen Preis bin ich durchaus käuflich :-))) > > Sag deinem Kumpel er soll ein anständiges Mailkonto bei einem zuverlässigen > Provider einrichten dann geht das auch mit der Kommunikation Erinnert mich gerade an meine Probleme mit bsmtp.bon.at - ist der Business Mailserver von der Telekom Austria. Die schaffen es einfach nicht, das helo in Verbindung mit verschiedenen Subnets korrekt zu konfigurieren. Mir werden immer wieder Mails von meinem Arbeitgeber gesendet. Immer wieder kommt es vor, dass die Mails bei mir nicht ankommen und der Chef eine Meldung zurückbekommt, dass die Mail an mich nicht zugestellt werden kann. Manchmal gehts, manchmal nicht - da steckt ein Loadbalancer dahinter. -- Beste Grüße, Clemens Schüller From lists at xunil.at Sun May 24 18:23:37 2015 From: lists at xunil.at (Stefan G. Weichinger) Date: Sun, 24 May 2015 18:23:37 +0200 Subject: [Postfixbuch-users] postscreen und MS Office In-Reply-To: <000b01d094c8$f73a2f60$e5ae8e20$@fblan.de> References: <555EECBD.2020008@xunil.at> <555F15F4.10307@alphasrv.net> <20150522151522.Horde.gYfoqaddoIKVx8YF-pzATDh@idvwebmail02.services.datev.de> <555F4504.9060104@alphasrv.net> <555F69B6.2080707@xunil.at> <000b01d094c8$f73a2f60$e5ae8e20$@fblan.de> Message-ID: <5561FB09.6080705@xunil.at> Am 2015-05-22 um 21:53 schrieb Uwe Drießen: > Deswegen lasse ich das, das ist ein Hausgemachtes Problem von Microsoft, > müssen die anders organisieren. > Aber wie immer für den richtigen Preis bin ich durchaus käuflich :-))) > > Sag deinem Kumpel er soll ein anständiges Mailkonto bei einem zuverlässigen > Provider einrichten dann geht das auch mit der Kommunikation Danke für Einschätzung und Stellungnahme ;) Mal sehen, was er dazu sagt. From lists at xunil.at Sun May 24 18:25:00 2015 From: lists at xunil.at (Stefan G. Weichinger) Date: Sun, 24 May 2015 18:25:00 +0200 Subject: [Postfixbuch-users] postscreen und MS Office In-Reply-To: <878ucgbcna.fsf@cougar.home.aneadesign.com> References: <555EECBD.2020008@xunil.at> <555F15F4.10307@alphasrv.net> <20150522151522.Horde.gYfoqaddoIKVx8YF-pzATDh@idvwebmail02.services.datev.de> <555F4504.9060104@alphasrv.net> <555F69B6.2080707@xunil.at> <000b01d094c8$f73a2f60$e5ae8e20$@fblan.de> <878ucgbcna.fsf@cougar.home.aneadesign.com> Message-ID: <5561FB5C.2090904@xunil.at> Am 2015-05-22 um 22:06 schrieb Clemens Schüller: > Erinnert mich gerade an meine Probleme mit bsmtp.bon.at - ist der > Business Mailserver von der Telekom Austria. > > Die schaffen es einfach nicht, das helo in Verbindung mit verschiedenen > Subnets korrekt zu konfigurieren. > > Mir werden immer wieder Mails von meinem Arbeitgeber gesendet. Immer > wieder kommt es vor, dass die Mails bei mir nicht ankommen und der Chef > eine Meldung zurückbekommt, dass die Mail an mich nicht zugestellt > werden kann. Manchmal gehts, manchmal nicht - da steckt ein Loadbalancer > dahinter. Wird bei MS wohl ähnlich sein. Schade eigentlich, daß man dauernd irgendwelche Ausnahmen machen muß, und zumeist grade wegen der "big player", die mit der Ignoranz des Stärkeren operieren ... From lists at xunil.at Sun May 24 19:03:29 2015 From: lists at xunil.at (Stefan G. Weichinger) Date: Sun, 24 May 2015 19:03:29 +0200 Subject: [Postfixbuch-users] postscreen und MS Office In-Reply-To: <000a01d094c8$4ddca420$e995ec60$@fblan.de> References: <555EECBD.2020008@xunil.at> <555F15F4.10307@alphasrv.net> <555F2189.7000205@xunil.at> <000a01d094c8$4ddca420$e995ec60$@fblan.de> Message-ID: <55620461.3040900@xunil.at> Am 2015-05-22 um 21:48 schrieb Uwe Drießen: > Im Auftrag von Stefan G. Weichinger >> Ist nicht viel Traffic von dort, daher greift auch das Auto-Whitelisting >> nicht wirklich (entries veralten, bevor wieder was kommt). >> >> Aber der eine Absender, um den es geht, will ich eben definitiv schnell >> in der Inbox haben und nicht verzögern. >> > Dann schieb ihn um alle Tests drum herum wenn er dir so wichtig ist. Wie denn .. da steh ich grad auf der Leitung .. wie den "herum schieben", wenn doch postscreen die vorderste Front darstellt? From thomas.wiese at ovis-consulting.de Sun May 24 20:16:36 2015 From: thomas.wiese at ovis-consulting.de (T. Wiese, OVIS IT Consulting GmbH) Date: Sun, 24 May 2015 18:16:36 +0000 Subject: [Postfixbuch-users] postscreen und MS Office In-Reply-To: <55620461.3040900@xunil.at> References: <555EECBD.2020008@xunil.at> <555F15F4.10307@alphasrv.net> <555F2189.7000205@xunil.at> <000a01d094c8$4ddca420$e995ec60$@fblan.de> <55620461.3040900@xunil.at> Message-ID: <62473491-EB9D-47AA-936A-BDCF48B1CF83@ovis-consulting.de> Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From lists at xunil.at Mon May 25 14:36:58 2015 From: lists at xunil.at (Stefan G. Weichinger) Date: Mon, 25 May 2015 14:36:58 +0200 Subject: [Postfixbuch-users] postscreen und MS Office In-Reply-To: <62473491-EB9D-47AA-936A-BDCF48B1CF83@ovis-consulting.de> References: <555EECBD.2020008@xunil.at> <555F15F4.10307@alphasrv.net> <555F2189.7000205@xunil.at> <000a01d094c8$4ddca420$e995ec60$@fblan.de> <55620461.3040900@xunil.at> <62473491-EB9D-47AA-936A-BDCF48B1CF83@ovis-consulting.de> Message-ID: <5563176A.7060204@xunil.at> Am 2015-05-24 um 20:16 schrieb T. Wiese, OVIS IT Consulting GmbH: > Moin, > anbei mal meine Liste die ich verwende für IPv4/IPv6. MS hat da große > Netzbereiche laut ripe und nutzt diese auch? > > # outlook.com addressen > 23.103.160.0/20 permit > 23.103.224.0/19 permit [...] Danke vielmals, soeben eingebaut ... ist dann noch ein bissl umfangreicher als meine bisherige. Mußtest Du die schon öfters anpassen oder bleibt die bislang eher statisch? Stefan From thomas.wiese at ovis-consulting.de Mon May 25 16:51:40 2015 From: thomas.wiese at ovis-consulting.de (T. Wiese, OVIS IT Consulting GmbH) Date: Mon, 25 May 2015 14:51:40 +0000 Subject: [Postfixbuch-users] postscreen und MS Office In-Reply-To: <5563176A.7060204@xunil.at> References: <555EECBD.2020008@xunil.at> <555F15F4.10307@alphasrv.net> <555F2189.7000205@xunil.at> <000a01d094c8$4ddca420$e995ec60$@fblan.de> <55620461.3040900@xunil.at> <62473491-EB9D-47AA-936A-BDCF48B1CF83@ovis-consulting.de>, <5563176A.7060204@xunil.at> Message-ID: <04011F8B-1384-4FE7-853E-C18EDCE2700A@ovis-consulting.de> Moin, Die ist statisch... Keine Ausreißer ;) Mit freundlichen Grüßen Thomas > Mit freundlichen Grüßen Thomas Wiese Geschäftsführender Gesellschafter OVIS IT Consulting GmbH Arnulfstraße 95, 12105 Berlin Tel.: 030 - 2201206 01 Fax: 030 - 2201206 30 https://www.ovis-consulting.de Geschäftsführer: Thomas Wiese Handelsregister: Berlin - Charlottenburg, HRB 155424B UST-IdNr.: DE293333139 Am 25.05.2015 um 14:38 schrieb Stefan G. Weichinger : > >> Am 2015-05-24 um 20:16 schrieb T. Wiese, OVIS IT Consulting GmbH: >> Moin, >> anbei mal meine Liste die ich verwende für IPv4/IPv6. MS hat da große >> Netzbereiche laut ripe und nutzt diese auch? >> >> # outlook.com addressen >> 23.103.160.0/20 permit >> 23.103.224.0/19 permit > > [...] > > Danke vielmals, soeben eingebaut ... ist dann noch ein bissl > umfangreicher als meine bisherige. > > Mußtest Du die schon öfters anpassen oder bleibt die bislang eher statisch? > > Stefan > > > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users From stefan1 at hofmeir.de Tue May 26 00:28:36 2015 From: stefan1 at hofmeir.de (Stefan Hofmeir) Date: Tue, 26 May 2015 00:28:36 +0200 Subject: [Postfixbuch-users] Amavis und X-Original-To Message-ID: <666988034.20150526002836@hofmeir.de> Hallo zusammen, sobald Amavis in der main.cf eingebunden wird > content_filter = amavis:[xxx.xxx.xxx.xxx]:10024 schreibt Postfix im Envelope die X-Original-To Zeile auf den endgültigen Postfachnamen um. Eine Auswertung ("Über welche virtuelle Mailadresse kam die Mail rein?") wird dadurch unmöglich. Mit einem postconf -e receive_override_options=no_address_mappings funktioniert es, X-Original-To ist trotz Amavis-Einbindung wieder korrekt. Nach einem postfix reload kann jedoch Postfix leider die virtuelle Adresse dem Postfach nicht mehr zuordnen ... > The mail system > : unknown user: "virtuelle at mailadresse.de" Wie erhält man wieder funktionierend eine unveränderte X-Original-To Zeile trotz Amavis? Für Anregungen wäre ich dankbar. -- Viele Grüße Stefan From gregor at a-mazing.de Tue May 26 09:23:41 2015 From: gregor at a-mazing.de (Gregor Hermens) Date: Tue, 26 May 2015 09:23:41 +0200 Subject: [Postfixbuch-users] Amavis und X-Original-To In-Reply-To: <666988034.20150526002836@hofmeir.de> References: <666988034.20150526002836@hofmeir.de> Message-ID: <201505260923.41686@office.a-mazing.net> Hallo Stefan, Am Dienstag, 26. Mai 2015 schrieb Stefan Hofmeir: > sobald Amavis in der main.cf eingebunden wird > > > content_filter = amavis:[xxx.xxx.xxx.xxx]:10024 > > schreibt Postfix im Envelope die X-Original-To Zeile auf den > endgültigen Postfachnamen um. Eine Auswertung ("Über welche virtuelle > Mailadresse kam die Mail rein?") wird dadurch unmöglich. > > Mit einem > postconf -e receive_override_options=no_address_mappings > funktioniert es, X-Original-To ist trotz Amavis-Einbindung wieder > korrekt. > > Nach einem postfix reload kann jedoch Postfix leider die virtuelle > Adresse dem Postfach nicht mehr zuordnen ... > > > The mail system > > > > : unknown user: "virtuelle at mailadresse.de" > > Wie erhält man wieder funktionierend eine unveränderte X-Original-To > Zeile trotz Amavis? du hast das Adress-Mapping global unterdrückt. Stattdessen darf das nur im für die Übergabe an Amavis zuständigen Eintrag der master.cf passieren. Wenn die Mail von Amavis zurückkommt soll ja gemapped werden... Gruß, Gregor -- @mazing fon +49 8142 6528665 Gregor Hermens fax +49 8142 6528669 Brucker Strasse 12 gregor.hermens at a-mazing.de D-82216 Gernlinden http://www.a-mazing.de/ From BHueck at kevag-telekom.de Thu May 28 16:47:33 2015 From: BHueck at kevag-telekom.de (=?utf-8?B?QmVuamFtaW4gSMO8Y2s=?=) Date: Thu, 28 May 2015 14:47:33 +0000 Subject: [Postfixbuch-users] Postfix, Verteiler und Amavis Message-ID: <55672A89.20708@kevag-telekom.de> Hallo zusammen, eine kurze Frage zu Postfix, Verteilern und Amavis anhand eines Beispiels: Eingehende Mail an einen Verteiler "verteiler at domain.de". Eingehende Mails werden aktuell direkt durch smtp_proxy_filter (Übergabe per Milter-Schnittstelle) gefiltert: local at intern verteiler at domain.de -> local at extern usw. Danach erfolgt per "transport-table" in Postfix der Transport der Mail: * local at intern -> Speicherung intern (lmtp usw.) * local at extern -> Versand per SMTP an ext. MTA In dem Fall "local at intern" würde die Mail nun lokal zugestellt, unbeachtet der Nutzer-spezifischen Amavis-Einstellungen. Wäre ja bspw. schlecht, wenn kein Viren- und Spamcheck für die Verteileradresse durch Amavis gegeben ist; somit soll die Nutzer-spezifischen Amavis-Policy die Annahme der Mail (wir gehen davon aus, es ist eine Viren/Spam Mail) verhindern. Ebenfalls tritt das Problem auf für die WB-Listen in Amavis, oder? Wie kann ich erreichen, dass diese Nutzer-spezifischen Amavis-Einstellungen noch angewendet werden, bevor die Mail lokal eingeliefert wird? Oder kann ich nur für den Verteiler eine Amavis-Policy definieren? Welche Probleme können dadurch entstehen? Oder gibt es einen anderen "Weg", dies zu lösen? Vielen Dank und viele Grüße Benjamin Hück -- ________________________________ ________________________________ KEVAG Telekom GmbH Cusanusstr. 7 D-56073 Koblenz Fon: +49 261 20162-0 Fax: +49 261 20162-25100 http://www.kevag-telekom.de/ Geschäftsführer: Bernd Gowitzke, Gerd Thewalt Sitz der Gesellschaft: Koblenz, Amtsgericht Koblenz, HRB Nr. 5343 USt.IdNr. DE 18 77 67 843 St-Nr. 22/650/0182/7 From t.maffert at owl3d.de Fri May 29 19:43:54 2015 From: t.maffert at owl3d.de (Tobias Maffert) Date: Fri, 29 May 2015 19:43:54 +0200 Subject: [Postfixbuch-users] Exchange > Postfix Submission Port ... Message-ID: <003501d09a37$0917d520$1b477f60$@owl3d.de> Hallo zusammen :) Ich plane derzeit einen Exchange Server 2010 über Port 587 (Submission) via Smarthost mit meinem Postfix Server zu verbinden. Über Port 25 ist das kein Problem, das funktioniert. Da dieser aber gefiltert wird usw. soll Exchange über Port 587 die Mails reinschicken. Aber bei Port 587 habe ich irgendwie Probleme! Meine main.cf habe ich so angepasst, dass er die E-Mails von dem Exchange Server entgegennimmt: mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 ip.von.meinem.exchange Der submission Teil meiner master.cf schaut wie folgt aus: submission inet n - - - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_proxy_filter=localhost:10026 Ich vermute das bei dem Submission Teil noch irgendwie etwas hin muss, das die IP vom Exchange expliziert erlaubt. Ist das richtig? Und wie müsste der „Befehl“ aussehen? -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From t.maffert at owl3d.de Fri May 29 19:59:44 2015 From: t.maffert at owl3d.de (Tobias Maffert) Date: Fri, 29 May 2015 19:59:44 +0200 Subject: [Postfixbuch-users] Exchange > Postfix Submission Port ... In-Reply-To: <003501d09a37$0917d520$1b477f60$@owl3d.de> References: <003501d09a37$0917d520$1b477f60$@owl3d.de> Message-ID: <004401d09a39$3f104a70$bd30df50$@owl3d.de> Ach ups, hier die Fehlermeldung die ich erhalte: May 29 19:54:01 mail postfix/smtpd[13709]: NOQUEUE: reject: RCPT from [ip.vom.exchange.server]: 554 5.7.1 : Client host rejected: Access denied; from= to= proto=ESMTP helo= May 29 19:54:02 mail postfix/smtpd[13709]: disconnect from ip.vom.exchange.server Exchange über Port 587 > Postfix normale mit Port 25 > in die weite E-Mail Welt … ;D Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Tobias Maffert Gesendet: Freitag, 29. Mai 2015 19:44 An: postfixbuch-users at listen.jpberlin.de Betreff: [Postfixbuch-users] Exchange > Postfix Submission Port ... Hallo zusammen :) Ich plane derzeit einen Exchange Server 2010 über Port 587 (Submission) via Smarthost mit meinem Postfix Server zu verbinden. Über Port 25 ist das kein Problem, das funktioniert. Da dieser aber gefiltert wird usw. soll Exchange über Port 587 die Mails reinschicken. Aber bei Port 587 habe ich irgendwie Probleme! Meine main.cf habe ich so angepasst, dass er die E-Mails von dem Exchange Server entgegennimmt: mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 ip.von.meinem.exchange Der submission Teil meiner master.cf schaut wie folgt aus: submission inet n - - - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_proxy_filter=localhost:10026 Ich vermute das bei dem Submission Teil noch irgendwie etwas hin muss, das die IP vom Exchange expliziert erlaubt. Ist das richtig? Und wie müsste der „Befehl“ aussehen? -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From Zahlenmaler at t-online.de Fri May 29 20:41:40 2015 From: Zahlenmaler at t-online.de (=?windows-1252?Q?Robert_M=F6ker?=) Date: Fri, 29 May 2015 20:41:40 +0200 Subject: [Postfixbuch-users] Exchange > Postfix Submission Port ... In-Reply-To: <003501d09a37$0917d520$1b477f60$@owl3d.de> References: <003501d09a37$0917d520$1b477f60$@owl3d.de> Message-ID: <5568B2E4.9070903@t-online.de> Am 29.05.2015 um 19:43 schrieb Tobias Maffert: > > -o smtpd_client_restrictions=permit_sasl_authenticated,reject > erlauben wer sich per sasl authentifiziert, alles andere verbieten >>>>helo= Wer das frei ins Internet lässt gehört auch übers Knie gelegt. From t.maffert at owl3d.de Fri May 29 20:54:08 2015 From: t.maffert at owl3d.de (Tobias Maffert) Date: Fri, 29 May 2015 20:54:08 +0200 Subject: [Postfixbuch-users] Exchange > Postfix Submission Port ... In-Reply-To: <5568B2E4.9070903@t-online.de> References: <003501d09a37$0917d520$1b477f60$@owl3d.de> <5568B2E4.9070903@t-online.de> Message-ID: <005101d09a40$d8afaac0$8a0f0040$@owl3d.de> Meinst du das ist eine schlechte Idee so wie ich das vorhabe? Wo würde denn in dem Fall das " helo=" hinkommen? -o helo= So`? Habe da noch Verständnisprobleme :S Oder hast du ne andere Idee wie man das "recht einfach" oder noch sicherer lösen könnte? -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Robert Möker Gesendet: Freitag, 29. Mai 2015 20:42 An: postfixbuch-users at listen.jpberlin.de Betreff: Re: [Postfixbuch-users] Exchange > Postfix Submission Port ... Am 29.05.2015 um 19:43 schrieb Tobias Maffert: > > -o smtpd_client_restrictions=permit_sasl_authenticated,reject > erlauben wer sich per sasl authentifiziert, alles andere verbieten >>>>helo= Wer das frei ins Internet lässt gehört auch übers Knie gelegt. -- _______________________________________________ Postfixbuch-users -- http://www.postfixbuch.de Heinlein Professional Linux Support GmbH Postfixbuch-users at listen.jpberlin.de https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users From t.maffert at owl3d.de Fri May 29 21:07:33 2015 From: t.maffert at owl3d.de (test) Date: Fri, 29 May 2015 21:07:33 +0200 Subject: [Postfixbuch-users] Exchange > Postfix Submission Port ... In-Reply-To: <005101d09a40$d8afaac0$8a0f0040$@owl3d.de> References: <003501d09a37$0917d520$1b477f60$@owl3d.de> <5568B2E4.9070903@t-online.de> <005101d09a40$d8afaac0$8a0f0040$@owl3d.de> Message-ID: <5568B8F5.8000605@owl3d.de> Achso jetzt hab ich das geschnallt. Die Log-Dateien habe ich "anonymisiert", deswegen dieser Eintrag .. Zum Postfix sollte das ja egal sein, denn der Postfix ist ja der, der mir der Außenwelt kommuniziert und der ist soweit Ordnungsgemäß ;) Bekomme das irgendwie nicht hin, das Exchange sich via TLS (SASL) am Postfix Authentifiziert. Hat da jemand vielleicht Konfigurationsbeispiele? Am 29.05.2015 um 20:54 schrieb Tobias Maffert: > Meinst du das ist eine schlechte Idee so wie ich das vorhabe? > > Wo würde denn in dem Fall das " helo=" hinkommen? > > -o helo= > So`? > > Habe da noch Verständnisprobleme :S > > Oder hast du ne andere Idee wie man das "recht einfach" oder noch sicherer > lösen könnte? > > -----Ursprüngliche Nachricht----- > Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] > Im Auftrag von Robert Möker > Gesendet: Freitag, 29. Mai 2015 20:42 > An: postfixbuch-users at listen.jpberlin.de > Betreff: Re: [Postfixbuch-users] Exchange > Postfix Submission Port ... > > > Am 29.05.2015 um 19:43 schrieb Tobias Maffert: >> -o smtpd_client_restrictions=permit_sasl_authenticated,reject >> > erlauben wer sich per sasl authentifiziert, alles andere verbieten > >>>>> helo= > Wer das frei ins Internet lässt gehört auch übers Knie gelegt. > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de Heinlein Professional Linux > Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users > From tech at kdmails.de Fri May 29 22:20:02 2015 From: tech at kdmails.de (Daniel Gompf) Date: Fri, 29 May 2015 22:20:02 +0200 Subject: [Postfixbuch-users] Exchange > Postfix Submission Port ... In-Reply-To: <004401d09a39$3f104a70$bd30df50$@owl3d.de> References: <003501d09a37$0917d520$1b477f60$@owl3d.de> <004401d09a39$3f104a70$bd30df50$@owl3d.de> Message-ID: <5568C9F2.1000208@kdmails.de> Hallo, meldet sich dein Exchange am Postfix an? Soll er sich anmelden? Ich gehe davon aus, da du "-o smtpd_client_restrictions=permit_sasl_authenticated,reject" drin hast. Leider sieht man das aus den Logdaten nicht. Am 29.05.2015 um 19:59 schrieb Tobias Maffert: > > Ach ups, hier die Fehlermeldung die ich erhalte: > > May 29 19:54:01 mail postfix/smtpd[13709]: NOQUEUE: reject: RCPT from > [ip.vom.exchange.server]: 554 5.7.1 > : Client host > rejected: Access denied; from= > to= proto=ESMTP helo= > > May 29 19:54:02 mail postfix/smtpd[13709]: disconnect from > ip.vom.exchange.server > > Exchange über Port 587 > Postfix normale mit Port 25 > in die weite > E-Mail Welt ? ;D > > *Von:*Postfixbuch-users > [mailto:postfixbuch-users-bounces at listen.jpberlin.de] *Im Auftrag von > *Tobias Maffert > *Gesendet:* Freitag, 29. Mai 2015 19:44 > *An:* postfixbuch-users at listen.jpberlin.de > *Betreff:* [Postfixbuch-users] Exchange > Postfix Submission Port ... > > Hallo zusammen :) > > Ich plane derzeit einen Exchange Server 2010 über Port 587 > (Submission) via Smarthost mit meinem Postfix Server zu verbinden. > > Über Port 25 ist das kein Problem, das funktioniert. Da dieser aber > gefiltert wird usw. soll Exchange über Port 587 die Mails > reinschicken. Aber bei Port 587 habe ich irgendwie Probleme! > > Meine main.cf habe ich so angepasst, dass er die E-Mails von dem > Exchange Server entgegennimmt: > > mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 > ip.von.meinem.exchange > > Der submission Teil meiner master.cf schaut wie folgt aus: > > submission inet n - - - - smtpd > > -o smtpd_tls_security_level=encrypt > > -o smtpd_sasl_auth_enable=yes > > -o smtpd_client_restrictions=permit_sasl_authenticated,reject > > -o smtpd_proxy_filter=localhost:10026 > > Ich vermute das bei dem Submission Teil noch irgendwie etwas hin muss, > das die IP vom Exchange expliziert erlaubt. Ist das richtig? Und wie > müsste der ?Befehl? aussehen? > > > -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From t.maffert at owl3d.de Fri May 29 22:51:33 2015 From: t.maffert at owl3d.de (test) Date: Fri, 29 May 2015 22:51:33 +0200 Subject: [Postfixbuch-users] Exchange > Postfix Submission Port ... In-Reply-To: <5568C9F2.1000208@kdmails.de> References: <003501d09a37$0917d520$1b477f60$@owl3d.de> <004401d09a39$3f104a70$bd30df50$@owl3d.de> <5568C9F2.1000208@kdmails.de> Message-ID: <5568D155.4060806@owl3d.de> Hallo, also in den Tests hat der Exchange Server via Port 25, ohne Authentifizierung, Postfix die Mails übergeben. Sprich in der Main.cf war die IP-Adresse vom Exchange Server drin, so das er die E-Mails von der IP entgegen nimmt. Der Abschnitt der main.cf sieht so aus: mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 ip.zu.meinem.exchange Da ich nun Amavis einsetze und die Geschichte über Port 587 (submission) laufen soll, funktioniert das durch die master.cf und meiner Konfiguration: submission inet n - - - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_proxy_filter=localhost:10026 so nicht mehr. Ich könnte nun -o smtpd_client_restrictions=permit_mynetworks, permit_sasl_authenticated,reject verwenden nur wirklich gut/sicher ist das doch auch nicht oder? Ich weiß halt nicht wie man Exchange vernünftig bzw. sicher mit Postfix verknüpft bzw. verknüpfen sollte?! Wie macht ihr das denn? Oder wie würdet ihr das machen? Es geht jetzt ausschließlich darum, das Exchange die Mails die an Extern geschickt werden, möglichst sicher an Postfix weiterleitet. Der Postfix Server selber, steht im Internet! ;) Am 29.05.2015 um 22:20 schrieb Daniel Gompf: > Hallo, > > meldet sich dein Exchange am Postfix an? Soll er sich anmelden? Ich > gehe davon aus, da du "-o > smtpd_client_restrictions=permit_sasl_authenticated,reject" drin hast. > Leider sieht man das aus den Logdaten nicht. > > Am 29.05.2015 um 19:59 schrieb Tobias Maffert: >> >> Ach ups, hier die Fehlermeldung die ich erhalte: >> >> May 29 19:54:01 mail postfix/smtpd[13709]: NOQUEUE: reject: RCPT from >> [ip.vom.exchange.server]: 554 5.7.1 >> : Client host >> rejected: Access denied; from= >> to= proto=ESMTP helo= >> >> May 29 19:54:02 mail postfix/smtpd[13709]: disconnect from >> ip.vom.exchange.server >> >> Exchange über Port 587 > Postfix normale mit Port 25 > in die weite >> E-Mail Welt ? ;D >> >> *Von:*Postfixbuch-users >> [mailto:postfixbuch-users-bounces at listen.jpberlin.de] *Im Auftrag von >> *Tobias Maffert >> *Gesendet:* Freitag, 29. Mai 2015 19:44 >> *An:* postfixbuch-users at listen.jpberlin.de >> *Betreff:* [Postfixbuch-users] Exchange > Postfix Submission Port ... >> >> Hallo zusammen :) >> >> Ich plane derzeit einen Exchange Server 2010 über Port 587 >> (Submission) via Smarthost mit meinem Postfix Server zu verbinden. >> >> Über Port 25 ist das kein Problem, das funktioniert. Da dieser aber >> gefiltert wird usw. soll Exchange über Port 587 die Mails >> reinschicken. Aber bei Port 587 habe ich irgendwie Probleme! >> >> Meine main.cf habe ich so angepasst, dass er die E-Mails von dem >> Exchange Server entgegennimmt: >> >> mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 >> ip.von.meinem.exchange >> >> Der submission Teil meiner master.cf schaut wie folgt aus: >> >> submission inet n - - - - smtpd >> >> -o smtpd_tls_security_level=encrypt >> >> -o smtpd_sasl_auth_enable=yes >> >> -o smtpd_client_restrictions=permit_sasl_authenticated,reject >> >> -o smtpd_proxy_filter=localhost:10026 >> >> Ich vermute das bei dem Submission Teil noch irgendwie etwas hin >> muss, das die IP vom Exchange expliziert erlaubt. Ist das richtig? >> Und wie müsste der ?Befehl? aussehen? >> >> >> > > > > -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From tech at kdmails.de Fri May 29 23:34:21 2015 From: tech at kdmails.de (Daniel Gompf) Date: Fri, 29 May 2015 23:34:21 +0200 Subject: [Postfixbuch-users] Exchange > Postfix Submission Port ... In-Reply-To: <5568D155.4060806@owl3d.de> References: <003501d09a37$0917d520$1b477f60$@owl3d.de> <004401d09a39$3f104a70$bd30df50$@owl3d.de> <5568C9F2.1000208@kdmails.de> <5568D155.4060806@owl3d.de> Message-ID: <5568DB5D.6020702@kdmails.de> Am 29.05.2015 um 22:51 schrieb test: > Hallo, > > also in den Tests hat der Exchange Server via Port 25, ohne > Authentifizierung, Postfix die Mails übergeben. Sprich in der Main.cf > war die IP-Adresse vom Exchange Server drin, so das er die E-Mails von > der IP entgegen nimmt. > > Der Abschnitt der main.cf sieht so aus: > > mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 > ip.zu.meinem.exchange > > Da ich nun Amavis einsetze und die Geschichte über Port 587 > (submission) laufen soll, funktioniert das durch die master.cf und > meiner Konfiguration: > > submission inet n - - - - smtpd > -o smtpd_tls_security_level=encrypt > -o smtpd_sasl_auth_enable=yes > -o smtpd_client_restrictions=permit_sasl_authenticated,reject > -o smtpd_proxy_filter=localhost:10026 > > so nicht mehr. Ich könnte nun > > -o smtpd_client_restrictions=permit_mynetworks, > permit_sasl_authenticated,reject > > verwenden nur wirklich gut/sicher ist das doch auch nicht oder? Ich > weiß halt nicht wie man Exchange vernünftig bzw. sicher mit Postfix > verknüpft bzw. verknüpfen sollte?! Wie macht ihr das denn? Oder wie > würdet ihr das machen? Wir lassen den Exchange auch auf 587 mit TLS einliefern, jedoch muss der sich anmelden. Wir machen da keinen Unterschied zwischen einem Exchange oder einem Nutzer der mit seinem MUA kommt. Wenn du das so machen möchtest, muss dem Sende-Connector noch mitteilen, dass er sich anmelden muss und TLS verwenden soll. > > Es geht jetzt ausschließlich darum, das Exchange die Mails die an > Extern geschickt werden, möglichst sicher an Postfix weiterleitet. Der > Postfix Server selber, steht im Internet! ;) > > > Am 29.05.2015 um 22:20 schrieb Daniel Gompf: >> Hallo, >> >> meldet sich dein Exchange am Postfix an? Soll er sich anmelden? Ich >> gehe davon aus, da du "-o >> smtpd_client_restrictions=permit_sasl_authenticated,reject" drin >> hast. Leider sieht man das aus den Logdaten nicht. >> >> Am 29.05.2015 um 19:59 schrieb Tobias Maffert: >>> >>> Ach ups, hier die Fehlermeldung die ich erhalte: >>> >>> May 29 19:54:01 mail postfix/smtpd[13709]: NOQUEUE: reject: RCPT >>> from [ip.vom.exchange.server]: 554 5.7.1 >>> : Client host >>> rejected: Access denied; from= >>> to= proto=ESMTP helo= >>> >>> May 29 19:54:02 mail postfix/smtpd[13709]: disconnect from >>> ip.vom.exchange.server >>> >>> Exchange über Port 587 > Postfix normale mit Port 25 > in die weite >>> E-Mail Welt ? ;D >>> >>> *Von:*Postfixbuch-users >>> [mailto:postfixbuch-users-bounces at listen.jpberlin.de] *Im Auftrag >>> von *Tobias Maffert >>> *Gesendet:* Freitag, 29. Mai 2015 19:44 >>> *An:* postfixbuch-users at listen.jpberlin.de >>> *Betreff:* [Postfixbuch-users] Exchange > Postfix Submission Port ... >>> >>> Hallo zusammen :) >>> >>> Ich plane derzeit einen Exchange Server 2010 über Port 587 >>> (Submission) via Smarthost mit meinem Postfix Server zu verbinden. >>> >>> Über Port 25 ist das kein Problem, das funktioniert. Da dieser aber >>> gefiltert wird usw. soll Exchange über Port 587 die Mails >>> reinschicken. Aber bei Port 587 habe ich irgendwie Probleme! >>> >>> Meine main.cf habe ich so angepasst, dass er die E-Mails von dem >>> Exchange Server entgegennimmt: >>> >>> mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 >>> ip.von.meinem.exchange >>> >>> Der submission Teil meiner master.cf schaut wie folgt aus: >>> >>> submission inet n - - - - smtpd >>> >>> -o smtpd_tls_security_level=encrypt >>> >>> -o smtpd_sasl_auth_enable=yes >>> >>> -o smtpd_client_restrictions=permit_sasl_authenticated,reject >>> >>> -o smtpd_proxy_filter=localhost:10026 >>> >>> Ich vermute das bei dem Submission Teil noch irgendwie etwas hin >>> muss, das die IP vom Exchange expliziert erlaubt. Ist das richtig? >>> Und wie müsste der ?Befehl? aussehen? >>> >>> >>> >> >> >> >> > > > -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From matthias.doering at mldsc.de Sat May 30 00:15:15 2015 From: matthias.doering at mldsc.de (=?utf-8?Q?Matthias_D=C3=B6ring?=) Date: Sat, 30 May 2015 00:15:15 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <20150522193237.GB14875@sys4.de> References: <555DB39F.1070807@yahoo.de> <555E2041.3040701@rolandschnabel.de> <555EC455.7070801@web.de> <001c01d0947f$6b994a70$42cbdf50$@ist-immer-online.de> <20150522112644.GC24854@sys4.de> <005801d09486$62c328b0$28497a10$@ist-immer-online.de> <20150522125315.GA30226@sys4.de> <000601d0949a$3e2f5c30$ba8e1490$@ist-immer-online.de> <20150522160108.GA9710@sys4.de> <000d01d094ae$60387f00$20a97d00$@ist-immer-online.de> <20150522193237.GB14875@sys4.de> Message-ID: <16169B01-1401-4982-9DE8-6405E680EAF8@mldsc.de> Nur so mal so. Ich finde trusted Connections sehr gut. Aber wieso sollte ich mir die Arbeit machen bestimmte Connections zu trusten? Es gibt keine Funktionseinschränkung. Ich sehe noch nicht denn Grund warum ein Mailadmin sich diese Arbeit machen soll? > Am 22.05.2015 um 21:32 schrieb Patrick Ben Koetter

: > > * Daniel : >> Hi Patrick, >> >> danke, hat geklappt im Test mit nem Synology Server und posteo als Mailrelay. >> >> Konkret in /volume1/@appstore/MailServer/etc/template/main.template >> smtp_tls_security_level = may >> >> ersetzt durch >> smtp_tls_security_level = fingerprint >> smtp_tls_fingerprint_cert_match = 3A:89:D8:AD:DC:A7:23:5C:8F:44:E9:DD:2E:85:6A:31:D2:D3:C9:70 >> >> Fingerprints kann man sich auch z.B. https://de.ssl-tools.net/mailservers/posteo.de hier entnehmen. >> >> Rest wie smtp_tls_fingerprint_digest = sha1 passte schon im Template. >> >> Wenn man mit Path arbeitet, kann man den postfix sagen, soll die Certs selbst dort sammeln und speichern, oder müsste ich mir für >> sätmliche große Server wenn dann Cert dort einfügen bzw. die fingerprints? > > Bei Trust willst Du Postfix nicht selber sammeln lassen. Wie sollte er denn > herausfinden, ob er dem was er gefunden hat, trusten soll? Das geht mit DANE > TLS, aber nicht mit statischen Cert Stores im Filesystem wie z.b. einer Datei > auf die Du mit CApath verweist. > > Wenn Du sämtliche Server verifzieren willst, dann musst Du das entweder von > Hand machen oder DANE einsetzen. Das geht dann automatisch - vorausgesetzt das > Ziel bietet DNSSEC und TLSA RRs an. > > Deine Beispieldomain posteo.de unterstützt DANE, wie Du dem DANE Validator > entnehmen kannst: > https://dane.sys4.de/smtp/posteo.de > > p at rick > > > >> >> Gruß Daniel >> -----Ursprüngliche Nachricht----- >> Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter >> Gesendet: Freitag, 22. Mai 2015 18:01 >> An: postfixbuch-users at listen.jpberlin.de >> Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES >> >> * Daniel : >>> Hi Patrick, >>> >>> denke der Fehler ist so schon korrekt mit untrustet, und mein Denkfehler war wohl in der schnelle, dass ich mein eigenes >> Zertifikat >>> angeben muss, und nicht mit dem vom Zielserver (Mailrelay) >>> >>> also lasse ich es wie es war. Würde der Mailserver direkt versenden, müsste ich wohl Path angeben, und für sämtliche Servern wie >>> Telekom, Google, 1&1, GMX und co entsprechend dann hinterlegen in dem Ordner, oder? >> >> Genau. >> >> Wenn Du willst, dann kannst Du über smtp_tls_policy_maps das Zertifikat Deines >> Relayserver pinnen (fingerprint). Dann gilt er als Verified. >> >> p at rick >> >> >> >>> >>> Gruß Daniel >>> >>> -----Ursprüngliche Nachricht----- >>> Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter >>> Gesendet: Freitag, 22. Mai 2015 14:53 >>> An: postfixbuch-users at listen.jpberlin.de >>> Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES >>> >>> * Daniel : >>>> Hallo Patrick, >>>> >>>> danke für die Antwort, leider klappt es nicht., weiterhin untrustet zum externen Mailrelay. >>>> >>>> Ich habe probiert >>>> smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt >>> >>> Das server-ca.crt weist wen aus? Ist das die CA mit der das Zertifikat des >>> "externen Mailrelay" signiert wurde? >>> >>>> und dann noch >>>> smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem >>>> smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key >>>> smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt >>>> >>>> Weitere Optionen mit smtp_ in der main.cf sind: >>>> smtp_tls_security_level = may >>>> smtp_tls_loglevel = 1 >>>> smtp_tls_fingerprint_digest = sha1 >>>> smtp_tls_note_starttls_offer = yes >>>> smtp_host_lookup = dns, native >>>> smtp_use_tls = yes >>> >>> Mach mal: >>> >>> openssl s_client -starttls smtp -CAfile /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt -connect $externesMailrelay:25 >>> >>> Und sende den output hier her. >>> >>> p at rick >>> >>> >>> >>> >>>> >>>> Gruß Daniel >>>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter >>>> Gesendet: Freitag, 22. Mai 2015 13:27 >>>> An: postfixbuch-users at listen.jpberlin.de >>>> Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES >>>> >>>> * Daniel : >>>>> Guten Tag, >>>>> >>>>> ich habe ein ähnliches Anliegen. >>>>> >>>>> Im Maillog steht beim Versenden von Mails z.B.: >>>>> postfix/smtp: Untrusted TLS connection established to mail.x.de[x.x.x.x]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 >>>>> (256/256 bits) >>>>> >>>>> Darauf hin habe ich habe ich mal main.cf geschaut nach dem in den Mail vom Werner bei den genannten Parameter. >>>>> >>>>> Dort habe ich nur gefunden: >>>>> smtpd_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem >>>>> smtpd_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key >>>>> >>>>> Dieses bezieht sich dann ja wohl nur für eingehende Verbindung, also müsste ich z.B. >>>>> smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem >>>>> smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key >>>>> >>>>> hinzufügen damit auch für ausgehende Verbindung Zertifikat verwendet wird und das untrustet verschwindet? >>>> >>>> >>>> Nein. Mit Deiner Änderung könnte der Postfix smtp-Client sich einem Server >>>> gegenüber ausweisen, wenn >>>> >>>> - das Zertifikat für Client Usage geeignet ist >>>> - der Server das Client-Zertifikat anfragt >>>> >>>> Du musst smtp_tls_CAfile setzen, damit der Client die Zertifikate anderer >>>> SMTP-Server verifizieren kann, z.B.: >>>> >>>> smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt >>>> >>>> p at rick >>>> >>>> >>>> >>>>> >>>>> Bin noch dabei mich mit ganzen Materie stärker vertraut zumachen. >>>>> >>>>> Gruß Daniel >>>>> >>>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Werner Flamme >>>>> Gesendet: Freitag, 22. Mai 2015 07:53 >>>>> An: postfixbuch-users at listen.jpberlin.de >>>>> Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES >>>>> >>>>> Roland Schnabel [21.05.2015 20:13]: >>>>>> >>>>>>> On 21.05.2015 12:29, Ralf Hansen wrote: >>>>>>> >>>>>>> Aber selbst bei Einrichtung eine Eintrages in /etc/hosts >>>>>>> 10.100.120.251 interner-server.mein-netz.de >>>>>>> >>>>>>> und Nutzung von >>>>>>> relayhost = interner-server.mein-netz.de >>>>>>> >>>>>>> erhalte ich eine Untrusted TLS connection? >>>>>> >>>>>> Postfix ignoriert /etc/hosts per Default: >>>>>> smtp_host_lookup = dns >>>>> >>>>> Trusted oder nicht hat nichts mit DNS zu tun, sondern damit, ob die >>>>> Zertifikatskette anerkannt wird. Das Root-Zertifikat der Kette sollte in >>>>> dem Verzeichnis liegen, das mit smtp_tls_CApath definiert wird (für >>>>> ausgehende Verbindungen; für eingehende ist es smtpd_tls_CApath). >>>>> >>>>> HDH, Werner >>> >>> >>> -- >>> _______________________________________________ >>> Postfixbuch-users -- http://www.postfixbuch.de >>> Heinlein Professional Linux Support GmbH >>> >>> Postfixbuch-users at listen.jpberlin.de >>> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users >> >> -- >> [*] sys4 AG >> >> https://sys4.de, +49 (89) 30 90 46 64 >> Franziskanerstraße 15, 81669 München >> >> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 >> Vorstand: Patrick Ben Koetter, Marc Schiffbauer >> Aufsichtsratsvorsitzender: Florian Kirstein >> >> -- >> _______________________________________________ >> Postfixbuch-users -- http://www.postfixbuch.de >> Heinlein Professional Linux Support GmbH >> >> Postfixbuch-users at listen.jpberlin.de >> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users >> >> >> -- >> _______________________________________________ >> Postfixbuch-users -- http://www.postfixbuch.de >> Heinlein Professional Linux Support GmbH >> >> Postfixbuch-users at listen.jpberlin.de >> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users > > -- > [*] sys4 AG > > https://sys4.de, +49 (89) 30 90 46 64 > Franziskanerstraße 15, 81669 München > > Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 > Vorstand: Patrick Ben Koetter, Marc Schiffbauer > Aufsichtsratsvorsitzender: Florian Kirstein > > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users From p at sys4.de Sat May 30 06:27:33 2015 From: p at sys4.de (Patrick Ben Koetter) Date: Sat, 30 May 2015 06:27:33 +0200 Subject: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES In-Reply-To: <16169B01-1401-4982-9DE8-6405E680EAF8@mldsc.de> References: <555EC455.7070801@web.de> <001c01d0947f$6b994a70$42cbdf50$@ist-immer-online.de> <20150522112644.GC24854@sys4.de> <005801d09486$62c328b0$28497a10$@ist-immer-online.de> <20150522125315.GA30226@sys4.de> <000601d0949a$3e2f5c30$ba8e1490$@ist-immer-online.de> <20150522160108.GA9710@sys4.de> <000d01d094ae$60387f00$20a97d00$@ist-immer-online.de> <20150522193237.GB14875@sys4.de> <16169B01-1401-4982-9DE8-6405E680EAF8@mldsc.de> Message-ID: <20150530042733.GA6798@sys4.de> * Matthias Döring : > Nur so mal so. Ich finde trusted Connections sehr gut. Aber wieso sollte ich mir die Arbeit machen bestimmte Connections zu trusten? Es gibt keine Funktionseinschränkung. Ich sehe noch nicht denn Grund warum ein Mailadmin sich diese Arbeit machen soll? Wir nutzen certificate pinning und DANE, weil wir nicht nur verschlüsseln wollen, sondern weil wir auch wissen wollen _mit wem_ wir dabei 'reden'. STARTTLS ist angreifbar im Verbindungsaufbau gegen "Downgrade Attack" und "Man in the Middle". Das dürfte der Grund sein, den Du suchst. Diese beiden Angriffsvektoren unterbindest Du mit certificate pinning, das - wie Du selber anmerkst - arbeitsaufwändig ist. Eleganter und mit weitaus geringerem Administrationsaufwand verbunden ist DANE. Hier announced man über einen DNSSEC-Kanal die Tatsache, dass ein SMTP-Server STARTTLS unterstützt und wie man den Server identifizieren kann. Auf Clientseite ist DANE ruck zuck eingerichtet. Du brauchst einen lokalen, DNSSEC-fähigen Resolver wie z.B. unbound. Nach dem Start prüfst Du, ob er DNSSEC verifizeren kann: $ dig +dnssec sys4.de ; <<>> DiG 9.8.1-P1 <<>> +dnssec sys4.de ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5075 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3 Wenn Du das 'ad' in der letzten Zeilen oben erhältst, dann hat er sys4.de als 'authenticated domain' erkannt und das bedeutet er konnte ihren DNSSEC-Status verifizieren. Dann trägst du 127.0.0.1 als ersten resolver in die /etc/resolv.conf ein und aktualisierst ggf. auch noch die /var/spool/postfix/etc/resolv.conf. In Deinem Postfix (version +2.11.1) setzt Du jetzt für den smtp Client: smtp_dns_support_level = dnssec smtp_tls_security_level = dane smtp_tls_loglevel = 1 Zum Testen sendest Du eine Mail an sink at dane.sys4.de. Im Log solltest Du jetzt anstatt 'trusted' ein 'verified' sehen. Fertig. Aus die Maus. ;) Auf Serverseite braucht es eine DNSSEC-aktivierte ZONE. Das ist - technisch betrachet - auch nicht so schwierig, aber es ist mit mehr operativen Risiken und Hürden verbunden. Bekommt man mit der erforderlichen Erfahrung auch alles gut hin. Wir machen das seit 1 1/2 Jahren sehr erfolgreich im Grosskundenbereich. Im Privatbereich ist DANE im Moment noch ein echtes Liebhaberstück. Es beginnt schon damit, dass Registrare selten "Wir supporten DNSSEC" an ihre Haustür schreiben. In .nl ist das anders. Da fördert der Staat DNSSEC indem er Domains bei der Konnektivierung bezuschusst wenn sie von Anfang an DNSSEC-aktiviert werden. > > > > Am 22.05.2015 um 21:32 schrieb Patrick Ben Koetter

: > > > > * Daniel : > >> Hi Patrick, > >> > >> danke, hat geklappt im Test mit nem Synology Server und posteo als Mailrelay. > >> > >> Konkret in /volume1/@appstore/MailServer/etc/template/main.template > >> smtp_tls_security_level = may > >> > >> ersetzt durch > >> smtp_tls_security_level = fingerprint > >> smtp_tls_fingerprint_cert_match = 3A:89:D8:AD:DC:A7:23:5C:8F:44:E9:DD:2E:85:6A:31:D2:D3:C9:70 > >> > >> Fingerprints kann man sich auch z.B. https://de.ssl-tools.net/mailservers/posteo.de hier entnehmen. > >> > >> Rest wie smtp_tls_fingerprint_digest = sha1 passte schon im Template. > >> > >> Wenn man mit Path arbeitet, kann man den postfix sagen, soll die Certs selbst dort sammeln und speichern, oder müsste ich mir für > >> sätmliche große Server wenn dann Cert dort einfügen bzw. die fingerprints? > > > > Bei Trust willst Du Postfix nicht selber sammeln lassen. Wie sollte er denn > > herausfinden, ob er dem was er gefunden hat, trusten soll? Das geht mit DANE > > TLS, aber nicht mit statischen Cert Stores im Filesystem wie z.b. einer Datei > > auf die Du mit CApath verweist. > > > > Wenn Du sämtliche Server verifzieren willst, dann musst Du das entweder von > > Hand machen oder DANE einsetzen. Das geht dann automatisch - vorausgesetzt das > > Ziel bietet DNSSEC und TLSA RRs an. > > > > Deine Beispieldomain posteo.de unterstützt DANE, wie Du dem DANE Validator > > entnehmen kannst: > > https://dane.sys4.de/smtp/posteo.de > > > > p at rick > > > > > > > >> > >> Gruß Daniel > >> -----Ursprüngliche Nachricht----- > >> Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter > >> Gesendet: Freitag, 22. Mai 2015 18:01 > >> An: postfixbuch-users at listen.jpberlin.de > >> Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > >> > >> * Daniel : > >>> Hi Patrick, > >>> > >>> denke der Fehler ist so schon korrekt mit untrustet, und mein Denkfehler war wohl in der schnelle, dass ich mein eigenes > >> Zertifikat > >>> angeben muss, und nicht mit dem vom Zielserver (Mailrelay) > >>> > >>> also lasse ich es wie es war. Würde der Mailserver direkt versenden, müsste ich wohl Path angeben, und für sämtliche Servern wie > >>> Telekom, Google, 1&1, GMX und co entsprechend dann hinterlegen in dem Ordner, oder? > >> > >> Genau. > >> > >> Wenn Du willst, dann kannst Du über smtp_tls_policy_maps das Zertifikat Deines > >> Relayserver pinnen (fingerprint). Dann gilt er als Verified. > >> > >> p at rick > >> > >> > >> > >>> > >>> Gruß Daniel > >>> > >>> -----Ursprüngliche Nachricht----- > >>> Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter > >>> Gesendet: Freitag, 22. Mai 2015 14:53 > >>> An: postfixbuch-users at listen.jpberlin.de > >>> Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > >>> > >>> * Daniel : > >>>> Hallo Patrick, > >>>> > >>>> danke für die Antwort, leider klappt es nicht., weiterhin untrustet zum externen Mailrelay. > >>>> > >>>> Ich habe probiert > >>>> smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt > >>> > >>> Das server-ca.crt weist wen aus? Ist das die CA mit der das Zertifikat des > >>> "externen Mailrelay" signiert wurde? > >>> > >>>> und dann noch > >>>> smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > >>>> smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > >>>> smtp_tls_CAfile = /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt > >>>> > >>>> Weitere Optionen mit smtp_ in der main.cf sind: > >>>> smtp_tls_security_level = may > >>>> smtp_tls_loglevel = 1 > >>>> smtp_tls_fingerprint_digest = sha1 > >>>> smtp_tls_note_starttls_offer = yes > >>>> smtp_host_lookup = dns, native > >>>> smtp_use_tls = yes > >>> > >>> Mach mal: > >>> > >>> openssl s_client -starttls smtp -CAfile /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt -connect $externesMailrelay:25 > >>> > >>> Und sende den output hier her. > >>> > >>> p at rick > >>> > >>> > >>> > >>> > >>>> > >>>> Gruß Daniel > >>>> > >>>> -----Ursprüngliche Nachricht----- > >>>> Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Patrick Ben Koetter > >>>> Gesendet: Freitag, 22. Mai 2015 13:27 > >>>> An: postfixbuch-users at listen.jpberlin.de > >>>> Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > >>>> > >>>> * Daniel : > >>>>> Guten Tag, > >>>>> > >>>>> ich habe ein ähnliches Anliegen. > >>>>> > >>>>> Im Maillog steht beim Versenden von Mails z.B.: > >>>>> postfix/smtp: Untrusted TLS connection established to mail.x.de[x.x.x.x]:587: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 > >>>>> (256/256 bits) > >>>>> > >>>>> Darauf hin habe ich habe ich mal main.cf geschaut nach dem in den Mail vom Werner bei den genannten Parameter. > >>>>> > >>>>> Dort habe ich nur gefunden: > >>>>> smtpd_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > >>>>> smtpd_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > >>>>> > >>>>> Dieses bezieht sich dann ja wohl nur für eingehende Verbindung, also müsste ich z.B. > >>>>> smtp_tls_cert_file = /var/packages/MailServer/target/etc/ssl/mailserver_ssl.pem > >>>>> smtp_tls_key_file = /usr/syno/etc/ssl/ssl.key/server.key > >>>>> > >>>>> hinzufügen damit auch für ausgehende Verbindung Zertifikat verwendet wird und das untrustet verschwindet? > >>>> > >>>> > >>>> Nein. Mit Deiner Änderung könnte der Postfix smtp-Client sich einem Server > >>>> gegenüber ausweisen, wenn > >>>> > >>>> - das Zertifikat für Client Usage geeignet ist > >>>> - der Server das Client-Zertifikat anfragt > >>>> > >>>> Du musst smtp_tls_CAfile setzen, damit der Client die Zertifikate anderer > >>>> SMTP-Server verifizieren kann, z.B.: > >>>> > >>>> smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt > >>>> > >>>> p at rick > >>>> > >>>> > >>>> > >>>>> > >>>>> Bin noch dabei mich mit ganzen Materie stärker vertraut zumachen. > >>>>> > >>>>> Gruß Daniel > >>>>> > >>>>> > >>>>> -----Ursprüngliche Nachricht----- > >>>>> Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Werner Flamme > >>>>> Gesendet: Freitag, 22. Mai 2015 07:53 > >>>>> An: postfixbuch-users at listen.jpberlin.de > >>>>> Betreff: Re: [Postfixbuch-users] Untrusted TLS connection mit eigener Root-CA unter SLES > >>>>> > >>>>> Roland Schnabel [21.05.2015 20:13]: > >>>>>> > >>>>>>> On 21.05.2015 12:29, Ralf Hansen wrote: > >>>>>>> > >>>>>>> Aber selbst bei Einrichtung eine Eintrages in /etc/hosts > >>>>>>> 10.100.120.251 interner-server.mein-netz.de > >>>>>>> > >>>>>>> und Nutzung von > >>>>>>> relayhost = interner-server.mein-netz.de > >>>>>>> > >>>>>>> erhalte ich eine Untrusted TLS connection? > >>>>>> > >>>>>> Postfix ignoriert /etc/hosts per Default: > >>>>>> smtp_host_lookup = dns > >>>>> > >>>>> Trusted oder nicht hat nichts mit DNS zu tun, sondern damit, ob die > >>>>> Zertifikatskette anerkannt wird. Das Root-Zertifikat der Kette sollte in > >>>>> dem Verzeichnis liegen, das mit smtp_tls_CApath definiert wird (für > >>>>> ausgehende Verbindungen; für eingehende ist es smtpd_tls_CApath). > >>>>> > >>>>> HDH, Werner > >>> > >>> > >>> -- > >>> _______________________________________________ > >>> Postfixbuch-users -- http://www.postfixbuch.de > >>> Heinlein Professional Linux Support GmbH > >>> > >>> Postfixbuch-users at listen.jpberlin.de > >>> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users > >> > >> -- > >> [*] sys4 AG > >> > >> https://sys4.de, +49 (89) 30 90 46 64 > >> Franziskanerstraße 15, 81669 München > >> > >> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 > >> Vorstand: Patrick Ben Koetter, Marc Schiffbauer > >> Aufsichtsratsvorsitzender: Florian Kirstein > >> > >> -- > >> _______________________________________________ > >> Postfixbuch-users -- http://www.postfixbuch.de > >> Heinlein Professional Linux Support GmbH > >> > >> Postfixbuch-users at listen.jpberlin.de > >> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users > >> > >> > >> -- > >> _______________________________________________ > >> Postfixbuch-users -- http://www.postfixbuch.de > >> Heinlein Professional Linux Support GmbH > >> > >> Postfixbuch-users at listen.jpberlin.de > >> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users > > > > -- > > [*] sys4 AG > > > > https://sys4.de, +49 (89) 30 90 46 64 > > Franziskanerstraße 15, 81669 München > > > > Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 > > Vorstand: Patrick Ben Koetter, Marc Schiffbauer > > Aufsichtsratsvorsitzender: Florian Kirstein > > > > -- > > _______________________________________________ > > Postfixbuch-users -- http://www.postfixbuch.de > > Heinlein Professional Linux Support GmbH > > > > Postfixbuch-users at listen.jpberlin.de > > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users > -- > _______________________________________________ > Postfixbuch-users -- http://www.postfixbuch.de > Heinlein Professional Linux Support GmbH > > Postfixbuch-users at listen.jpberlin.de > https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From t.maffert at owl3d.de Sat May 30 23:42:38 2015 From: t.maffert at owl3d.de (test) Date: Sat, 30 May 2015 23:42:38 +0200 Subject: [Postfixbuch-users] Exchange > Postfix Submission Port ... In-Reply-To: <5568DB5D.6020702@kdmails.de> References: <003501d09a37$0917d520$1b477f60$@owl3d.de> <004401d09a39$3f104a70$bd30df50$@owl3d.de> <5568C9F2.1000208@kdmails.de> <5568D155.4060806@owl3d.de> <5568DB5D.6020702@kdmails.de> Message-ID: <556A2ECE.1010904@owl3d.de> Achso, das heißt bei euch ist Dovecot o.ä. (zum authentifizieren) aktiv? Denn ich dachte mir das eigentlich so das der Postfix "Stumpf" die Mails von der Außenwelt entgegennimmt (filtert usw.) und diese an den Exchange weiterleitet. Umgekehrt natürlich auch so. Am 29.05.2015 um 23:34 schrieb Daniel Gompf: > > > Am 29.05.2015 um 22:51 schrieb test: >> Hallo, >> >> also in den Tests hat der Exchange Server via Port 25, ohne >> Authentifizierung, Postfix die Mails übergeben. Sprich in der Main.cf >> war die IP-Adresse vom Exchange Server drin, so das er die E-Mails >> von der IP entgegen nimmt. >> >> Der Abschnitt der main.cf sieht so aus: >> >> mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 >> ip.zu.meinem.exchange >> >> Da ich nun Amavis einsetze und die Geschichte über Port 587 >> (submission) laufen soll, funktioniert das durch die master.cf und >> meiner Konfiguration: >> >> submission inet n - - - - smtpd >> -o smtpd_tls_security_level=encrypt >> -o smtpd_sasl_auth_enable=yes >> -o smtpd_client_restrictions=permit_sasl_authenticated,reject >> -o smtpd_proxy_filter=localhost:10026 >> >> so nicht mehr. Ich könnte nun >> >> -o smtpd_client_restrictions=permit_mynetworks, >> permit_sasl_authenticated,reject >> >> verwenden nur wirklich gut/sicher ist das doch auch nicht oder? Ich >> weiß halt nicht wie man Exchange vernünftig bzw. sicher mit Postfix >> verknüpft bzw. verknüpfen sollte?! Wie macht ihr das denn? Oder wie >> würdet ihr das machen? > Wir lassen den Exchange auch auf 587 mit TLS einliefern, jedoch muss > der sich anmelden. Wir machen da keinen Unterschied zwischen einem > Exchange oder einem Nutzer der mit seinem MUA kommt. Wenn du das so > machen möchtest, muss dem Sende-Connector noch mitteilen, dass er sich > anmelden muss und TLS verwenden soll. > >> >> Es geht jetzt ausschließlich darum, das Exchange die Mails die an >> Extern geschickt werden, möglichst sicher an Postfix weiterleitet. >> Der Postfix Server selber, steht im Internet! ;) >> >> >> Am 29.05.2015 um 22:20 schrieb Daniel Gompf: >>> Hallo, >>> >>> meldet sich dein Exchange am Postfix an? Soll er sich anmelden? Ich >>> gehe davon aus, da du "-o >>> smtpd_client_restrictions=permit_sasl_authenticated,reject" drin >>> hast. Leider sieht man das aus den Logdaten nicht. >>> >>> Am 29.05.2015 um 19:59 schrieb Tobias Maffert: >>>> >>>> Ach ups, hier die Fehlermeldung die ich erhalte: >>>> >>>> May 29 19:54:01 mail postfix/smtpd[13709]: NOQUEUE: reject: RCPT >>>> from [ip.vom.exchange.server]: 554 5.7.1 >>>> : Client host >>>> rejected: Access denied; from= >>>> to= proto=ESMTP helo= >>>> >>>> May 29 19:54:02 mail postfix/smtpd[13709]: disconnect from >>>> ip.vom.exchange.server >>>> >>>> Exchange über Port 587 > Postfix normale mit Port 25 > in die weite >>>> E-Mail Welt ? ;D >>>> >>>> *Von:*Postfixbuch-users >>>> [mailto:postfixbuch-users-bounces at listen.jpberlin.de] *Im Auftrag >>>> von *Tobias Maffert >>>> *Gesendet:* Freitag, 29. Mai 2015 19:44 >>>> *An:* postfixbuch-users at listen.jpberlin.de >>>> *Betreff:* [Postfixbuch-users] Exchange > Postfix Submission Port ... >>>> >>>> Hallo zusammen :) >>>> >>>> Ich plane derzeit einen Exchange Server 2010 über Port 587 >>>> (Submission) via Smarthost mit meinem Postfix Server zu verbinden. >>>> >>>> Über Port 25 ist das kein Problem, das funktioniert. Da dieser aber >>>> gefiltert wird usw. soll Exchange über Port 587 die Mails >>>> reinschicken. Aber bei Port 587 habe ich irgendwie Probleme! >>>> >>>> Meine main.cf habe ich so angepasst, dass er die E-Mails von dem >>>> Exchange Server entgegennimmt: >>>> >>>> mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 >>>> ip.von.meinem.exchange >>>> >>>> Der submission Teil meiner master.cf schaut wie folgt aus: >>>> >>>> submission inet n - - - - smtpd >>>> >>>> -o smtpd_tls_security_level=encrypt >>>> >>>> -o smtpd_sasl_auth_enable=yes >>>> >>>> -o smtpd_client_restrictions=permit_sasl_authenticated,reject >>>> >>>> -o smtpd_proxy_filter=localhost:10026 >>>> >>>> Ich vermute das bei dem Submission Teil noch irgendwie etwas hin >>>> muss, das die IP vom Exchange expliziert erlaubt. Ist das richtig? >>>> Und wie müsste der ?Befehl? aussehen? >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> > > > > -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From tech at kdmails.de Sun May 31 00:06:00 2015 From: tech at kdmails.de (Daniel Gompf) Date: Sun, 31 May 2015 00:06:00 +0200 Subject: [Postfixbuch-users] Exchange > Postfix Submission Port ... In-Reply-To: <556A2ECE.1010904@owl3d.de> References: <003501d09a37$0917d520$1b477f60$@owl3d.de> <004401d09a39$3f104a70$bd30df50$@owl3d.de> <5568C9F2.1000208@kdmails.de> <5568D155.4060806@owl3d.de> <5568DB5D.6020702@kdmails.de> <556A2ECE.1010904@owl3d.de> Message-ID: <556A3448.2010502@kdmails.de> Am 30.05.2015 um 23:42 schrieb test: > Achso, das heißt bei euch ist Dovecot o.ä. (zum authentifizieren) aktiv? > > Denn ich dachte mir das eigentlich so das der Postfix "Stumpf" die > Mails von der Außenwelt entgegennimmt (filtert usw.) und diese an den > Exchange weiterleitet. Umgekehrt natürlich auch so. Das kommt darauf an wie der jeweilige Exchange läuft, läuft er "Authoritative/" /kannst du das so machen. Dann solltest du das einliefern aber mit "reject_unverified_recipient" vorher prüfen. Wenn dein Exchange aber in einem anderen Modus ist musst du wissen welche E-Mailadressen existieren, bei diesen Kunden haben wir dann Lookup-Tabellen. Ja zur Authentifizierung nutzen wir Dovecot. > > Am 29.05.2015 um 23:34 schrieb Daniel Gompf: >> >> >> Am 29.05.2015 um 22:51 schrieb test: >>> Hallo,// >>> >>> also in den Tests hat der Exchange Server via Port 25, ohne >>> Authentifizierung, Postfix die Mails übergeben. Sprich in der >>> Main.cf war die IP-Adresse vom Exchange Server drin, so das er die >>> E-Mails von der IP entgegen nimmt. >>> >>> Der Abschnitt der main.cf sieht so aus: >>> >>> mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 >>> ip.zu.meinem.exchange >>> >>> Da ich nun Amavis einsetze und die Geschichte über Port 587 >>> (submission) laufen soll, funktioniert das durch die master.cf und >>> meiner Konfiguration: >>> >>> submission inet n - - - - smtpd >>> -o smtpd_tls_security_level=encrypt >>> -o smtpd_sasl_auth_enable=yes >>> -o smtpd_client_restrictions=permit_sasl_authenticated,reject >>> -o smtpd_proxy_filter=localhost:10026 >>> >>> so nicht mehr. Ich könnte nun >>> >>> -o smtpd_client_restrictions=permit_mynetworks, >>> permit_sasl_authenticated,reject >>> >>> verwenden nur wirklich gut/sicher ist das doch auch nicht oder? Ich >>> weiß halt nicht wie man Exchange vernünftig bzw. sicher mit Postfix >>> verknüpft bzw. verknüpfen sollte?! Wie macht ihr das denn? Oder wie >>> würdet ihr das machen? >> Wir lassen den Exchange auch auf 587 mit TLS einliefern, jedoch muss >> der sich anmelden. Wir machen da keinen Unterschied zwischen einem >> Exchange oder einem Nutzer der mit seinem MUA kommt. Wenn du das so >> machen möchtest, muss dem Sende-Connector noch mitteilen, dass er >> sich anmelden muss und TLS verwenden soll. >> >>> >>> Es geht jetzt ausschließlich darum, das Exchange die Mails die an >>> Extern geschickt werden, möglichst sicher an Postfix weiterleitet. >>> Der Postfix Server selber, steht im Internet! ;) >>> >>> >>> Am 29.05.2015 um 22:20 schrieb Daniel Gompf: >>>> Hallo, >>>> >>>> meldet sich dein Exchange am Postfix an? Soll er sich anmelden? Ich >>>> gehe davon aus, da du "-o >>>> smtpd_client_restrictions=permit_sasl_authenticated,reject" drin >>>> hast. Leider sieht man das aus den Logdaten nicht. >>>> >>>> Am 29.05.2015 um 19:59 schrieb Tobias Maffert: >>>>> >>>>> Ach ups, hier die Fehlermeldung die ich erhalte: >>>>> >>>>> May 29 19:54:01 mail postfix/smtpd[13709]: NOQUEUE: reject: RCPT >>>>> from [ip.vom.exchange.server]: 554 5.7.1 >>>>> : Client host >>>>> rejected: Access denied; from= >>>>> to= proto=ESMTP helo= >>>>> >>>>> May 29 19:54:02 mail postfix/smtpd[13709]: disconnect from >>>>> ip.vom.exchange.server >>>>> >>>>> Exchange über Port 587 > Postfix normale mit Port 25 > in die >>>>> weite E-Mail Welt ? ;D >>>>> >>>>> *Von:*Postfixbuch-users >>>>> [mailto:postfixbuch-users-bounces at listen.jpberlin.de] *Im Auftrag >>>>> von *Tobias Maffert >>>>> *Gesendet:* Freitag, 29. Mai 2015 19:44 >>>>> *An:* postfixbuch-users at listen.jpberlin.de >>>>> *Betreff:* [Postfixbuch-users] Exchange > Postfix Submission Port ... >>>>> >>>>> Hallo zusammen :) >>>>> >>>>> Ich plane derzeit einen Exchange Server 2010 über Port 587 >>>>> (Submission) via Smarthost mit meinem Postfix Server zu verbinden. >>>>> >>>>> Über Port 25 ist das kein Problem, das funktioniert. Da dieser >>>>> aber gefiltert wird usw. soll Exchange über Port 587 die Mails >>>>> reinschicken. Aber bei Port 587 habe ich irgendwie Probleme! >>>>> >>>>> Meine main.cf habe ich so angepasst, dass er die E-Mails von dem >>>>> Exchange Server entgegennimmt: >>>>> >>>>> mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 >>>>> ip.von.meinem.exchange >>>>> >>>>> Der submission Teil meiner master.cf schaut wie folgt aus: >>>>> >>>>> submission inet n - - - - smtpd >>>>> >>>>> -o smtpd_tls_security_level=encrypt >>>>> >>>>> -o smtpd_sasl_auth_enable=yes >>>>> >>>>> -o smtpd_client_restrictions=permit_sasl_authenticated,reject >>>>> >>>>> -o smtpd_proxy_filter=localhost:10026 >>>>> >>>>> Ich vermute das bei dem Submission Teil noch irgendwie etwas hin >>>>> muss, das die IP vom Exchange expliziert erlaubt. Ist das richtig? >>>>> Und wie müsste der ?Befehl? aussehen? >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> >> > > > -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: