From mailinglists at qutic.com Fri Oct 5 10:49:58 2018 From: mailinglists at qutic.com (qutic development) Date: Fri, 5 Oct 2018 10:49:58 +0200 Subject: =?utf-8?Q?Re=3A_Aktuelle_pattern_f=C3=BCr_logstash?= In-Reply-To: References: Message-ID: > hat jemand von den hochgeschätzten Herren aktuelle grok-pattern für logstash? Läuft bei uns mit Postfix 3.3.x, Amavisd 2.11.0. HTH: https://gist.github.com/jfqd/69713ae9c0c20e47fec900e1ab18fb6d Änderungen gerne als Kommentar im Gist. Gruß, Stefan From Hajo.Locke at gmx.de Mon Oct 8 09:47:17 2018 From: Hajo.Locke at gmx.de (Hajo Locke) Date: Mon, 8 Oct 2018 09:47:17 +0200 Subject: NiX Spam - Abfragelimits Message-ID: <718afdd4-c074-6fb7-820e-13f502f69b0e@gmx.de> Hallo Liste, es gibt RBLs wie Spamhaus die Abfragen im geringen Umfang kostenfrei zulassen und bei größeren Abfragemengen dann eine Gebühr verlangen. Mich würde das interessieren, wie sich das bei ix.dnsbl.manitu.net verhält. Auf den offiziellen Seiten konnte ich dazu nichts finden. Weiß das jemand? Danke, Hajo From Ralf.Hildebrandt at charite.de Mon Oct 8 13:28:35 2018 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Mon, 8 Oct 2018 13:28:35 +0200 Subject: [ext] NiX Spam - Abfragelimits In-Reply-To: <718afdd4-c074-6fb7-820e-13f502f69b0e@gmx.de> References: <718afdd4-c074-6fb7-820e-13f502f69b0e@gmx.de> Message-ID: <20181008112835.GC30632@charite.de> * Hajo Locke : > Hallo Liste, > > es gibt RBLs wie Spamhaus die Abfragen im geringen Umfang kostenfrei > zulassen und bei größeren Abfragemengen dann eine Gebühr verlangen. > Mich würde das interessieren, wie sich das bei ix.dnsbl.manitu.net verhält. > Auf den offiziellen Seiten konnte ich dazu nichts finden. > Weiß das jemand? Aktuell scheinen die keine Limits zu haben, allerdings kenne ich mind. zwei größere Betreiber von Mailservern, die "abuse" Mails bekommen haben - weil angeblich der abfragende Mailserver eine DNS amplification attack macht (was nicht der Fall ist). -- 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 | https://www.charite.de From Hajo.Locke at gmx.de Mon Oct 8 13:51:37 2018 From: Hajo.Locke at gmx.de (Hajo Locke) Date: Mon, 8 Oct 2018 13:51:37 +0200 Subject: [ext] NiX Spam - Abfragelimits In-Reply-To: <20181008112835.GC30632@charite.de> References: <718afdd4-c074-6fb7-820e-13f502f69b0e@gmx.de> <20181008112835.GC30632@charite.de> Message-ID: <01eac9be-b5e2-260e-aad0-4d08da1af194@gmx.de> Hallo, Am 08.10.2018 um 13:28 schrieb Ralf Hildebrandt: > * Hajo Locke : >> Hallo Liste, >> >> es gibt RBLs wie Spamhaus die Abfragen im geringen Umfang kostenfrei >> zulassen und bei größeren Abfragemengen dann eine Gebühr verlangen. >> Mich würde das interessieren, wie sich das bei ix.dnsbl.manitu.net verhält. >> Auf den offiziellen Seiten konnte ich dazu nichts finden. >> Weiß das jemand? > Aktuell scheinen die keine Limits zu haben, allerdings kenne ich mind. > zwei größere Betreiber von Mailservern, die "abuse" Mails bekommen > haben - weil angeblich der abfragende Mailserver eine DNS > amplification attack macht (was nicht der Fall ist). > Vielleicht frag ich direkt mal bei Herrn Ungerer nach. Ich möchte nicht erst in irgendwelche Probleme laufen. Die Mail zur amplification attack haben wir auch, wird von einem Kollegen untersucht, der bei uns erst mal keine der geschilderten Vorgänge finden konnte. Bist du auch betroffen? Wenn mehrere Betreiber solche Mails erhalten vermute ich da eher einen Irrtum als einen Angriff von mehreren unabhängigen Betreibern. Danke, Hajo From Ralf.Hildebrandt at charite.de Mon Oct 8 14:07:52 2018 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Mon, 8 Oct 2018 14:07:52 +0200 Subject: [ext] NiX Spam - Abfragelimits In-Reply-To: <01eac9be-b5e2-260e-aad0-4d08da1af194@gmx.de> References: <718afdd4-c074-6fb7-820e-13f502f69b0e@gmx.de> <20181008112835.GC30632@charite.de> <01eac9be-b5e2-260e-aad0-4d08da1af194@gmx.de> Message-ID: <20181008120751.GC32125@charite.de> * Hajo Locke : > Vielleicht frag ich direkt mal bei Herrn Ungerer nach. Ich möchte nicht erst > in irgendwelche Probleme laufen. > Die Mail zur amplification attack haben wir auch, wird von einem Kollegen > untersucht, der bei uns erst mal keine der geschilderten Vorgänge finden > konnte. Wie hier. > Bist du auch betroffen? Ja > Wenn mehrere Betreiber solche Mails erhalten vermute ich da eher einen > Irrtum als einen Angriff von mehreren unabhängigen Betreibern. Denke auch Irrtum -- 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 | https://www.charite.de From debian at slashproc.org Mon Oct 8 17:09:54 2018 From: debian at slashproc.org (Manfred Schmitt) Date: Mon, 8 Oct 2018 17:09:54 +0200 Subject: [ext] NiX Spam - Abfragelimits In-Reply-To: <01eac9be-b5e2-260e-aad0-4d08da1af194@gmx.de> References: <718afdd4-c074-6fb7-820e-13f502f69b0e@gmx.de> <20181008112835.GC30632@charite.de> <01eac9be-b5e2-260e-aad0-4d08da1af194@gmx.de> Message-ID: <20181008170954.633907d4.debian@slashproc.org> Hajo Locke schrieb: > > Aktuell scheinen die keine Limits zu haben, allerdings kenne ich mind. > > zwei größere Betreiber von Mailservern, die "abuse" Mails bekommen > > haben - weil angeblich der abfragende Mailserver eine DNS > > amplification attack macht (was nicht der Fall ist). > > Ich hab die Abuse-Mail von Manitu vor ein Paar Tagen, auf einem wenig frequentiertem Server bei Hetzner, auch gekriegt. Und ich konnte das ebenso nicht nachvollziehen, imo klar False Positive. Hab nun die NixSpam-RBL erst einmal aus postfix rausgenommen. Und wech, Manne From ml at andreas-ziegler.de Mon Oct 8 20:10:23 2018 From: ml at andreas-ziegler.de (Andreas Ziegler) Date: Mon, 8 Oct 2018 20:10:23 +0200 Subject: [ext] NiX Spam - Abfragelimits In-Reply-To: <20181008170954.633907d4.debian@slashproc.org> References: <718afdd4-c074-6fb7-820e-13f502f69b0e@gmx.de> <20181008112835.GC30632@charite.de> <01eac9be-b5e2-260e-aad0-4d08da1af194@gmx.de> <20181008170954.633907d4.debian@slashproc.org> Message-ID: <546073b7-4933-5380-74cc-0209fecfa71a@andreas-ziegler.de> Manfred Schmitt schrieb am 08.10.18 um 17:09: > Hajo Locke schrieb: > >>> Aktuell scheinen die keine Limits zu haben, allerdings kenne ich mind. >>> zwei größere Betreiber von Mailservern, die "abuse" Mails bekommen >>> haben - weil angeblich der abfragende Mailserver eine DNS >>> amplification attack macht (was nicht der Fall ist). >>> > Ich hab die Abuse-Mail von Manitu vor ein Paar Tagen, auf einem wenig > frequentiertem Server bei Hetzner, auch gekriegt. > Und ich konnte das ebenso nicht nachvollziehen, imo klar False Positive. dito, mehrere Server, alles false positive. From mailinglisten at pothe.de Tue Oct 9 16:53:27 2018 From: mailinglisten at pothe.de (Andreas Pothe) Date: Tue, 9 Oct 2018 16:53:27 +0200 Subject: Office 365 - bin ich doof oder Microsoft? Message-ID: <8218d4d4-0109-35ff-a95d-7f73fd9cba44@pothe.de> Hi, aus irgendeinem Grund meint Microsoft, seinen Office 365-Usern keine Mails von meinem Mailserver zumuten zu müssen. Vermutlich blocken die mal wieder alle Hetzner-Server (oder zumindest Ranges) und meiner ist ein Kollateralschaden, mein Mailserver steht auf keiner öffentlich abfragbaren Blacklist (wenn ich multirbl.valli.org vertrauen darf). > host > jensmuellergmbh-de01b1b.mail.protection.outlook.de[51.5.80.10] said: 550 > 5.7.606 Access denied, banned sending IP [94.130.180.65]. To request > removal from this list please visit https://sender.office.com/ and follow > the directions. For more information please go to > http://go.microsoft.com/fwlink/?LinkID=526655 (AS16012609) (in reply to > RCPT TO command) Gut, also gehe ich auf https://sender.office.com und mache das Spielchen mit. Allerdings habe ich bislang keine E-Mail bekommen... Mein Mailserver lehnt die Mail nämlich ab, aufgrund der DMARC-Policy von Microsoft: > postfix/postscreen[25175]: CONNECT from [52.100.135.97]:40264 to > [94.130.180.65]:25 > postfix/dnsblog[25177]: addr 52.100.135.97 listed by domain > list.dnswl.org as 127.0.3.0 > postfix/postscreen[25175]: PASS NEW [52.100.135.97]:40264 > postfix/smtpd[25184]: connect from > mail-bgr052100135097.outbound.protection.outlook.com[52.100.135.97] > postfix/smtpd[25184]: Anonymous TLS connection established from > mail-bgr052100135097.outbound.protection.outlook.com[52.100.135.97]: > TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits) > postfix/smtpd[25184]: 018DE1F48D: > client=mail-bgr052100135097.outbound.protection.outlook.com[52.100.135.97] > postfix/cleanup[25146]: 018DE1F48D: > message-id= > opendkim[3134]: 018DE1F48D: > mail-bgr052100135097.outbound.protection.outlook.com [52.100.135.97] > not internal > opendkim[3134]: 018DE1F48D: not authenticated > opendkim[3134]: 018DE1F48D: failed to parse Authentication-Results: > header field > opendkim[3134]: 018DE1F48D: no signature data > opendmarc[3117]: 018DE1F48D: microsoft.com fail > postfix/cleanup[25146]: 018DE1F48D: milter-reject: END-OF-MESSAGE from > mail-bgr052100135097.outbound.protection.outlook.com[52.100.135.97]: > 5.7.1 rejected by DMARC policy for microsoft.com; > from= to= > proto=ESMTP helo= > postfix/smtpd[25184]: disconnect from > mail-bgr052100135097.outbound.protection.outlook.com[52.100.135.97] > ehlo=2 starttls=1 mail=1 rcpt=1 data=0/1 quit=1 commands=6/7 DNS-Abfrage: $ dig _dmarc.microsoft.com txt +short "v=DMARC1; p=reject; pct=100; rua=mailto:d at rua.agari.com; ruf=mailto:d at ruf.agari.com; fo=1" $ dig microsoft.com txt +short "v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com include:spf-a.hotmail.com ip4:147.243.128.24 ip4:147.243.128.26 ip4:147.243.1.153 ip4:147.243.1.47 ip4:147.243.1.48 -all" $ dig _spf-a.microsoft.com txt +short "v=spf1 ip4:216.99.5.67 ip4:216.99.5.68 ip4:202.177.148.100 ip4:203.122.32.250 ip4:202.177.148.110 ip4:213.199.128.139 ip4:213.199.128.145 ip4:207.46.50.72 ip4:207.46.50.82 ip4:65.55.42.224/28 include:spf.protection.outlook.com ~all" $ dig spf.protection.outlook.com txt +short "v=spf1 ip4:207.46.100.0/24 ip4:207.46.163.0/24 ip4:65.55.169.0/24 ip4:157.56.110.0/23 ip4:157.55.234.0/24 ip4:213.199.154.0/24 ip4:213.199.180.128/26 ip4:52.100.0.0/14 include:spfa.protection.outlook.com -all" So, und da steckt mit ip4:52.100.0.0/14 der Absender-Server drin, d. h. die Mail müsste angenommen werden. Kann opendkim keine verschachtelten Includes bei SPF? Oder habe ich eine fehlerhafte Konfiguration? Oder verstößt Microsoft mit den mehrfachen Verschachtelungen gegen die Standards? Oder wo liegt sonst der Fehler? Wie würdet Ihr damit umgehen? Mir ist es schon recht wichtig, dass ich auch dahin Mails loswerde, wenngleich ich das Problem jetzt erstmals hatte, also scheinbar nur wenige Leute den kack Microsoft-Office365-Service nutzen (witzigerweise ist eine Zustellung an hotmail.com oder outlook.com kein Problem). Beste Grüße Andreas From andre.peters at debinux.de Tue Oct 9 17:53:49 2018 From: andre.peters at debinux.de (=?utf-8?q?Andr=C3=A9?= Peters) Date: Tue, 9 Oct 2018 17:53:49 +0200 Subject: Office 365 - bin ich doof oder Microsoft? In-Reply-To: <8218d4d4-0109-35ff-a95d-7f73fd9cba44@pothe.de> References: <8218d4d4-0109-35ff-a95d-7f73fd9cba44@pothe.de> Message-ID: <57FB294F-E7F1-494E-A2B9-73956FE51488@debinux.de> Hetzner, OVH, Online.net und Co. sind auch einfach übel für Mailing. Ich score neue Domains aus den ASNs auch etwas höher. Glaube das OVH Netz kann man heute komplett knicken. Dazu kommt, dass die Hetzner Netze nun auch größtenteils für DNSBL blockiert/ratelimited sind. > Am 09.10.2018 um 16:53 schrieb Andreas Pothe : > > Hi, > > aus irgendeinem Grund meint Microsoft, seinen Office 365-Usern keine > Mails von meinem Mailserver zumuten zu müssen. Vermutlich blocken die > mal wieder alle Hetzner-Server (oder zumindest Ranges) und meiner ist > ein Kollateralschaden, mein Mailserver steht auf keiner öffentlich > abfragbaren Blacklist (wenn ich multirbl.valli.org vertrauen darf). > >> host >> jensmuellergmbh-de01b1b.mail.protection.outlook.de[51.5.80.10] said: 550 >> 5.7.606 Access denied, banned sending IP [94.130.180.65]. To request >> removal from this list please visit https://sender.office.com/ and follow >> the directions. For more information please go to >> http://go.microsoft.com/fwlink/?LinkID=526655 (AS16012609) (in reply to >> RCPT TO command) > > Gut, also gehe ich auf https://sender.office.com und mache das Spielchen > mit. Allerdings habe ich bislang keine E-Mail bekommen... Mein > Mailserver lehnt die Mail nämlich ab, aufgrund der DMARC-Policy von > Microsoft: > >> postfix/postscreen[25175]: CONNECT from [52.100.135.97]:40264 to >> [94.130.180.65]:25 >> postfix/dnsblog[25177]: addr 52.100.135.97 listed by domain >> list.dnswl.org as 127.0.3.0 >> postfix/postscreen[25175]: PASS NEW [52.100.135.97]:40264 >> postfix/smtpd[25184]: connect from >> mail-bgr052100135097.outbound.protection.outlook.com[52.100.135.97] >> postfix/smtpd[25184]: Anonymous TLS connection established from >> mail-bgr052100135097.outbound.protection.outlook.com[52.100.135.97]: >> TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits) >> postfix/smtpd[25184]: 018DE1F48D: >> client=mail-bgr052100135097.outbound.protection.outlook.com[52.100.135.97] >> postfix/cleanup[25146]: 018DE1F48D: >> message-id= >> opendkim[3134]: 018DE1F48D: >> mail-bgr052100135097.outbound.protection.outlook.com [52.100.135.97] >> not internal >> opendkim[3134]: 018DE1F48D: not authenticated >> opendkim[3134]: 018DE1F48D: failed to parse Authentication-Results: >> header field >> opendkim[3134]: 018DE1F48D: no signature data >> opendmarc[3117]: 018DE1F48D: microsoft.com fail >> postfix/cleanup[25146]: 018DE1F48D: milter-reject: END-OF-MESSAGE from >> mail-bgr052100135097.outbound.protection.outlook.com[52.100.135.97]: >> 5.7.1 rejected by DMARC policy for microsoft.com; >> from= to= >> proto=ESMTP helo= >> postfix/smtpd[25184]: disconnect from >> mail-bgr052100135097.outbound.protection.outlook.com[52.100.135.97] >> ehlo=2 starttls=1 mail=1 rcpt=1 data=0/1 quit=1 commands=6/7 > > DNS-Abfrage: > > $ dig _dmarc.microsoft.com txt +short > "v=DMARC1; p=reject; pct=100; rua=mailto:d at rua.agari.com; > ruf=mailto:d at ruf.agari.com; fo=1" > > $ dig microsoft.com txt +short > "v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com > include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com > include:spf-a.hotmail.com ip4:147.243.128.24 ip4:147.243.128.26 > ip4:147.243.1.153 ip4:147.243.1.47 ip4:147.243.1.48 -all" > > $ dig _spf-a.microsoft.com txt +short > "v=spf1 ip4:216.99.5.67 ip4:216.99.5.68 ip4:202.177.148.100 > ip4:203.122.32.250 ip4:202.177.148.110 ip4:213.199.128.139 > ip4:213.199.128.145 ip4:207.46.50.72 ip4:207.46.50.82 > ip4:65.55.42.224/28 include:spf.protection.outlook.com ~all" > > $ dig spf.protection.outlook.com txt +short > "v=spf1 ip4:207.46.100.0/24 ip4:207.46.163.0/24 ip4:65.55.169.0/24 > ip4:157.56.110.0/23 ip4:157.55.234.0/24 ip4:213.199.154.0/24 > ip4:213.199.180.128/26 ip4:52.100.0.0/14 > include:spfa.protection.outlook.com -all" > > So, und da steckt mit ip4:52.100.0.0/14 der Absender-Server drin, d. h. > die Mail müsste angenommen werden. > > Kann opendkim keine verschachtelten Includes bei SPF? Oder habe ich eine > fehlerhafte Konfiguration? Oder verstößt Microsoft mit den mehrfachen > Verschachtelungen gegen die Standards? Oder wo liegt sonst der Fehler? > Wie würdet Ihr damit umgehen? > > Mir ist es schon recht wichtig, dass ich auch dahin Mails loswerde, > wenngleich ich das Problem jetzt erstmals hatte, also scheinbar nur > wenige Leute den kack Microsoft-Office365-Service nutzen (witzigerweise > ist eine Zustellung an hotmail.com oder outlook.com kein Problem). > > Beste Grüße > Andreas > From driessen at fblan.de Tue Oct 9 21:40:36 2018 From: driessen at fblan.de (=?utf-8?Q?Uwe_Drie=C3=9Fen?=) Date: Tue, 9 Oct 2018 21:40:36 +0200 Subject: AW: Office 365 - bin ich doof oder Microsoft? In-Reply-To: <57FB294F-E7F1-494E-A2B9-73956FE51488@debinux.de> References: <8218d4d4-0109-35ff-a95d-7f73fd9cba44@pothe.de> <57FB294F-E7F1-494E-A2B9-73956FE51488@debinux.de> Message-ID: <007901d46007$f486f5b0$dd94e110$@fblan.de> Im Auftrag von André Peters > > Hetzner, OVH, Online.net und Co. sind auch einfach übel für Mailing. Ich > score neue Domains aus den ASNs auch etwas höher. Das ist glaube ich auch Kein Problem die sperren einfach mit der Großen Kelle ganze Rechenzentren wenn es Ihnen nicht passt. Da kommt aus einem /20 ein paar mehr spam mails dann ist das ganze /20 gesperrt wobei es nur 3 oder 8 IP aus dem Bereich auffällig sind. > > Glaube das OVH Netz kann man heute komplett knicken. > > Dazu kommt, dass die Hetzner Netze nun auch größtenteils für DNSBL > blockiert/ratelimited sind. Bei 5 Mails pro Minute pro IP sollte kein normaler Mailserver die Grenze sprengen. Einige dieser großen Empfänger domains hab ich eingestellt das da nur 10 Mails pro Min gleichzeitig rausgehen da bleibt das ganze dann unter dem Radar > Ganz so schlimm ist das nicht :-) Ich hab ne pöse Mail an MS geschickt und gefragt was das soll das ich bei 20 Mail am Tag an die auf einer Blacklist stehe Ob sie das nicht gebacken bekommen ohne blind immer alle möglichen Netze zu sperren für die es keinen Grund gibt Hat keine 5 Stunden bis zur Freischaltung gedauert mit entsprechender Entschuldigung. Ich kann dir allerdings nicht mehr sagen überwelchen Weg ob Webseite oder Mailadresse ich hatte mir das aus google gefischt Ansonsten kann ich eh keinem MS empfehlen der wirklich Mail geschäftlich benötigt. es gibt bessere, günstigere Alternativen, mit weniger Problemen :-) ) MS bekommt seit 10 Jahren kein Greylisting hin bzw. kann immer noch nicht mit umgehen und erzählen Ihren Kunden es wäre veraltete Technik. Andere mit ebenfalls MIO an Mailkunden können es auch. Mit freundlichen Grüßen Uwe Drießen -- Software & Computer Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner ! Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: 06708660045 From andre.peters at debinux.de Tue Oct 9 21:53:13 2018 From: andre.peters at debinux.de (=?UTF-8?Q?Andr=c3=a9_Peters?=) Date: Tue, 9 Oct 2018 21:53:13 +0200 Subject: Office 365 - bin ich doof oder Microsoft? In-Reply-To: <007901d46007$f486f5b0$dd94e110$@fblan.de> References: <8218d4d4-0109-35ff-a95d-7f73fd9cba44@pothe.de> <57FB294F-E7F1-494E-A2B9-73956FE51488@debinux.de> <007901d46007$f486f5b0$dd94e110$@fblan.de> Message-ID: <63234ad1-7634-fec2-1b4b-3ba79431457f@debinux.de> Am 09.10.2018 um 21:40 schrieb Uwe Drießen: > Das ist glaube ich auch Kein Problem die sperren einfach mit der Großen Kelle ganze Rechenzentren wenn es Ihnen nicht passt. > Da kommt aus einem /20 ein paar mehr spam mails dann ist das ganze /20 gesperrt wobei es nur 3 oder 8 IP aus dem Bereich auffällig sind. Najo, die (virtuellen) Server sind meist nur kurz angemietet, die IPs wechseln sehr häufig die "Mieter", das kann ich denen nicht verübeln. Besonders dann, wenn wieder eine Welle PKV Spam rumgeht. > Bei 5 Mails pro Minute pro IP sollte kein normaler Mailserver die Grenze sprengen. > Einige dieser großen Empfänger domains hab ich eingestellt das da nur 10 Mails pro Min gleichzeitig rausgehen da bleibt das ganze dann unter dem Radar Ich meine nur die Blacklist Lookups, da kann schon was zusammenkommen. Aber da bin ich nicht im Thema. > Ganz so schlimm ist das nicht :-) > Ich hab ne pöse Mail an MS geschickt und gefragt was das soll das ich bei 20 Mail am Tag an die auf einer Blacklist stehe > Ob sie das nicht gebacken bekommen ohne blind immer alle möglichen Netze zu sperren für die es keinen Grund gibt > Hat keine 5 Stunden bis zur Freischaltung gedauert mit entsprechender Entschuldigung. Das ist sehr, sehr mutig, eine _böse_ Mail zu senden. Sie schulden dir nichts und im schlimmsten Fall kooperieren sie nicht. :-/ Ich bekomme von OVH und Hetzner relativ viel Spam - von Hetzner zwar eher weniger, aber auch etwas mehr als üblich (der Grund ist natürlich nachvollziehbar bei der Größe). Das Risiko der schlechten Reputation nimmt man da einfach mit. Ich kann es wie gesagt leider nachvollziehen. Gerade bei Spamwellen würde ich auch am liebsten temporär die Netze weiter abwerten. > Ich kann dir allerdings nicht mehr sagen überwelchen Weg ob Webseite oder Mailadresse ich hatte mir das aus google gefischt > > Ansonsten kann ich eh keinem MS empfehlen der wirklich Mail geschäftlich benötigt. > es gibt bessere, günstigere Alternativen, mit weniger Problemen :-) ) > > > MS bekommt seit 10 Jahren kein Greylisting hin bzw. kann immer noch nicht mit umgehen und erzählen Ihren Kunden es wäre veraltete Technik. > Andere mit ebenfalls MIO an Mailkunden können es auch. Habe mit denen schon länger nichts mehr am Hut, kann ich nicht beurteilen. :-) Viele Grüße André > > Mit freundlichen Grüßen > > Uwe Drießen > -- > Software & Computer > > Netzwerke, Server. > Wir vernetzen Sie und Ihre Rechner ! > > Uwe Drießen > Lembergstraße 33 > 67824 Feilbingert > > Tel.: 06708660045 > From driessen at fblan.de Wed Oct 10 10:03:39 2018 From: driessen at fblan.de (=?utf-8?Q?Uwe_Drie=C3=9Fen?=) Date: Wed, 10 Oct 2018 10:03:39 +0200 Subject: AW: Office 365 - bin ich doof oder Microsoft? In-Reply-To: <63234ad1-7634-fec2-1b4b-3ba79431457f@debinux.de> References: <8218d4d4-0109-35ff-a95d-7f73fd9cba44@pothe.de> <57FB294F-E7F1-494E-A2B9-73956FE51488@debinux.de> <007901d46007$f486f5b0$dd94e110$@fblan.de> <63234ad1-7634-fec2-1b4b-3ba79431457f@debinux.de> Message-ID: <008d01d4606f$c37a1020$4a6e3060$@fblan.de> Im Auftrag von André Peters > > > Das ist sehr, sehr mutig, eine _böse_ Mail zu senden. Sie schulden dir > nichts und im schlimmsten Fall kooperieren sie nicht. :-/ Das hat nichts mit Mutig zu tun. Im Zweifel ist das unbegründete Behinderung im Geschäftsverkehr und üble Nachrede da die Meldung behauptet man sei Spammer und das geht an die Endkunden (Dritte). Sippenhaft gibt es nicht mehr. Und es ist mit der heutigen Technik und Tools KEIN Problem die einzelnen IP's (sogar Zeitabhängig) zu sperren OHNE ganzen Rechenzentren vom normalen Mailverkehr grundlos auszuschließen. Ich bekomme den meisten Spam von eben genau denen die da immer mit der großen Kelle .... Und das sie es auch anders können zeigt es eben das sie selektiv auch freischalten können .... > > Ich bekomme von OVH und Hetzner relativ viel Spam - von Hetzner zwar > eher weniger, aber auch etwas mehr als üblich (der Grund ist natürlich > nachvollziehbar bei der Größe). Das Risiko der schlechten Reputation > nimmt man da einfach mit. Ich kann es wie gesagt leider nachvollziehen. > Gerade bei Spamwellen würde ich auch am liebsten temporär die Netze > weiter abwerten. Fail2ban und IPset und alle sind glücklich 3. Spam 24 Stunden Block genau der Verursacher IP. Gibt dem Serverinhaber die Zeit zu reagieren oder Hetzner die Möglichkeit entsprechend einzugreifen Und Hetzner geht jeder Abuse zeitnah nach (zumindest ist meine Erfahrung so) > > Viele Grüße > André > Mit freundlichen Grüßen Uwe Drießen -- Software & Computer Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner ! Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: 06708660045 From p.heinlein at heinlein-support.de Thu Oct 11 09:34:36 2018 From: p.heinlein at heinlein-support.de (Peer Heinlein) Date: Thu, 11 Oct 2018 09:34:36 +0200 Subject: Heute ist DNSSEC-Day In-Reply-To: <9cede438-b97c-2a2c-8496-5aa38199ce1c@heinlein-support.de> References: <9cede438-b97c-2a2c-8496-5aa38199ce1c@heinlein-support.de> Message-ID: <770f8a6d-5369-a983-76a6-362c47cbe2ec@heinlein-support.de> Hallo, liebe Leute. Bitte denkt dran: Heute ist DNSSEC-Day, d.h. in der Root-Serverzone wird der DNSSEC-Schlüssel getauscht. Uralte DNS-Server, die nie ein Config-Update erfahren haben, kennen den seit vor einigen Jahren publizierten neuen DNSSEC-Schlüssel ggf. noch nicht. Dabei muß auch bedacht werden, daß in Router- oder DSL-Boxen und anderen Geräten ggf. veraltete Resolver embedded mit installiert sein könnten. 2017 sollte der Schlüsseltausch schon einmal stattfinden und wurde aufgrund der hohen Verbreitung alter Resolver abgeblasen... Wann immer es heute zu DNS-bezogenen Schwierigkeiten im Netz kommt, sollte an den DNSSEC-Change gedacht werden. Dazu gehören allgemein individuelle Nicht-Erreichbarkeiten von Webseiten und Mailadressen. Schuld ist in dem Fall dann jeweils der lokale (veraltete) Resolver des Nutzers, der die Webseite nicht aufrufen kann, bzw. des Providers, der die Mails an DNSSEC-Domains nicht mehr senden kann. Grundsätzlich bringen aktuelle BIND-VErsionen 9.11 die neuen Keys mit. Bei älteren Versionen müßten Keys ggf. eingespielt werden. Prüfen kann man seinen lokalen Bind auch durch einen Blick in die Config. Idealerweise existiert eine Datei bind.keys, die auch den neuen Key beinhaltet: # This key (20326) is to be published in the root zone in 2017. # Servers which were already using the old key (19036) should # roll seamlessly to this new one via RFC 5011 rollover. Servers # being set up for the first time can use the contents of this # file as initializing keys; thereafter, the keys in the # managed key database will be trusted and maintained # automatically. . initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU="; 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 Ralf.Hildebrandt at charite.de Thu Oct 11 10:27:04 2018 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Thu, 11 Oct 2018 10:27:04 +0200 Subject: [ext] Heute ist DNSSEC-Day In-Reply-To: <770f8a6d-5369-a983-76a6-362c47cbe2ec@heinlein-support.de> References: <9cede438-b97c-2a2c-8496-5aa38199ce1c@heinlein-support.de> <770f8a6d-5369-a983-76a6-362c47cbe2ec@heinlein-support.de> Message-ID: <20181011082704.GA30312@charite.de> > Schuld ist in dem Fall dann jeweils der lokale (veraltete) Resolver des > Nutzers, der die Webseite nicht aufrufen kann, bzw. des Providers, der > die Mails an DNSSEC-Domains nicht mehr senden kann. https://www.icann.org/dns-resolvers-checking-current-trust-anchors beschreibt für BIND, unbound PowerDNS Recursor, Knot u.v.a.m. wie man prüfen kann. -- 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 | https://www.charite.de From lt-cmd.data at gmx.de Thu Oct 11 10:39:48 2018 From: lt-cmd.data at gmx.de (Lieutenat-Commander DATA) Date: Thu, 11 Oct 2018 10:39:48 +0200 Subject: Heute ist DNSSEC-Day In-Reply-To: <770f8a6d-5369-a983-76a6-362c47cbe2ec@heinlein-support.de> References: <9cede438-b97c-2a2c-8496-5aa38199ce1c@heinlein-support.de> <770f8a6d-5369-a983-76a6-362c47cbe2ec@heinlein-support.de> Message-ID: <21049e94-f68e-2c59-4dad-ab2b8585041c@gmx.de> Hallo zusammen, ich habe noch nen älteren Bind 9.8.4, und habe versucht diesem ein Update zu geben, indem ich ihm die Konfig "dnssec-validation auto;" verpasst habe. Im Log stand nach einem Neustart des Bind dann auch: *** managed-keys-zone ./IN: Initializing automatic trust anchor management for zone '.'; DNSKEY ID 20326 is now trusted, waiving the normal 30-day waiting period. *** In der bind.keys hat sich aber nichts geändert. Ist das nun trotzdem aktualisiert, oder besteht noch Handlungsbedarf? Gruß, DATA Am 11.10.2018 um 09:34 schrieb Peer Heinlein: > > Hallo, liebe Leute. > > Bitte denkt dran: Heute ist DNSSEC-Day, d.h. in der Root-Serverzone wird > der DNSSEC-Schlüssel getauscht. > > Uralte DNS-Server, die nie ein Config-Update erfahren haben, kennen den > seit vor einigen Jahren publizierten neuen DNSSEC-Schlüssel ggf. noch nicht. > > Dabei muß auch bedacht werden, daß in Router- oder DSL-Boxen und anderen > Geräten ggf. veraltete Resolver embedded mit installiert sein könnten. > > 2017 sollte der Schlüsseltausch schon einmal stattfinden und wurde > aufgrund der hohen Verbreitung alter Resolver abgeblasen... > > Wann immer es heute zu DNS-bezogenen Schwierigkeiten im Netz kommt, > sollte an den DNSSEC-Change gedacht werden. Dazu gehören allgemein > individuelle Nicht-Erreichbarkeiten von Webseiten und Mailadressen. > > Schuld ist in dem Fall dann jeweils der lokale (veraltete) Resolver des > Nutzers, der die Webseite nicht aufrufen kann, bzw. des Providers, der > die Mails an DNSSEC-Domains nicht mehr senden kann. > > Grundsätzlich bringen aktuelle BIND-VErsionen 9.11 die neuen Keys mit. > Bei älteren Versionen müßten Keys ggf. eingespielt werden. Prüfen kann > man seinen lokalen Bind auch durch einen Blick in die Config. > Idealerweise existiert eine Datei bind.keys, die auch den neuen Key > beinhaltet: > > # This key (20326) is to be published in the root zone in 2017. > > > # Servers which were already using the old key (19036) should > # roll seamlessly to this new one via RFC 5011 rollover. Servers > # being set up for the first time can use the contents of this > # file as initializing keys; thereafter, the keys in the > # managed key database will be trusted and maintained > # automatically. > . initial-key 257 3 8 > "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 > +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv > ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF > 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e > oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd > RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN > R1AkUTV74bU="; > > > Peer > > > From martin at lichtvoll.de Thu Oct 11 22:12:53 2018 From: martin at lichtvoll.de (Martin Steigerwald) Date: Thu, 11 Oct 2018 22:12:53 +0200 Subject: [ext] Heute ist DNSSEC-Day In-Reply-To: <20181011082704.GA30312@charite.de> References: <9cede438-b97c-2a2c-8496-5aa38199ce1c@heinlein-support.de> <770f8a6d-5369-a983-76a6-362c47cbe2ec@heinlein-support.de> <20181011082704.GA30312@charite.de> Message-ID: <3107989.fAuUyDqnZ1@merkaba> Ralf Hildebrandt - 11.10.18, 10:27: > > Schuld ist in dem Fall dann jeweils der lokale (veraltete) Resolver > > des Nutzers, der die Webseite nicht aufrufen kann, bzw. des > > Providers, der die Mails an DNSSEC-Domains nicht mehr senden kann. > > https://www.icann.org/dns-resolvers-checking-current-trust-anchors > beschreibt für BIND, unbound PowerDNS Recursor, Knot u.v.a.m. wie > man prüfen kann. Also mit dem Omnia Turris hier komme ich noch ins Netz. DNSSEC scheint immer noch zu funktionieren. Ich vermute, die haben den Knot Resolver in Turris OS längst entsprechend aktualisiert. -- Martin From andreas.schulze at datev.de Wed Oct 17 13:40:58 2018 From: andreas.schulze at datev.de (Andreas Schulze) Date: Wed, 17 Oct 2018 13:40:58 +0200 Subject: noch ein "DNS-Day" im Februar 2019 Message-ID: <95763c8c-4557-a67c-1929-f5487f19d64b@datev.de> Hallo zusammen, nachdem Peer hier auf den (im wesentlichen reibungslosen) Austausch des DNSSEC-Schlüssels in der Root-Zone hingewiesen hat, will ich die Gelegenheit nutzen... ich war am Wochenende auf einem DNS-OARC Workshop (1) in Amsterdam. Neben der Freude über den doch ruhigen KSK-Rollover haben die Entwickler der OpenSource Resolver auf eine gemeinsame Initiative hingewiesen, was ich hiermit gern weitergebe. Das DNS-Protokoll wird seit 20 Jahren durch EDNS erweitert. Dennoch schaffen es viele Betreiber von Nameservern nicht, diese Spezifikation sauber umzusetzen. Daher haben die Programmierer der Resolver massiven Aufwand, durch diverse hässliche Workarounds das System dennoch am Laufen zu halten. Da diese Aufwände exponentiell steigen, ohne dass die Buggy Nameserverbetreiber (die auch gerne mal Milliarden Umsätze machen) sich an diesen Kosten beteiligen, kündigen die Resolver-Entwickler Ihr Fallback-Netz nun ab. Details unter https://dnsflagday.net Jeder solle doch bitte mal seine eigenen Domains/Nameserver mit dem dort verlinkten Tester prüfen und entsprechend handeln. Viele Grüße Andreas -- A. Schulze DATEV eG (1) https://indico.dns-oarc.net/event/29/ From p.heinlein at heinlein-support.de Fri Oct 19 08:52:45 2018 From: p.heinlein at heinlein-support.de (Peer Heinlein) Date: Fri, 19 Oct 2018 08:52:45 +0200 Subject: Fwd: TLSv1.3 (& Postfix) In-Reply-To: <00485c95-ecdd-7ef4-43c2-9c74812b40e5@heinlein-support.de> References: <00485c95-ecdd-7ef4-43c2-9c74812b40e5@heinlein-support.de> Message-ID: <090b24a7-b225-fc29-445f-dc223bd5201d@heinlein-support.de> Hier eine Info aus unserem Team. Schönen Gruß Peer -------- Forwarded Message -------- Subject: TLSv1.3 (& Postfix) Date: Fri, 19 Oct 2018 08:42:26 +0200 From: Carsten Rosenberg To: Heinlein-Support Team Moin, die ersten Distros aktivieren mit den ganz aktuellen Versionen von OpenSSL (openssl (1.1.1-1) September 2018) TLSv1.3 ... und schon gibts Ärger ;) Das hier beschriebene Problem sollte nicht Postfix spezifisch sein: http://postfix.1071664.n5.nabble.com/postfix-amp-TLS1-3-problems-td97864.html Im Postfix bekommt man mit damit mit so einigen Gegenstellen SSL handshake errors und fällt auf Klartext zurück oder die Mail bleibt hängen. Also Vorsicht bei Updates ;) VG c From bjo at nord-west.org Fri Oct 19 18:14:00 2018 From: bjo at nord-west.org (Bjoern Franke) Date: Fri, 19 Oct 2018 18:14:00 +0200 Subject: [ext] NiX Spam - Abfragelimits In-Reply-To: <546073b7-4933-5380-74cc-0209fecfa71a@andreas-ziegler.de> References: <718afdd4-c074-6fb7-820e-13f502f69b0e@gmx.de> <20181008112835.GC30632@charite.de> <01eac9be-b5e2-260e-aad0-4d08da1af194@gmx.de> <20181008170954.633907d4.debian@slashproc.org> <546073b7-4933-5380-74cc-0209fecfa71a@andreas-ziegler.de> Message-ID: <1668d1add40.2802.18df75d9f55f4f1100510b2c557cad9a@nord-west.org> Am 8. Oktober 2018 20:19:02 schrieb Andreas Ziegler : > dito, mehrere Server, alles false positive. Hier heute auch mal wieder, angeblich ist einer unser Resolver offen obwohl dank ACL und Firewall nur Abfragen aus dem eigenen Netz erlaubt werden. Grüße Björn From Jogie at quantentunnel.de Tue Oct 23 10:38:03 2018 From: Jogie at quantentunnel.de (=?UTF-8?Q?=22J=C3=B6rg_Sitek=22?=) Date: Tue, 23 Oct 2018 10:38:03 +0200 Subject: Postscreen Greylisting Message-ID: Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From klaus at tachtler.net Tue Oct 23 10:43:02 2018 From: klaus at tachtler.net (Klaus Tachtler) Date: Tue, 23 Oct 2018 10:43:02 +0200 Subject: Postscreen Greylisting In-Reply-To: Message-ID: <20181023104302.Horde.cQlxIzADo8YpOqOD3V0-4LM@buero.tachtler.net> Hallo Jörg, nachfolgendes sollte eigentlich die DEFAULT-Einstellung sein: # Tachtler - Log: BARE NEWLINE postscreen_bare_newline_enable = no # Tachtler - Log: NON-SMTP COMMAND postscreen_non_smtp_command_enable = no # Tachtler - Log: COMMAND PIPELINING postscreen_pipelining_enable = no Die drei "checks" BARE NEWLINE, NON-SMTP COMMAND und COMMAND PIPELINING würden zu einem "greylisting" führen, soweit ich das richtig verstanden habe. # Deep protocol test - DISABLED to avoid greylisting - # The main limitation of "after 220 greeting" tests is that a new client must disconnect after passing these tests (reason: postscreen is not a proxy). # Then the client must reconnect from the same IP address before it can deliver mail. > Hallo, >   > kann mir jemand einen Tipp geben wie ich das in Postscreen implementierte > Greylisting deaktivieren kann? >   > Danke & viele Grüße > Jörg -- ------------------------------------------------ e-Mail : klaus at tachtler.net Homepage: https://www.tachtler.net DokuWiki: https://dokuwiki.tachtler.net ------------------------------------------------ -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : nicht verfügbar Dateityp : application/pgp-keys Dateigröße : 3120 bytes Beschreibung: Öffentlicher PGP-Schlüssel URL : From Jogie at quantentunnel.de Tue Oct 23 11:20:27 2018 From: Jogie at quantentunnel.de (=?UTF-8?Q?=22J=C3=B6rg_Sitek=22?=) Date: Tue, 23 Oct 2018 11:20:27 +0200 Subject: Aw: Re: Postscreen Greylisting In-Reply-To: <20181023104302.Horde.cQlxIzADo8YpOqOD3V0-4LM@buero.tachtler.net> References: <20181023104302.Horde.cQlxIzADo8YpOqOD3V0-4LM@buero.tachtler.net> Message-ID: Hi Klaus,   danke für den Hinweis. So klappt es.   viele Grüße Jörg       Gesendet: Dienstag, 23. Oktober 2018 um 10:43 Uhr Von: "Klaus Tachtler" An: "Diskussionen und Support rund um Postfix" Betreff: Re: Postscreen Greylisting Hallo Jörg, nachfolgendes sollte eigentlich die DEFAULT-Einstellung sein: # Tachtler - Log: BARE NEWLINE postscreen_bare_newline_enable = no # Tachtler - Log: NON-SMTP COMMAND postscreen_non_smtp_command_enable = no # Tachtler - Log: COMMAND PIPELINING postscreen_pipelining_enable = no Die drei "checks" BARE NEWLINE, NON-SMTP COMMAND und COMMAND PIPELINING würden zu einem "greylisting" führen, soweit ich das richtig verstanden habe. # Deep protocol test - DISABLED to avoid greylisting - # The main limitation of "after 220 greeting" tests is that a new client must disconnect after passing these tests (reason: postscreen is not a proxy). # Then the client must reconnect from the same IP address before it can deliver mail. > Hallo, >   > kann mir jemand einen Tipp geben wie ich das in Postscreen implementierte > Greylisting deaktivieren kann? >   > Danke & viele Grüße > Jörg -- ------------------------------------------------ e-Mail : klaus at tachtler.net Homepage: https://www.tachtler.net DokuWiki: https://dokuwiki.tachtler.net[https://dokuwiki.tachtler.net] ------------------------------------------------   From stse+postfixbuch at fsing.rootsland.net Tue Oct 23 11:40:09 2018 From: stse+postfixbuch at fsing.rootsland.net (Stephan Seitz) Date: Tue, 23 Oct 2018 11:40:09 +0200 Subject: Domainbetreiber mit DNSSEC Message-ID: <20181023T113148.GA.d9a24.stse@fsing.rootsland.net> Hallo, zusammen! Hat nur indirekt etwas mit Postfix zu tun, aber: Welche guten Domainbetreiber (möglichst in Deutschland) kennt ihr, die ihre Zonen auch automatisch mit DNSSEC sichern, ohne daß der Kunde etwas tun muß? Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 3545 bytes Beschreibung: nicht verfügbar URL : From jost+lists at dimejo.at Tue Oct 23 12:53:32 2018 From: jost+lists at dimejo.at (Alex JOST) Date: Tue, 23 Oct 2018 12:53:32 +0200 Subject: Domainbetreiber mit DNSSEC In-Reply-To: <20181023T113148.GA.d9a24.stse@fsing.rootsland.net> References: <20181023T113148.GA.d9a24.stse@fsing.rootsland.net> Message-ID: Am 23.10.2018 um 11:40 schrieb Stephan Seitz: > Hallo, zusammen! > > Hat nur indirekt etwas mit Postfix zu tun, aber: > > Welche guten Domainbetreiber (möglichst in Deutschland) kennt ihr, die > ihre Zonen auch automatisch mit DNSSEC sichern, ohne daß der Kunde etwas > tun muß? https://www.heise.de/ct/artikel/Hoster-und-Registrare-mit-DNSSEC-Diensten-2643530.html -- Alex JOST From klaus at tachtler.net Tue Oct 23 13:50:32 2018 From: klaus at tachtler.net (Klaus Tachtler) Date: Tue, 23 Oct 2018 13:50:32 +0200 Subject: Domainbetreiber mit DNSSEC In-Reply-To: <20181023T113148.GA.d9a24.stse@fsing.rootsland.net> Message-ID: <20181023135032.Horde.Guov1Nn1X_HCC-mPuMMexT4@buero.tachtler.net> Hallo Stephan, ich bin dort sehr zufrieden: - https://www.core-networks.de/ Grüße Klaus. > Hallo, zusammen! > > Hat nur indirekt etwas mit Postfix zu tun, aber: > > Welche guten Domainbetreiber (möglichst in Deutschland) kennt ihr, > die ihre Zonen auch automatisch mit DNSSEC sichern, ohne daß der > Kunde etwas tun muß? > > Shade and sweet water! > > Stephan > > -- > | Public Keys: http://fsing.rootsland.net/~stse/keys.html | -- ------------------------------------------------ e-Mail : klaus at tachtler.net Homepage: https://www.tachtler.net DokuWiki: https://dokuwiki.tachtler.net ------------------------------------------------ -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : nicht verfügbar Dateityp : application/pgp-keys Dateigröße : 3120 bytes Beschreibung: Öffentlicher PGP-Schlüssel URL : From christian at bricart.de Tue Oct 23 15:38:16 2018 From: christian at bricart.de (Christian Bricart) Date: Tue, 23 Oct 2018 15:38:16 +0200 Subject: Domainbetreiber mit DNSSEC In-Reply-To: <20181023T113148.GA.d9a24.stse@fsing.rootsland.net> References: <20181023T113148.GA.d9a24.stse@fsing.rootsland.net> Message-ID: <0caa8067e7967498ee87e3509065d1ee@bricart.de> Hallo Stephan, Als B2B -> http.net Als Endkunde -> hosting.de (ist im Hintergrund der selbe Dienstleister) Grüsse Christian Am 2018-10-23 11:40, schrieb Stephan Seitz: > Hallo, zusammen! > > Hat nur indirekt etwas mit Postfix zu tun, aber: > > Welche guten Domainbetreiber (möglichst in Deutschland) kennt ihr, die > ihre Zonen auch automatisch mit DNSSEC sichern, ohne daß der Kunde > etwas tun muß? > > Shade and sweet water! > > Stephan From thomas at plant.systems Tue Oct 23 17:25:40 2018 From: thomas at plant.systems (Thomas Plant) Date: Tue, 23 Oct 2018 17:25:40 +0200 Subject: =?UTF-8?Q?Postfix_recipient_address_verification_-_f=c3=bcr_einzeln?= =?UTF-8?Q?e_Domain_abschalten?= Message-ID: <2ce41e55-05ff-42e6-6743-41043d7ffe21@plant.systems> Hallo Postfix Gurus, in Kurz: gibt es eine Möglichkeit die 'recipient address verification' für einzelne Domains abzuschalten? Lange Story: Wir haben zwei eingehende Mailgateways für verschiedene Kunden die die Mails per Rspamd überprüfen und an deren Mailserver weiterleiten und dabei die Recipients verifiziert. Jetzt haben wir einen Kunden bei dem die verification einmal fehlschlägt und einmal nicht bzw. der Server in Timeout geht und Postfix stuft das anscheinend als 'reject' ein und lehnt ab diesem Moment die Mails an die Mailadresse ab. Hier so ein Logeintrag: Oct 23 00:21:17 gw7 postfix/cleanup[16527]: 42f9wF3zx5z10js: message-id=<42f9wF3zx5z10js at abcdef.it> Oct 23 00:21:17 gw7 postfix/qmgr[22288]: 42f9wF3zx5z10js: from=, size=225, nrcpt=1 (queue active) Oct 23 00:21:47 gw7 postfix/smtp[16768]: 42f9wF3zx5z10js: to=, relay=none, delay=30, delays=0.01/0/30/0, dsn=4.4.1, status=undeliverable (connect to 95.171.46.42[95.171.46.42]:25: Connection timed out) Oct 23 00:21:47 gw7 postfix/qmgr[22288]: 42f9wF3zx5z10js: removed Kann ich das irgendwie konfigurieren das für die Domain "derproblemkunde.com" die Verifizierung nicht gemacht wird? Stattdessen filtern wir die eingehenden Mails per relay_domains und relay_recipient_maps für diesen Kunden. Danke für jede Hilfe, Thomas From thomas at plant.systems Tue Oct 23 17:31:01 2018 From: thomas at plant.systems (Thomas Plant) Date: Tue, 23 Oct 2018 17:31:01 +0200 Subject: =?UTF-8?Q?Re=3a_Postfix_recipient_address_verification_-_f=c3=bcr_e?= =?UTF-8?Q?inzelne_Domain_abschalten?= In-Reply-To: <2ce41e55-05ff-42e6-6743-41043d7ffe21@plant.systems> References: <2ce41e55-05ff-42e6-6743-41043d7ffe21@plant.systems> Message-ID: Vergessen: wir nutzen zur Zeit noch Debian 8 und damit Postfix 2.11 auf den Gateways. Am 23.10.2018 um 17:25 schrieb Thomas Plant: > Hallo Postfix Gurus, > > in Kurz: gibt es eine Möglichkeit die 'recipient address verification' > für einzelne Domains abzuschalten? > > Lange Story: Wir haben zwei eingehende Mailgateways für verschiedene > Kunden die die Mails per Rspamd überprüfen und an deren Mailserver > weiterleiten und dabei die Recipients verifiziert. Jetzt haben wir > einen Kunden bei dem die verification einmal fehlschlägt und einmal > nicht bzw. der Server in Timeout geht und Postfix stuft das > anscheinend als 'reject' ein und lehnt ab diesem Moment die Mails an > die Mailadresse ab. Hier so ein Logeintrag: > > Oct 23 00:21:17 gw7 postfix/cleanup[16527]: 42f9wF3zx5z10js: > message-id=<42f9wF3zx5z10js at abcdef.it> > Oct 23 00:21:17 gw7 postfix/qmgr[22288]: 42f9wF3zx5z10js: > from=, size=225, nrcpt=1 (queue active) > Oct 23 00:21:47 gw7 postfix/smtp[16768]: 42f9wF3zx5z10js: > to=, relay=none, delay=30, > delays=0.01/0/30/0, dsn=4.4.1, status=undeliverable (connect to > 95.171.46.42[95.171.46.42]:25: Connection timed out) > Oct 23 00:21:47 gw7 postfix/qmgr[22288]: 42f9wF3zx5z10js: removed > > Kann ich das irgendwie konfigurieren das für die Domain > "derproblemkunde.com" die Verifizierung nicht gemacht wird? > Stattdessen filtern wir die eingehenden Mails per relay_domains und > relay_recipient_maps für diesen Kunden. > > > Danke für jede Hilfe, > Thomas > > From cr at ncxs.de Tue Oct 23 17:32:51 2018 From: cr at ncxs.de (Carsten Rosenberg) Date: Tue, 23 Oct 2018 17:32:51 +0200 Subject: =?UTF-8?Q?Re=3a_Postfix_recipient_address_verification_-_f=c3=bcr_e?= =?UTF-8?Q?inzelne_Domain_abschalten?= In-Reply-To: References: <2ce41e55-05ff-42e6-6743-41043d7ffe21@plant.systems> Message-ID: <570f7671-d45f-96be-3251-ed606e074ce6@ncxs.de> Hi, ja wenn du die Domain auf eine eigene restriction class machst. Oder du erlaubst die Empfänger vor dem reject_unverified_recipient via check_recipient_access. VG c On 23.10.18 17:31, Thomas Plant wrote: > Vergessen: wir nutzen zur Zeit noch Debian 8 und damit Postfix 2.11 auf > den Gateways. > > Am 23.10.2018 um 17:25 schrieb Thomas Plant: >> Hallo Postfix Gurus, >> >> in Kurz: gibt es eine Möglichkeit die 'recipient address verification' >> für einzelne Domains abzuschalten? >> >> Lange Story: Wir haben zwei eingehende Mailgateways für verschiedene >> Kunden die die Mails per Rspamd überprüfen und an deren Mailserver >> weiterleiten und dabei die Recipients verifiziert. Jetzt haben wir >> einen Kunden bei dem die verification einmal fehlschlägt und einmal >> nicht bzw. der Server in Timeout geht und Postfix stuft das >> anscheinend als 'reject' ein und lehnt ab diesem Moment die Mails an >> die Mailadresse ab. Hier so ein Logeintrag: >> >> Oct 23 00:21:17 gw7 postfix/cleanup[16527]: 42f9wF3zx5z10js: >> message-id=<42f9wF3zx5z10js at abcdef.it> >> Oct 23 00:21:17 gw7 postfix/qmgr[22288]: 42f9wF3zx5z10js: >> from=, size=225, nrcpt=1 (queue active) >> Oct 23 00:21:47 gw7 postfix/smtp[16768]: 42f9wF3zx5z10js: >> to=, relay=none, delay=30, >> delays=0.01/0/30/0, dsn=4.4.1, status=undeliverable (connect to >> 95.171.46.42[95.171.46.42]:25: Connection timed out) >> Oct 23 00:21:47 gw7 postfix/qmgr[22288]: 42f9wF3zx5z10js: removed >> >> Kann ich das irgendwie konfigurieren das für die Domain >> "derproblemkunde.com" die Verifizierung nicht gemacht wird? >> Stattdessen filtern wir die eingehenden Mails per relay_domains und >> relay_recipient_maps für diesen Kunden. >> >> >> Danke für jede Hilfe, >> Thomas >> >> > From postfixer99 at gmail.com Tue Oct 23 20:16:22 2018 From: postfixer99 at gmail.com (Carsten) Date: Tue, 23 Oct 2018 20:16:22 +0200 Subject: dovecot Traffic Analysetool gesucht Message-ID: Hallo zusammen, einige meinerUser scheinen extrem viel IMAP-Traffic zu erzeugen. Es ist schwierig diese Poweruser manuell im Logfile zu identifizieren. Welche Logfile Analyse-Werkzeuge nutzt Ihr für Dovecot?  (2.2.13) Beste Grüße, Carsten From thomas at plant.systems Wed Oct 24 09:36:35 2018 From: thomas at plant.systems (Thomas Plant) Date: Wed, 24 Oct 2018 09:36:35 +0200 Subject: =?UTF-8?Q?Re=3a_Postfix_recipient_address_verification_-_f=c3=bcr_e?= =?UTF-8?Q?inzelne_Domain_abschalten?= In-Reply-To: <570f7671-d45f-96be-3251-ed606e074ce6@ncxs.de> References: <2ce41e55-05ff-42e6-6743-41043d7ffe21@plant.systems> <570f7671-d45f-96be-3251-ed606e074ce6@ncxs.de> Message-ID: Ok Danke für die Info, werd mal 'reject_unverified_recipient' auf einem Testsystem versuchen. Die 'relay_recipient_maps' die wir per MySQL einlesen werden dadurch nicht beeinflusst? VG, Thomas Am 23.10.2018 um 17:32 schrieb Carsten Rosenberg: > Hi, > > ja wenn du die Domain auf eine eigene restriction class machst. > > Oder du erlaubst die Empfänger vor dem reject_unverified_recipient via > check_recipient_access. > > VG c > > On 23.10.18 17:31, Thomas Plant wrote: >> Vergessen: wir nutzen zur Zeit noch Debian 8 und damit Postfix 2.11 auf >> den Gateways. >> >> Am 23.10.2018 um 17:25 schrieb Thomas Plant: >>> Hallo Postfix Gurus, >>> >>> in Kurz: gibt es eine Möglichkeit die 'recipient address verification' >>> für einzelne Domains abzuschalten? >>> >>> Lange Story: Wir haben zwei eingehende Mailgateways für verschiedene >>> Kunden die die Mails per Rspamd überprüfen und an deren Mailserver >>> weiterleiten und dabei die Recipients verifiziert. Jetzt haben wir >>> einen Kunden bei dem die verification einmal fehlschlägt und einmal >>> nicht bzw. der Server in Timeout geht und Postfix stuft das >>> anscheinend als 'reject' ein und lehnt ab diesem Moment die Mails an >>> die Mailadresse ab. Hier so ein Logeintrag: >>> >>> Oct 23 00:21:17 gw7 postfix/cleanup[16527]: 42f9wF3zx5z10js: >>> message-id=<42f9wF3zx5z10js at abcdef.it> >>> Oct 23 00:21:17 gw7 postfix/qmgr[22288]: 42f9wF3zx5z10js: >>> from=, size=225, nrcpt=1 (queue active) >>> Oct 23 00:21:47 gw7 postfix/smtp[16768]: 42f9wF3zx5z10js: >>> to=, relay=none, delay=30, >>> delays=0.01/0/30/0, dsn=4.4.1, status=undeliverable (connect to >>> 95.171.46.42[95.171.46.42]:25: Connection timed out) >>> Oct 23 00:21:47 gw7 postfix/qmgr[22288]: 42f9wF3zx5z10js: removed >>> >>> Kann ich das irgendwie konfigurieren das für die Domain >>> "derproblemkunde.com" die Verifizierung nicht gemacht wird? >>> Stattdessen filtern wir die eingehenden Mails per relay_domains und >>> relay_recipient_maps für diesen Kunden. >>> >>> >>> Danke für jede Hilfe, >>> Thomas >>> >>> From thomas at plant.systems Wed Oct 24 16:09:49 2018 From: thomas at plant.systems (Thomas Plant) Date: Wed, 24 Oct 2018 16:09:49 +0200 Subject: =?UTF-8?Q?=c3=84nder_von_proxy=5fread=5fmaps?= Message-ID: <32f0fd4e-005d-8ac3-e8c6-6775e9d865b3@plant.systems> Hallo, proxy_read_maps enthält einen Haufen default Werte. Ich müsste einen 'proxy:mysql:....' Wert hinzufügen. Dazu hab ich mir mit 'postconf -d proxy_read_maps' die Defaultwerte ausgeben lassen und eine Zeile für die main.cf konstruiert. Hier ein Beispiel mit dem meine Config z.Z. funktioniert: proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $smtpd_sender_login_maps $sender_bcc_maps $recipient_bcc_maps $smtp_generic_maps $lmtp_generic_maps $alias_maps proxy:mysql:/etc/postfix/mysql/check_recipient_access.cf Das kommt mir allerdings problematisch vor wenn sich z.B. durch ein Update die Defaultwerte ändern. Gibt es keine Möglichkeit mit einer Art Macro die Defaultwerte automatisch einzubinden? VG, Thomas From mailinglists at qutic.com Thu Oct 25 16:23:47 2018 From: mailinglists at qutic.com (qutic development) Date: Thu, 25 Oct 2018 16:23:47 +0200 Subject: dovecot Traffic Analysetool gesucht In-Reply-To: References: Message-ID: <5A3F7F35-62CB-46A4-98C4-86706804F4B8@qutic.com> > Welche Logfile Analyse-Werkzeuge nutzt Ihr für Dovecot? (2.2.13) Wir machen das mit dem ELK-Stack [1] und können uns damit den Traffic jedes Users ausrechnen lassen. Gruß, Stefan [1] https://www.elastic.co/de/ From stse+postfixbuch at fsing.rootsland.net Wed Oct 24 20:34:07 2018 From: stse+postfixbuch at fsing.rootsland.net (Stephan Seitz) Date: Wed, 24 Oct 2018 20:34:07 +0200 Subject: Domainbetreiber mit DNSSEC In-Reply-To: References: <20181023T113148.GA.d9a24.stse@fsing.rootsland.net> Message-ID: <20181024T203215.GA.47518.stse@fsing.rootsland.net> On Di, Okt 23, 2018 at 12:53:32 +0200, Alex JOST wrote: >Am 23.10.2018 um 11:40 schrieb Stephan Seitz: >>Welche guten Domainbetreiber (möglichst in Deutschland) kennt ihr, die >>ihre Zonen auch automatisch mit DNSSEC sichern, ohne daß der Kunde >>etwas tun muß? >https://www.heise.de/ct/artikel/Hoster-und-Registrare-mit-DNSSEC-Diensten-2643530.html Vielen Dank auch an alle anderen, die sich hier oder privat gemeldet haben. Da werde ich mir dann mal die Anbieter anschauen. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : smime.p7s Dateityp : application/pkcs7-signature Dateigröße : 3545 bytes Beschreibung: nicht verfügbar URL : From gjn at gjn.priv.at Tue Oct 30 01:39:59 2018 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Tue, 30 Oct 2018 01:39:59 +0100 Subject: OT: Nur eine Test Message-ID: <2255746.pZEpQ7I1yt@techz> Hallo, ist nur ein Test da meine SUSE Listen nicht mehr funktionieren Danke -- mit freundliche Grüßen / best regards, Günther J. Niederwimmer -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 488 bytes Beschreibung: This is a digitally signed message part. URL : From claas.goltz at contact-software.com Tue Oct 30 12:49:07 2018 From: claas.goltz at contact-software.com (Claas Goltz) Date: Tue, 30 Oct 2018 12:49:07 +0100 Subject: =?UTF-8?Q?Unregelm=c3=a4=c3=9fig_bei_spamrl=2ecom_gelistet?= Message-ID: Hallo Kollegen, ich habe hin und wieder, vielleicht einmal im Monat, das Problem, dass ein bestimmter MX Server von uns bei spamrl.com mit folgender Begründung gelistet ist: "(..) said: 550 The sending IP (x.x.x.x) is listed on https://spamrl.com as a source of dictionary attacks. (in reply to end of DATA command)) (...)" Prüfe ich zu dem fraglichen Zeitpunkt mit diversen blacklist checker, ob wir irgendwo sonst gelistet sind, ist das nie der Fall. Es ist also ausschließlich spamrl.com. Meine anderen MX'e sind nicht betroffen. Es ist immer der eine. Ich kann mir da keinen Reim 'draus machen. Ich sehe keine verdächtigen Prozesse. Habt ihr einen Tipp für mich, wie ich der Sache auf den Grund gehen kann? Auf dem Server läuft ein Deb 9.5 mit Postfix 3.1.8 und Amavis 2.10. Ich lasse auch outbound Mails checken. Danke und Viele Grüße! #postconf -n (ist auf den anderen MX Server auch aktiv) alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no bounce_queue_lifetime = 3d check_greylist = check_policy_service inet:127.0.0.1:10023 compatibility_level = 2 delay_warning_time = 4h header_checks = regexp:/etc/postfix/header_checks inet_interfaces = all insiders_only = check_sender_access hash:/etc/postfix/insiders, reject maximal_queue_lifetime = 3d message_size_limit = 41943040 mydestination = fqdn, localhost.domain, localhost myhostname = fqdn mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 (...) myorigin = fqdn readme_directory = no relay_domains = hash:/etc/postfix/relay_domains, smtp_helo_name = fqdn smtp_tls_CApath = /etc/ssl/certs smtp_tls_cert_file = $smtpd_tls_cert_file smtp_tls_key_file = $smtpd_tls_key_file smtp_tls_loglevel = 1 smtp_tls_security_level = may smtpd_banner = fqdn ESMTP $mail_name smtpd_helo_required = yes smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/access_recipient, check_client_access cidr:/etc/postfix/access_client, check_helo_access hash:/etc/postfix/access_helo, check_sender_access hash:/etc/postfix/access_sender, check_recipient_access hash:/etc/postfix/protected_destinations reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_invalid_hostname, permit_sasl_authenticated, permit_mynetworks, reject_rbl_client zen.spamhaus.org, reject_rbl_client ix.dnsbl.manitu.net, check_policy_service inet:127.0.0.1:12525 check_client_access regexp:/etc/postfix/check_client_greylist reject_unverified_recipient, permit_mx_backup, reject_unauth_destination, permit smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination smtpd_restriction_classes = check_greylist, insiders_only smtpd_sasl_auth_enable = no smtpd_tls_cert_file = /etc/ssl/wildcard/fullchain.pem smtpd_tls_dh1024_param_file = /etc/postfix/dh_2048.pem smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem smtpd_tls_eecdh_grade = strong smtpd_tls_key_file = /etc/ssl/wildcard/fqdn.key smtpd_tls_loglevel = 1 smtpd_tls_security_level = may strict_rfc821_envelopes = yes tls_preempt_cipherlist = yes transport_maps = hash:/etc/postfix/transport_maps, $relay_domains unverified_recipient_reject_code = 599 -- Claas Goltz IT-Systemadministrator CONTACT Software GmbH Wiener Straße 1?3, 28359 Bremen, Germany T +49 421 20153-27 F +49 421 20153-41 mailto:claas.goltz at contact-software.com www.contact-software.com Registered office: Bremen, Germany Managing directors: Karl Heinz Zachries, Ralf Holtgrefe Court of register: Amtsgericht Bremen HRB 13215 From Ralf.Hildebrandt at charite.de Tue Oct 30 12:53:49 2018 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Tue, 30 Oct 2018 12:53:49 +0100 Subject: [ext] =?utf-8?B?VW5yZWdlbG3DpMOfaQ==?= =?utf-8?Q?g?= bei spamrl.com gelistet In-Reply-To: References: Message-ID: <20181030115349.GK26557@charite.de> * Claas Goltz : > Hallo Kollegen, > > ich habe hin und wieder, vielleicht einmal im Monat, das Problem, dass ein > bestimmter MX Server von uns bei spamrl.com mit folgender Begründung > gelistet ist: > > "(..) said: 550 The sending IP (x.x.x.x) is listed on https://spamrl.com as > a source of dictionary attacks. (in reply to end of DATA command)) (...)" dictionary attacks, also viel Emails an (unbekannte) Adressen. > Prüfe ich zu dem fraglichen Zeitpunkt mit diversen blacklist checker, ob wir > irgendwo sonst gelistet sind, ist das nie der Fall. Es ist also > ausschließlich spamrl.com. Jede Liste hat ihre eigenen Aufnahmekriterien. > Meine anderen MX'e sind nicht betroffen. Es ist immer der eine. Ich kann mir > da keinen Reim 'draus machen. Ich sehe keine verdächtigen Prozesse. Für mich klingt das eher so, als würde von dem einen Host viel gesendet werden. > Habt ihr einen Tipp für mich, wie ich der Sache auf den Grund gehen kann? Mails suchen mit "status=bounced" und nachsehen, ob viele Mails an unbekannte Adressen gesendet wurden. http://postfix.1071664.n5.nabble.com/Spamrl-com-RBL-problem-td84686.html-- 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 | https://www.charite.de