From ms at ddnetservice.de Sat Apr 1 01:29:16 2017 From: ms at ddnetservice.de (ms at ddnetservice.de) Date: Sat, 1 Apr 2017 01:29:16 +0200 Subject: Problem mit Spam In-Reply-To: <7677da87-6dbc-d116-f14f-78d080f859fc@xanismail.de> References: <9b259282-29aa-8a13-dc74-0d2b8fb1f267@debianfan.de> <20170321091714.s42cse5syo6c4bby@sys4.de> <38a66883-1a56-15d3-c6dc-1a4959e44027@ddnetservice.de> <7677da87-6dbc-d116-f14f-78d080f859fc@xanismail.de> Message-ID: Am 31.03.2017 um 21:16 schrieb Thomas Schwenski: > > Es gibt also durchaus Mittel und Wege solche Spammer IPs zu > > blockieren, die mit den neuen TLDs verschicken, ohne gleich alle > > neuen TLDs von Haus aus blockieren zu müssen. > > Das Problem sind tatsächlich weniger die konkreten IPs als die > besagten TLDs - diese werden tatsächlich gerade verstärkt beschickt. > (Ist zumindest auch meine Erfahrung hier mit vermutlich nur einem > einzigen Verursacher.) > > Für mich eher ein Fall des bekannten Henne-Ei Problems. Wenn man es schafft, die Spammer-IPs zu erfassen, dann muss man die neuen TLDs nicht komplett blocken. Der Versand erfolgt meinen Beobachtungen zufolge immer nur von einigen wenigen Servern aus dem Netz von Massen-Hoster XYZ. Daher der Ansatz mit Spamassassin, weil man hierüber die TLDs erfassen kann von denen gerne mal gespammt wird. Ich mache es so, dass ich mit Spamassassin solche E-Mails von den neuen TLDs tagge und dann stündlich das maillog auf evtl. Hits automatisiert überprüfe. Wenn ein gewisser Threshold erreicht wurde, dann wandert diese IP in eine interne DNSBL. Im schlimmsten Fall provoziert dies einen false-positive, da vielleicht tatsächlich mal jemand legitimes viele E-Mails über eine der neuen TLDs verschickt hat. Allerdings ist dieser Fall in der Praxis mir noch nicht untergekommen. Daher ist dieser Ansatz m.M.n. mit taggen und später blocken immerhin ein guter Kompromiss zwischen "ich bin total resolut und blocke alle neuen TLDs" und "ich lasse mal alle neuen TLDs durch". Gruß Micha From torben at dannhauer.info Sun Apr 2 08:18:42 2017 From: torben at dannhauer.info (Torben Dannhauer) Date: Sun, 2 Apr 2017 08:18:42 +0200 Subject: =?utf-8?Q?AW:_postfix_f=C3=BCgt_'sub_address'_=28?= =?utf-8?Q?tag=29_bei_Weiterleitungen_hinzu?= In-Reply-To: References: Message-ID: <056301d2ab78$fa291fb0$ee7b5f10$@dannhauer.info> Hallo, Ja das genannte Verhalten erscheint mir korrekt : http://www.postfix.org/aliases.5.html -> " ADDRESS EXTENSION" Postfix ist mittels http://www.postfix.org/postconf.5.html#propagate_unmatched_extensions konfigurierbar, ob es die Extension fallen lassen soll, oder dieser weiterreichen soll. Daher musst du das bei dir dann entsprechend in Postfix konfigurieren. Wenn du zwei Weiterleitungen definiert hast (max+sub-address at .. und max at ..), wird er die bestpassendste Adresse nutzen. Bsp: max at .. -> Ziel1 max+foo at .. -> Ziel2 witwe-bolte@ ->wilhelm at busch.de Sprich eine Email an max at .. gehts an Ziel1 Eine Email max+foo geht an Ziel2 Eine Mail an witwe-bolte+foo at .. geht je nach propagate_unmatched_extensions setting an wilhelm+foo at busch.de oder an wilhelm at busch.de Grüße, Torben -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Igor Sverkos Gesendet: Donnerstag, 30. März 2017 17:03 An: Postfix-Buch Mailing List Betreff: postfix fügt 'sub address' (tag) bei Weiterleitungen hinzu Hallo, ich habe folgendes Verhalten beobachtet und würde gerne wissen ob das wirklich so vorgesehen ist: Auf einem Mailserver der für example.invalid zuständig ist wurde die E-Mailadresse "max at example.invalid" als Weiterleitung zu "moritz at auf-einem-anderen-server.invalid" eingerichtet. In der Konfiguration ist "recipient_delimiter = +" gesetzt. Wenn jetzt jemand eine E-Mail an "max+sub-address at example.invalid" schreibt wird diese E-Mail nicht wie von mir gedacht an "moritz at auf-einem-anderen-server.invalid" weitergeleitet, sondern eben an "moritz+sub-address at auf-einem-anderen-server.invalid". Soll das wirklich so sein? Aufgefallen ist es, weil der MX von "auf-einem-anderen-server.invalid" keine "Sub Addresses" (tagging) unterstützt und die Mail daher wegen "Recipient address rejected: undeliverable address" abgelehnt wurde. Ich frage mich gerade auch was Postfix machen würde, wenn ich explizit als Weiterleitungsziel "moritz+weiterleitung-von-max at auf-einem-anderen-server.invalid" bei mir gesetzt hätte... hängt er dann ein weiteres "+" an oder überschreibt gar meines? Daher erscheint mir das nicht richtig. Dem könnte ich jetzt bspw. mit einer recipient_canonical_maps begegnen aber evtl. geht das auch eleganter oder ist ein Bug? -- Ich Grüße, Igor From thomas.schwenski at xanismail.de Mon Apr 3 00:37:03 2017 From: thomas.schwenski at xanismail.de (Thomas Schwenski) Date: Mon, 3 Apr 2017 00:37:03 +0200 Subject: Umgang mit permanenten Fehlern / REJECT Message-ID: <34c9146f-53a0-3db7-3cba-71699592fce0@xanismail.de> Hallo, mal eine fachliche Frage an euch: Wie ist das Abweisen mit einem permaneten Fehler (5xx) technisch und rechtlich einzustufen? Bisher ging ich davon aus, das die Gegenstelle, die den REJECT sendet, nicht mehr für die Mail zuständig ist. Technisch gesehen hat Sie ja die Annahme der Mail verweigert - und der sendende Mailserver informiert den Absender darüber. Juristisch gesehen müsste die Mail also als nicht zugestellt gelten (wovon der Absender ja nun ausgehen muss). Jetzt ist mir aber ein Server begegnet, der zwar einen permanenten Fehler zurückliefert (konkret 570) die Mail aber trotzdem an den Empfänger zustellt. (Das Ganze ist wohl Teil deren Spam-Setups, denn die Mail ging aufgrund einiger typischer Begriffe in den Spam-Folder des Postfachs.) Technisch ist das Ganze für mich irgendwie zwar nachvollziehbar, aber juristisch habe ich hier gerade ziemliche Bauchschmerzen über dieses Serververhalten. Was meint Ihr? (Insbesondere Du Peer.) Thomas From rainer_wiesenfarth at trimble.com Tue Apr 4 08:51:17 2017 From: rainer_wiesenfarth at trimble.com (Rainer Wiesenfarth) Date: Tue, 4 Apr 2017 08:51:17 +0200 Subject: OT: Seltsames(?) Verhalten von GMX Message-ID: Hallo, wir haben ein seltsames Verhalten von GMX festgestellt und können das nicht richtig einordnen. Kurzform: GMX schickt "Bad DNS PTR" Meldungen, obwohl HELO, A und PTR passen. Langform: Wir haben einen Server unter dem Namen euve000000.serverprofi.24.de passend eingerichtet (verifiziert mit helocheck und DNS Lookups). Dennoch lehnt GMX ab: Mar 30 12:38:26 euve000000 postfix/smtp[29487]: 3503880616: to=< johndoe at gmx.de >, orig_to=>, relay=mx01.emig.gmx.net[212.227.17.5]:25, delay=1096, delays=1096/0.01/0.11/0, dsn=4.0.0, status=deferred (host mx01.emig.gmx.net[212.227.17.5] refused to talk to me: 554-gmx.net (mxgmx105) Nemesis ESMTP Service not available 554-No SMTP service 554-Bad DNS PTR resource record. 554 For explanation visit http://postmaster.gmx.com/en/e rror-messages?ip=1.2.3.4&c=rdns ) ?(das passiert auch? ohne orig_to). Sobald wir den Servernamen auf einen "vernünftigen" Namen ändern, gehen die Nachrichten durch. Kann uns jemand sagen, ob wir da etwas falsch machen oder ob GMX eine falsche Meldung absetzt? Viele Grüße Rainer -- Software Engineer | Trimble Imaging Division Rotebühlstraße 81 | 70178 Stuttgart | Germany Office +49 711 22881 0 | Fax +49 711 22881 11 http://www.trimble.com/imaging/ | http://www.inpho.de/ Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, Geschäftsführer: Dr. Frank Heimberg, Jürgen Kesper -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From ms at ddnetservice.de Tue Apr 4 09:00:02 2017 From: ms at ddnetservice.de (ms at ddnetservice.de) Date: Tue, 4 Apr 2017 09:00:02 +0200 Subject: OT: Seltsames(?) Verhalten von GMX In-Reply-To: References: Message-ID: Am 04.04.2017 um 08:51 schrieb Rainer Wiesenfarth: > Hallo, > > wir haben ein seltsames Verhalten von GMX festgestellt und können das > nicht richtig einordnen. > > Kurzform: GMX schickt "Bad DNS PTR" Meldungen, obwohl HELO, A und PTR > passen. > > Langform: > > Wir haben einen Server unter dem Namen euve000000.serverprofi.24.de > passend eingerichtet > (verifiziert mit helocheck und DNS Lookups). Dennoch lehnt GMX ab: > > Mar 30 12:38:26 euve000000 postfix/smtp[29487]: 3503880616: > to=>, > orig_to=>, > relay=mx01.emig.gmx.net [212.227.17.5]:25, > delay=1096, delays=1096/0.01/0.11/0, dsn=4.0.0, status=deferred (host > mx01.emig.gmx.net [212.227.17.5] refused to > talk to me: 554-gmx.net (mxgmx105) Nemesis ESMTP > Service not available 554-No SMTP service 554-Bad DNS PTR resource > record. 554 For explanation visit > http://postmaster.gmx.com/en/error-messages?ip=1.2.3.4&c=rdns > ) > > ?(das passiert auch? ohne orig_to). > > Sobald wir den Servernamen auf einen "vernünftigen" Namen ändern, > gehen die Nachrichten durch. > > Moin die Antwort hast Du Dir im Prinzip schon selbst gegeben, mit "vernünftiger" Servername... Auszug aus der GMX Postmaster FAQ: > > * The PTR-RR states that the IP address was dynamically allocated. > * The PTR-RR is a generic standard entry of your provider. Please > allocate an independent and fully qualified domain name (Fully > Qualified Domain Name - FQDN) to your email server and enter the > corresponding valid PTR-RR. > Einfach einen PTR und Hostnamen wählen der nicht wie ein "standard entry" des Providers aussieht. Gruß Michael From mail at behrens.io Tue Apr 4 09:03:56 2017 From: mail at behrens.io (Boris Behrens) Date: Tue, 4 Apr 2017 09:03:56 +0200 Subject: OT: Seltsames(?) Verhalten von GMX In-Reply-To: References: Message-ID: <424D5B81-EB6B-498B-B294-48588DF34A4F@behrens.io> Hi, #dig euve000000.serverprofi.24.de euve000000.serverprofi.24.de. 86399 IN A 127.0.0.2 Ist das der aktuell richtige Wert? Wenn ja, wundert es mich jetzt nicht. Habt Ihr vielleicht n SplitDNS laufen und du bekommst nur interne requests zurück? Boris > Am 04.04.2017 um 08:51 schrieb Rainer Wiesenfarth : > > Hallo, > > wir haben ein seltsames Verhalten von GMX festgestellt und können das nicht richtig einordnen. > > Kurzform: GMX schickt "Bad DNS PTR" Meldungen, obwohl HELO, A und PTR passen. > > Langform: > > Wir haben einen Server unter dem Namen euve000000.serverprofi.24.de passend eingerichtet (verifiziert mit helocheck und DNS Lookups). Dennoch lehnt GMX ab: > > Mar 30 12:38:26 euve000000 postfix/smtp[29487]: 3503880616: to=>, orig_to=>, relay=mx01.emig.gmx.net [212.227.17.5]:25, delay=1096, delays=1096/0.01/0.11/0, dsn=4.0.0, status=deferred (host mx01.emig.gmx.net [212.227.17.5] refused to talk to me: 554-gmx.net (mxgmx105) Nemesis ESMTP Service not available 554-No SMTP service 554-Bad DNS PTR resource record. 554 For explanation visit http://postmaster.gmx.com/en/error-messages?ip=1.2.3.4&c=rdns ) > > ?(das passiert auch? ohne orig_to). > > Sobald wir den Servernamen auf einen "vernünftigen" Namen ändern, gehen die Nachrichten durch. > > Kann uns jemand sagen, ob wir da etwas falsch machen oder ob GMX eine falsche Meldung absetzt? > > Viele Grüße > Rainer > > -- > Software Engineer | Trimble Imaging Division > Rotebühlstraße 81 | 70178 Stuttgart | Germany > Office +49 711 22881 0 | Fax +49 711 22881 11 > http://www.trimble.com/imaging/ | http://www.inpho.de/ > > Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim > Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, > Geschäftsführer: Dr. Frank Heimberg, Jürgen Kesper -------------- 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 : 3565 bytes Beschreibung: nicht verfügbar URL : From rainer_wiesenfarth at trimble.com Tue Apr 4 11:04:05 2017 From: rainer_wiesenfarth at trimble.com (Rainer Wiesenfarth) Date: Tue, 4 Apr 2017 11:04:05 +0200 Subject: OT: Seltsames(?) Verhalten von GMX In-Reply-To: References: Message-ID: Am 4. April 2017 um 09:00 schrieb : > Einfach einen PTR und Hostnamen wählen der nicht wie ein "standard entry" > des Providers aussieht. ?Ok, wer lesen kann ist klar im Vorteil... Wir haben uns durch das "Bad DNS PTR" irritieren lassen - zumal der vorherige Server mit vs0000000.vserver.de auch einen Standardnamen hatte, der aber funktionierte...? ?Danke für den Hinweis! -- Software Engineer | Trimble Imaging Division Rotebühlstraße 81 | 70178 Stuttgart | Germany Office +49 711 22881 0 | Fax +49 711 22881 11 http://www.trimble.com/imaging/ | http://www.inpho.de/ Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, Geschäftsführer: Dr. Frank Heimberg, Jürgen Kesper -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From rainer_wiesenfarth at trimble.com Tue Apr 4 11:06:56 2017 From: rainer_wiesenfarth at trimble.com (Rainer Wiesenfarth) Date: Tue, 4 Apr 2017 11:06:56 +0200 Subject: OT: Seltsames(?) Verhalten von GMX In-Reply-To: <424D5B81-EB6B-498B-B294-48588DF34A4F@behrens.io> References: <424D5B81-EB6B-498B-B294-48588DF34A4F@behrens.io> Message-ID: Am 4. April 2017 um 09:03 schrieb Boris Behrens : > #dig euve000000.serverprofi.24.de > euve000000.serverprofi.24.de. 86399 IN A 127.0.0.2 > > Ist das der aktuell richtige Wert? > ?Nö, die richtige Nummer habe ich geändert, weil das "dig?ging" ja in beide Richtungen funktioniert hat. Aber der Hinweis auf den "standard entry" scheint die Ursache zu sein. Das hatten wir im Nachhinein auch vermutet, hätten es aber nicht hinter der Fehlermeldung "Bad DNS PTR" vermutet. Viele Grüße Rainer -- Software Engineer | Trimble Imaging Division Rotebühlstraße 81 | 70178 Stuttgart | Germany Office +49 711 22881 0 | Fax +49 711 22881 11 http://www.trimble.com/imaging/ | http://www.inpho.de/ Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, Geschäftsführer: Dr. Frank Heimberg, Jürgen Kesper -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From chris2014 at postbox.xyz Fri Apr 7 17:42:12 2017 From: chris2014 at postbox.xyz (Chris) Date: Fri, 7 Apr 2017 17:42:12 +0200 Subject: filtertechnik@t-online.de Message-ID: <8dbb81d203642f47608e06053ee37a68.squirrel@mail2.postbox.xyz> Weiss jemand zufällig was das für Filtertechnik ist? https://www.heise.de/newsticker/meldung/Spamflut-bei-T-Online-Filtertechnik-der-Telekom-ueberfordert-3678137.html Gruß, Christian From thomas.schwenski at xanismail.de Mon Apr 10 01:48:22 2017 From: thomas.schwenski at xanismail.de (Thomas Schwenski) Date: Mon, 10 Apr 2017 01:48:22 +0200 Subject: filtertechnik@t-online.de In-Reply-To: <8dbb81d203642f47608e06053ee37a68.squirrel@mail2.postbox.xyz> References: <8dbb81d203642f47608e06053ee37a68.squirrel@mail2.postbox.xyz> Message-ID: Hallo Christian, ein Schelm wer jetzt Böses dabei denkt, dass Deine(?) Domain sich hinter einem Whois Guard verbirgt. :) Aber zu Deiner Frage: > Weiss jemand zufällig was das für Filtertechnik ist? Ich glaube nicht, dass jemand hier etwas konkretes weiß. Thomas From martin at lichtvoll.de Sat Apr 15 12:57:55 2017 From: martin at lichtvoll.de (Martin Steigerwald) Date: Sat, 15 Apr 2017 12:57:55 +0200 Subject: =?UTF-8?B?QW5ow6RuZ2U=?= blocken, z.B. ZIP-Archive mit Javascript-Malware Message-ID: <1499483.vSjfiB9zQ5@merkaba> Hallo! Da ich gerade eben von den täglichen ZIP-Archiven mit Javascript-Malware, die über vger.kernel.org reinkommen (die die Postmaster dort an sich auch mal blocken könnten), die Schnauze wohl hab, hab ich jetzt mal # Anhänge blocken: ZIP noch dazu, weil das am häufigsten kommt. # http://www.postfix.org/header_checks.5.html /^Content-(Disposition|Type).*name\s*=\s*"?([^;]*(\.|=2E)( ade|adp|asp|bas|bat|chm|cmd|com|cpl|crt|dll|exe| hlp|ht[at]| inf|ins|isp|jse?|lnk|md[betw]|ms[cipt]|nws| \{[[:xdigit:]]{8}(?:-[[:xdigit:]]{4}){3}-[[:xdigit:]]{12}\}| ops|pcd|pif|prf|reg|sc[frt]|sh[bsm]|swf| vb[esx]?|vxd|ws[cfh]|zip))(\?=)?"?\s*(;|$)/x REJECT Attachment name "$2" may not end with ".$4" in die via PCRE eingebundenen Header-Checks eingebaut. Aus naheliegenden Gründen möchte ich jetzt keine dieser Mails weiterleiten. Lösch die eh gleich wieder. Soweit durch die Verwirrungstaktik in einem der Skripte durchblicke, greift das ohnehin mal wieder nur auf Windows-Systemen. Diese Mails gehen seit eh und jeh bei mir sowohl an policyd-weight als auch an SpamAssassin mit Zusatzregeln spamassassin.heinlein-support.de, updates.spamassassin.org, sought.rules.yerp.org vorbei. Ich bin bei der Recherche auch auf Postscreen gestoßen und sicherlich würde sich auch Amavis dazu eignen. Auch postgrey habe ich mir mal wieder überlegt, jedoch kam ich bislang auch ganz gut ohne aus und mag das an sich nicht so gerne, wenn legitime Mails um Minuten verzögert bei mir eintreffen. Insgesamt möchte ich mein Mailserver-Setup auch nicht unnötig komplex machen. Ich hab ohnehin immer mehr Komplexität hinzugefügt als eine Art Wettrüsten mit den Spammern. Falls jemand mir ein Archiv schicken möchte, könnte sie es immer noch irgendwo hochladen oder? ein anderes Kompressionsformat verwenden. Was verwendet ihr? Also genau da würde mich eine aktualisierte Fassung des Postfix-Buches mit den aktuellen Best Practice-Empfehlungen für ein einfaches, jedoch auch äußerst wirksames Spamfilter-Setup interessieren. Natürlich dürfte das zu einem Teil auch zum Geschäftsgeheimnis von Mail-Konto-Anbietern gehören. Mein Setup ist auch bereits recht wirksam, wenn ich sehe, dass pro Tag micht mehr als ca. 20 Mails durchkommen. Ich hab keine Stastistik, aber ich gehe davon aus, dass mein Server über 90% aller Mails auf SMTP-Ebene zurückweist. (Manchmal möchte ich einfach alle Mails wegblocken oder einen Antibot schreiben, der sämtliche schlecht abgesicherten IoT-Müll-Teile und VMs unbrauchbar macht. Und ja, ich kann mich zurückhalten.). Kandidaten, die meinen Dovecot knacken wollen, dabei jedoch dilletantisch vorgehen, gibt es auch mal wieder: Apr 15 12:34:22 mondschein dovecot: pop3-login: Disconnected (tried to use disallowed plaintext auth): user=<>, rip=49.69.121.47, lip=194.150.191.11 (Okay, grad mal sshguard angepasst, damit er auch das mail.log pollt.) Frohe Ostern, -- Martin From dominik at kupschke.net Sat Apr 15 13:35:15 2017 From: dominik at kupschke.net (Dominik Kupschke) Date: Sat, 15 Apr 2017 13:35:15 +0200 Subject: =?UTF-8?B?QW5ow6RuZ2U=?= blocken, z.B. ZIP-Archive mit Javascript-Malware In-Reply-To: <1499483.vSjfiB9zQ5@merkaba> References: <1499483.vSjfiB9zQ5@merkaba> Message-ID: <6157148.U9ivyKdr1f@dominik-desktop> Hallo, gegen ZIP Dateien mit Javascript oder Double-Extensions (invoice.pdf.exe) verwende ich ClamAV mit den Foxhole Signaturen von Sanesecurity: http://sanesecurity.com/foxhole-databases/ VG Dominik Am Samstag, 15. April 2017, 12:57:55 CEST schrieb Martin Steigerwald: > Hallo! > > Da ich gerade eben von den täglichen ZIP-Archiven mit Javascript-Malware, > die über vger.kernel.org reinkommen (die die Postmaster dort an sich auch > mal blocken könnten), die Schnauze wohl hab, hab ich jetzt mal > > # Anhänge blocken: ZIP noch dazu, weil das am häufigsten kommt. > # http://www.postfix.org/header_checks.5.html > /^Content-(Disposition|Type).*name\s*=\s*"?([^;]*(\.|=2E)( > ade|adp|asp|bas|bat|chm|cmd|com|cpl|crt|dll|exe| > hlp|ht[at]| > inf|ins|isp|jse?|lnk|md[betw]|ms[cipt]|nws| > \{[[:xdigit:]]{8}(?:-[[:xdigit:]]{4}){3}-[[:xdigit:]]{12}\}| > ops|pcd|pif|prf|reg|sc[frt]|sh[bsm]|swf| > vb[esx]?|vxd|ws[cfh]|zip))(\?=)?"?\s*(;|$)/x > REJECT Attachment name "$2" may not end with ".$4" > > in die via PCRE eingebundenen Header-Checks eingebaut. > > Aus naheliegenden Gründen möchte ich jetzt keine dieser Mails weiterleiten. > Lösch die eh gleich wieder. Soweit durch die Verwirrungstaktik in einem der > Skripte durchblicke, greift das ohnehin mal wieder nur auf Windows-Systemen. > > Diese Mails gehen seit eh und jeh bei mir sowohl an policyd-weight als auch > an SpamAssassin mit Zusatzregeln spamassassin.heinlein-support.de, > updates.spamassassin.org, sought.rules.yerp.org vorbei. > > Ich bin bei der Recherche auch auf Postscreen gestoßen und sicherlich würde > sich auch Amavis dazu eignen. Auch postgrey habe ich mir mal wieder > überlegt, jedoch kam ich bislang auch ganz gut ohne aus und mag das an sich > nicht so gerne, wenn legitime Mails um Minuten verzögert bei mir > eintreffen. > > Insgesamt möchte ich mein Mailserver-Setup auch nicht unnötig komplex > machen. Ich hab ohnehin immer mehr Komplexität hinzugefügt als eine Art > Wettrüsten mit den Spammern. Falls jemand mir ein Archiv schicken möchte, > könnte sie es immer noch irgendwo hochladen oder? ein anderes > Kompressionsformat verwenden. > > Was verwendet ihr? > > Also genau da würde mich eine aktualisierte Fassung des Postfix-Buches mit > den aktuellen Best Practice-Empfehlungen für ein einfaches, jedoch auch > äußerst wirksames Spamfilter-Setup interessieren. Natürlich dürfte das zu > einem Teil auch zum Geschäftsgeheimnis von Mail-Konto-Anbietern gehören. > > Mein Setup ist auch bereits recht wirksam, wenn ich sehe, dass pro Tag micht > mehr als ca. 20 Mails durchkommen. Ich hab keine Stastistik, aber ich gehe > davon aus, dass mein Server über 90% aller Mails auf SMTP-Ebene > zurückweist. > > (Manchmal möchte ich einfach alle Mails wegblocken oder einen Antibot > schreiben, der sämtliche schlecht abgesicherten IoT-Müll-Teile und VMs > unbrauchbar macht. Und ja, ich kann mich zurückhalten.). > > > Kandidaten, die meinen Dovecot knacken wollen, dabei jedoch dilletantisch > vorgehen, gibt es auch mal wieder: > > Apr 15 12:34:22 mondschein dovecot: pop3-login: Disconnected (tried to use > disallowed plaintext auth): user=<>, rip=49.69.121.47, lip=194.150.191.11 > > (Okay, grad mal sshguard angepasst, damit er auch das mail.log pollt.) > > Frohe Ostern, -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 833 bytes Beschreibung: This is a digitally signed message part. URL : From martin at lichtvoll.de Sat Apr 15 14:06:01 2017 From: martin at lichtvoll.de (Martin Steigerwald) Date: Sat, 15 Apr 2017 14:06:01 +0200 Subject: =?UTF-8?B?QW5ow6RuZ2U=?= blocken, z.B. ZIP-Archive mit Javascript-Malware In-Reply-To: <6157148.U9ivyKdr1f@dominik-desktop> References: <1499483.vSjfiB9zQ5@merkaba> <6157148.U9ivyKdr1f@dominik-desktop> Message-ID: <2363906.ic9TjBgxzH@merkaba> Hallo Dominik. Danke für Deine Antwort. Dominik Kupschke - 15.04.17, 13:35: > gegen ZIP Dateien mit Javascript oder Double-Extensions (invoice.pdf.exe) > verwende ich ClamAV mit den Foxhole Signaturen von Sanesecurity: > > http://sanesecurity.com/foxhole-databases/ Wie hängst Du den in Postfix ein? Direkt, via Amavis oder noch irgendwie anders? Von meiner früheren Erinnerung am Amavis-Konfiguration auf Kunden-Servern, würde ich mir dieses Teil doch lieber ersparen. SpamAssassin habe ich via spamc und header_checks eingehängt, plane dies jedoch irgendwann auf spampd umzustellen. Danke, -- Martin From dominik at kupschke.net Sat Apr 15 14:13:24 2017 From: dominik at kupschke.net (Dominik Kupschke) Date: Sat, 15 Apr 2017 14:13:24 +0200 Subject: =?UTF-8?B?QW5ow6RuZ2U=?= blocken, z.B. ZIP-Archive mit Javascript-Malware In-Reply-To: <2363906.ic9TjBgxzH@merkaba> References: <1499483.vSjfiB9zQ5@merkaba> <6157148.U9ivyKdr1f@dominik-desktop> <2363906.ic9TjBgxzH@merkaba> Message-ID: <5626171.ZxOJKgL0K2@dominik-desktop> Hallo Martin, ich verwende hierzu den clamav-milter: https://packages.debian.org/de/jessie/clamav-milter VG Dominik Am Samstag, 15. April 2017, 14:06:01 CEST schrieb Martin Steigerwald: > Hallo Dominik. > > Danke für Deine Antwort. > > Dominik Kupschke - 15.04.17, 13:35: > > gegen ZIP Dateien mit Javascript oder Double-Extensions (invoice.pdf.exe) > > verwende ich ClamAV mit den Foxhole Signaturen von Sanesecurity: > > > > http://sanesecurity.com/foxhole-databases/ > > Wie hängst Du den in Postfix ein? Direkt, via Amavis oder noch irgendwie > anders? > > Von meiner früheren Erinnerung am Amavis-Konfiguration auf Kunden-Servern, > würde ich mir dieses Teil doch lieber ersparen. > > SpamAssassin habe ich via spamc und header_checks eingehängt, plane dies > jedoch irgendwann auf spampd umzustellen. > > Danke, -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 833 bytes Beschreibung: This is a digitally signed message part. URL : From stephan.hendl at landtag.brandenburg.de Wed Apr 19 15:35:06 2017 From: stephan.hendl at landtag.brandenburg.de (Hendl Stephan) Date: Wed, 19 Apr 2017 13:35:06 +0000 Subject: Facebook und Greylisting? Message-ID: Hallo, vor einiger Zeit wurde hier über Probleme beim Empfang von Mails von "outlook.de" und Greylisting geschrieben. Für Facebook scheint das Gleiche zu gelten. Facebook hat die Sichertheitsabfragemail nach dem Einrichten eines Accounts 6 Mal über verschiedene Mailserver geschickt, ist 6 Mal temporär abgewiesen worden und hat dann aufgegeben. 69-171-232-170.outappmail.facebook.com[69.171.232.170] 69-171-232-158.outmail.facebook.com[69.171.232.158] intmgw232179.mxout.facebook.com[69.171.232.179] 66-220-155-163.outcampmail.facebook.com[66.220.155.163] 66-220-144-146.outmail.facebook.com[66.220.144.146] 66-220-155-156.outmail.facebook.com[66.220.155.156] In der "/etc/postgery/whitelist_clients" würde ich dann folgendes eintragen: /*\.outmail\.facebook\.com$/ /*\.outappmail\.facebook\.com$/ /*\.outcampmail\.facebook\.com$/ /*\.mxout\.facebook\.com$/ Oder hat jemand eine andere/bessere Idee? Viele Grüße Stephan Hendl -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From bjoern.meier at gmail.com Wed Apr 19 15:45:53 2017 From: bjoern.meier at gmail.com (Bjoern Meier) Date: Wed, 19 Apr 2017 13:45:53 +0000 Subject: Facebook und Greylisting? In-Reply-To: References: Message-ID: Hi, > 66.220.155.156] > > > > In der ?/etc/postgery/whitelist_clients? würde ich dann folgendes > eintragen: > > > > /*\.outmail\.facebook\.com$/ > > /*\.outappmail\.facebook\.com$/ > > /*\.outcampmail\.facebook\.com$/ > > /*\.mxout\.facebook\.com$/ > > > jemand hier auf der Liste hat mir geraten eher eine Graylist-Klase zu machen. Quasi der umgekehrte Weg. Die FQDNs und IPs festzulegen die unter graylisting kommen. smtpd_restriction_classes = greylisting check_client_access pcre:/etc/postfix/maps/dialups.grey mit Inhalt /(\-.+){4}$/ greylisting /(\..+){4}$/ greylisting # everything with 3 or more dots/hyphens in the hostname /(^|[0-9.x_-])(abo|br(e|oa)dband|cabel|(hk)?cablep?|catv|cbl|cidr|d?client2?|cust(omer)?s?|dhcp|dial?(in|up)?|d[iu]p|[asx]?dsld?|dyn(a(dsl|mic)?)?|home|in-addr|modem(cable)?|(di)?pool|ppp|ptr|rev|static|user|YahooBB[0-9]{12}|c[[:alnum:]]{6,}(\.[a-z]{3})?\.virtua|[1-9]Cust[0-9]+|AC[A-Z][0-9A-F]{5}\.ipt|pcp[0-9]{6,}pcs|S0106[[:alnum:]]{12,}\.[a-z]{2})[0-9.x_-]/ greylisting /(\.si$|\.ru$|\.br$|\.sk$|\.pe$|\.ro$|\.eg$|\.in$|\.lv$|\.gr$|\.za$|\.net$|\.com$|\.br$|\.jp$|\.co$|\.in$|\.il$|\.it$|\.co$|\.mx$|\.pl$|\.pt$|\.ua$|\.ar$|\.th$|\.cz$|\.no$|\.th$|\.nl$|\.cy$|\.ma$|\.nu$|\.ee$|\.pe$|\.se$)/ greylisting /unknown/ greylisting Gruß, Björn -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From klaus at tachtler.net Wed Apr 19 15:46:10 2017 From: klaus at tachtler.net (Klaus Tachtler) Date: Wed, 19 Apr 2017 15:46:10 +0200 Subject: Frage zu SpamAssassin-Regeln von spamassassin.heinlein-support.de Message-ID: <20170419154610.Horde.njSF739zoBqclQQAYEEv4AM@buero.tachtler.net> Hallo Liste, hallo Peer, werden die Regelsätze, welche via --> # sa-update --nogpg --channel spamassassin.heinlein-support.de bezogen werden können noch gepflegt? Gibt es auch einen GPG-Schlüssel dazu, denn unter dem CentOS-7 Konfigurations-Skript zu sa-update /usr/share/spamassassin/sa-update.cron --> werden Konfigurationen im Ordner /etc/mail/spamassassin/channel.d/ gesucht, welche dann z.B. so aussehen: # cat /etc/mail/spamassassin/channel.d/sought.conf # http://wiki.apache.org/spamassassin/SoughtRules CHANNELURL=sought.rules.yerp.org KEYID=6C6191E3 # Ignore everything below. return 0 ... Vielen Dank schon in Voraus! Klaus. -- ------------------------------------------ e-Mail : klaus at tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.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 driessen at fblan.de Wed Apr 19 15:50:57 2017 From: driessen at fblan.de (=?iso-8859-1?Q?Uwe_Drie=DFen?=) Date: Wed, 19 Apr 2017 15:50:57 +0200 Subject: AW: Facebook und Greylisting? In-Reply-To: References: Message-ID: <00f701d2b913$f8c939e0$ea5bada0$@fblan.de> Im Auftrag von Hendl Stephan > > Hallo, > > > > vor einiger Zeit wurde hier über Probleme beim Empfang von Mails von > „outlook.de“ und Greylisting geschrieben. Für Facebook scheint das Gleiche > zu gelten. Facebook hat die Sichertheitsabfragemail nach dem Einrichten > eines Accounts 6 Mal über verschiedene Mailserver geschickt, ist 6 Mal > temporär abgewiesen worden und hat dann aufgegeben. > Das ist aber auch nicht unbedingt Standardkonform Da gilt das erstgesagte erst recht (es sei denn die haben für die 6 Zustellung 4 Tage benötigt wobei ich mich frage warum die dann so lange brauchen). Das da immer ein paar meinen am Standard vorbei zu agieren und andere für sich Ohne Bezahlung arbeiten lassen. Anders kann man sich aber auch deren Gewinne nicht erklären :-)) 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 Apr 19 15:46:55 2017 From: driessen at fblan.de (=?iso-8859-1?Q?Uwe_Drie=DFen?=) Date: Wed, 19 Apr 2017 15:46:55 +0200 Subject: AW: Facebook und Greylisting? In-Reply-To: References: Message-ID: <00f601d2b913$68fbdf20$3af39d60$@fblan.de> Im Auftrag von Hendl Stephan > Betreff: Facebook und Greylisting? > > Oder hat jemand eine andere/bessere Idee? > > Nicht mit Facebook kommunizieren :-) Ich sag da immer wenn die es nicht können ..... muss ich es auch nicht können. Wenn du auf die Mails angewiesen bist musst du ausnahmen schreiben. Da reicht doch dann auch ein Eintrag /\.facebook\.com$/ 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 news at amaltea.de Thu Apr 20 09:52:50 2017 From: news at amaltea.de (Paul) Date: Thu, 20 Apr 2017 09:52:50 +0200 Subject: Facebook und Greylisting? In-Reply-To: <00f601d2b913$68fbdf20$3af39d60$@fblan.de> References: <00f601d2b913$68fbdf20$3af39d60$@fblan.de> Message-ID: <5891aab3-82f7-1ac6-66f6-0ca1f81eec42@amaltea.de> Am 19.04.2017 um 15:46 schrieb Uwe Drießen: > Im Auftrag von Hendl Stephan >> Betreff: Facebook und Greylisting? >> >> Oder hat jemand eine andere/bessere Idee? >> > > Wenn du auf die Mails angewiesen bist musst du ausnahmen schreiben. > > Da reicht doch dann auch ein Eintrag > > /\.facebook\.com$/ Einfach nur facebook.com müsste doch auch reichen, oder? > Mit freundlichen Grüßen > > Uwe Drießen From Ralf.Hildebrandt at charite.de Thu Apr 20 11:23:10 2017 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Thu, 20 Apr 2017 11:23:10 +0200 Subject: Frage zu SpamAssassin-Regeln von spamassassin.heinlein-support.de In-Reply-To: <20170419154610.Horde.njSF739zoBqclQQAYEEv4AM@buero.tachtler.net> References: <20170419154610.Horde.njSF739zoBqclQQAYEEv4AM@buero.tachtler.net> Message-ID: <20170420092309.dblqurvpkywa6qas@charite.de> * Klaus Tachtler : > Hallo Liste, > hallo Peer, > > werden die Regelsätze, welche via --> > > # sa-update --nogpg --channel spamassassin.heinlein-support.de > > bezogen werden können noch gepflegt? Ich hatte den (nicht tiefer geprüften) Eindruck, die wären "stale". -- 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 ms at ddnetservice.de Thu Apr 20 12:28:42 2017 From: ms at ddnetservice.de (Michael Seevogel) Date: Thu, 20 Apr 2017 12:28:42 +0200 Subject: Frage zu SpamAssassin-Regeln von spamassassin.heinlein-support.de In-Reply-To: <20170420092309.dblqurvpkywa6qas@charite.de> References: <20170419154610.Horde.njSF739zoBqclQQAYEEv4AM@buero.tachtler.net> <20170420092309.dblqurvpkywa6qas@charite.de> Message-ID: Am 20.04.2017 um 11:23 schrieb Ralf Hildebrandt: > * Klaus Tachtler : >> Hallo Liste, >> hallo Peer, >> >> werden die Regelsätze, welche via --> >> >> # sa-update --nogpg --channel spamassassin.heinlein-support.de >> >> bezogen werden können noch gepflegt? > > Ich hatte den (nicht tiefer geprüften) Eindruck, die wären "stale". > Das ein oder andere Update gab es schon in der jüngsten Vergangenheit, so ist es ja nicht. Aber ein gewisser Trend zu einer abnehmenden "Aktualisierungsintensität" der Regeln beobachte ich auch schon seit einiger Zeit. Bzgl des letzten Updates vom 13.04: Man darf auch nicht vergessen dass wir jetzt gerade erst Ostern hatten und der/die Person(en) die diese Regeln pflegt, eventuell auch gerade im "Urlaub" ist... Darüber hinaus kann man auch mal seine Dankbarkeit zeigen, denn solche Regelsätze zu erstellen/pflegen und kostenlos bereitzustellen ist nicht selbstverständlich. Wer selbst regelmäßig SA-Regeln schreibt, dürfte bzgl des Aufwand wissen was ich meine ;-) Beste Grüße Michael Seevogel From claas.goltz at rock-bunker.de Mon Apr 24 15:51:57 2017 From: claas.goltz at rock-bunker.de (Claas Goltz) Date: Mon, 24 Apr 2017 15:51:57 +0200 (CEST) Subject: Image only spam Message-ID: <1380771818.29.1493041917669@rock-bunker.de> Hallo! Es kommt von Zeit zu Zeit immer mal wieder vor, dass Spam Mails, die nur ein Bild mit Werbung enthalten, es durch meine Filter schaffen (amavis mit sa). Die bekommen zwar schon einen relativ hohen score, aber eben nicht genug, ab 5.2 blockiere ich die E-Mails. Mein erster Gedanke ist, dass ich einfach die Scores von HTML_IMAGE_ONLY erhöhe, aber da weiß ich leider nicht, welche Stellschraube da die Richtige ist. Meint ihr, dass ist der Richtige weg? Und wenn ja, was würdet ihr da empfehlen? Danke! Hier der Auszug der /var/lib/spamassassin/3.004000/updates_spamassassin_org/50_scores.cf score HTML_IMAGE_ONLY_04 1.680 0.342 1.799 1.172 score HTML_IMAGE_ONLY_08 0.585 1.781 1.845 1.651 score HTML_IMAGE_ONLY_12 1.381 1.629 1.400 2.059 score HTML_IMAGE_ONLY_16 1.969 1.048 1.199 1.092 score HTML_IMAGE_ONLY_20 2.109 0.700 1.300 1.546 score HTML_IMAGE_ONLY_24 2.799 1.282 1.328 1.618 score HTML_IMAGE_ONLY_28 2.799 0.726 1.512 1.404 score HTML_IMAGE_ONLY_32 2.196 0.001 1.172 0.001 score HTML_IMAGE_RATIO_02 2.199 0.805 1.200 0.437 score HTML_IMAGE_RATIO_04 2.089 0.610 0.607 0.556 score HTML_IMAGE_RATIO_06 0.001 0.001 0.001 0.001 score HTML_IMAGE_RATIO_08 0.001 0.001 0.001 0.001 Beispiel E-Mail: Received: from ex02.localdomain.de (x.x.x.x) by ex01.localdomain.de (x.x.x.x) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34 via Mailbox Transport; Mon, 24 Apr 2017 13:55:34 +0200 Received: from mx1.localdomain.de (x.x.x.x) by ex02.localdomain.de (x.x.x.x) with Microsoft SMTP Server (TLS) id 15.1.466.34; Mon, 24 Apr 2017 13:55:34 +0200 Received: from localhost (localhost [127.0.0.1]) by mx1.localdomain.de (Postfix) with ESMTP id 1BE47FF2F3 for ; Mon, 24 Apr 2017 13:55:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mx1.localdomain.de X-Spam-Flag: NO X-Spam-Score: 4.797 X-Spam-Level: **** X-Spam-Status: No, score=4.797 tagged_above=-999 required=5.2 tests=[HTML_IMAGE_ONLY_04=0.342, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.139, MPART_ALT_DIFF=0.724, RCVD_IN_BRBL_LASTEXT=1.644, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_ABUSE_SURBL=1.948, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mx1.localdomain.de ([IPv6:::1]) by localhost (mx1.localdomain.de [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id m76-z8EjAC2e for ; Mon, 24 Apr 2017 13:55:38 +0200 (CEST) Received: from mail.htcforum.eu (mail.htcforum.eu [163.172.221.180]) by mx1.localdomain.de (Postfix) with ESMTP for ; Mon, 24 Apr 2017 13:55:38 +0200 (CEST) Received: from htcforum.eu (mail.htcforum.eu [163.172.221.180]) by mail.htcforum.eu (Postfix) with ESMTPA id F0332215573C; Mon, 24 Apr 2017 06:05:22 +0300 (EEST) Message-ID: <1f7601d2bcc0$c4dee390$ea2b73a0 at uhvanrq> Reply-To: Passionpharm From: Passionpharm To: Subject: Angebot der Woche! Date: Mon, 24 Apr 2017 06:05:26 +0300 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01D2BCC0.B7951830" X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 Return-Path: uhvanrq at htcforum.eu X-MS-Exchange-Organization-Network-Message-Id: 6db10c63-64d3-4422-444f-08d48b08d0b7 X-MS-Exchange-Organization-AuthSource: ex02.localdomain.de X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Transport-EndToEndLatency: 00:00:00.0926630 MIME-Version: 1.0 postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no bounce_queue_lifetime = 3d broken_sasl_auth_clients = yes check_greylist = check_policy_service inet:127.0.0.1:10023 config_directory = /etc/postfix cyrus_sasl_config_path = /etc/postfix/sasl inet_interfaces = all maximal_queue_lifetime = 3d message_size_limit = 41943040 myorigin = /etc/mailname readme_directory = no relay_domains = hash:/etc/postfix/relay_domains, smtp_helo_name = mx0.contact.de smtp_tls_CAfile = /etc/postfix/ssl/CAcert.pem smtp_tls_cert_file = /etc/postfix/ssl/cert-2017.pem smtp_tls_key_file = /etc/postfix/ssl/key-2017.pem smtp_tls_security_level = may smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) 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, 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 smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = no smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = noanonymous smtpd_tls_CAfile = /etc/postfix/ssl/CAcert.pem smtpd_tls_auth_only = no smtpd_tls_cert_file = /etc/postfix/ssl/cert-2017.pem smtpd_tls_key_file = /etc/postfix/ssl/key-2017.pem smtpd_tls_security_level = may transport_maps = hash:/etc/postfix/transport_maps, $relay_domains unverified_recipient_reject_code = 599 -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From Ralf.Hildebrandt at charite.de Mon Apr 24 16:48:07 2017 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Mon, 24 Apr 2017 16:48:07 +0200 Subject: Image only spam In-Reply-To: <1380771818.29.1493041917669@rock-bunker.de> References: <1380771818.29.1493041917669@rock-bunker.de> Message-ID: <20170424144807.3phnxsnm7hamcqf3@charite.de> * Claas Goltz : > Hallo! > Es kommt von Zeit zu Zeit immer mal wieder vor, dass Spam Mails, die nur ein Bild mit Werbung enthalten, es durch meine Filter schaffen (amavis mit sa). Die bekommen zwar schon einen relativ hohen score, aber eben nicht genug, ab 5.2 blockiere ich die E-Mails. Mein erster Gedanke ist, dass ich einfach die Scores von HTML_IMAGE_ONLY erhöhe, aber da weiß ich leider nicht, welche Stellschraube da die Richtige ist. Meint ihr, dass ist der Richtige weg? Und wenn ja, was würdet ihr da empfehlen? Das OCR Plugin :) -- 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 kai_postfix at fuerstenberg.ws Mon Apr 24 16:42:27 2017 From: kai_postfix at fuerstenberg.ws (=?UTF-8?Q?Kai_F=c3=bcrstenberg?=) Date: Mon, 24 Apr 2017 16:42:27 +0200 Subject: Image only spam In-Reply-To: <1380771818.29.1493041917669@rock-bunker.de> References: <1380771818.29.1493041917669@rock-bunker.de> Message-ID: <75d05354-a011-fa21-9bfd-86feab0d5c7c@fuerstenberg.ws> Hi Claas, Am 24.04.2017 um 15:51 schrieb Claas Goltz: > Hallo! > Es kommt von Zeit zu Zeit immer mal wieder vor, dass Spam Mails, die nur > ein Bild mit Werbung enthalten, es durch meine Filter schaffen (amavis > mit sa). Die bekommen zwar schon einen relativ hohen score, aber eben > nicht genug, ab 5.2 blockiere ich die E-Mails. Mein erster Gedanke ist, > dass ich einfach die Scores von HTML_IMAGE_ONLY erhöhe, aber da weiß ich > leider nicht, welche Stellschraube da die Richtige ist. Meint ihr, dass > ist der Richtige weg? Und wenn ja, was würdet ihr da empfehlen? früher gab es für sowas FuzzyOCR, das Projekt ist aber wohl eingeschlafen. Evtl. funktioniert das hier aber: https://wiki.apache.org/spamassassin/OcrPlugin Ich selbst habe es nicht am laufen, da bei mir nicht so viel Image-Only-Spam aufschlägt. -- Kai Fürstenberg PM an: kai at fuerstenberg punkt ws From ms at ddnetservice.de Mon Apr 24 16:48:38 2017 From: ms at ddnetservice.de (ms at ddnetservice.de) Date: Mon, 24 Apr 2017 16:48:38 +0200 Subject: Image only spam In-Reply-To: <1380771818.29.1493041917669@rock-bunker.de> References: <1380771818.29.1493041917669@rock-bunker.de> Message-ID: <9173d78c-25eb-ef0e-00ea-cdf850f29f32@ddnetservice.de> Am 24.04.2017 um 15:51 schrieb Claas Goltz: > Hallo! > Es kommt von Zeit zu Zeit immer mal wieder vor, dass Spam Mails, die nur > ein Bild mit Werbung enthalten, es durch meine Filter schaffen (amavis > mit sa). Die bekommen zwar schon einen relativ hohen score, aber eben > nicht genug, ab 5.2 blockiere ich die E-Mails. Mein erster Gedanke ist, > dass ich einfach die Scores von HTML_IMAGE_ONLY erhöhe, aber da weiß ich > leider nicht, welche Stellschraube da die Richtige ist. Meint ihr, dass > ist der Richtige weg? Und wenn ja, was würdet ihr da empfehlen? Moin, HTML_IMAGE_ONLY_04 zu erhöhen wäre auf den ersten Blick natürlich die logische Konsequenz. Allerdings kann man damit auch die false-positive Rate ordentlich nach oben treiben. Meiner Meinung nach sind hier Meta Rules die bessere Variante, um solchen Spam-Mails Herr zu werden. Die folgende Meta Rule sollte eigentlich diesen Spam erkennen: > mimeheader __DD_CYRILLIC_SPAM_01 content-type =~ /charset=\"windows-1251\"/i > meta DD_CYRILLIC_01 (__DD_CYRILLIC_SPAM_01 && HTML_IMAGE_ONLY_04) > score DD_CYRILLIC_01 6.75 Erklärung: Wenn der Mimeheader windows-1251 (also kyrillisch) ist und HTML_IMAGE_ONLY_04 auch vom SA erkannt wurde, dann wird entsprechend "gescored". Man kann natürlich die Meta Rule noch um weitere Tests erweitern, aber eigentlich sollte das so schon ausreichen. Bei mir sortiert die Rule diese Art von Spam seit 2-3 Jahren zuverlässig aus. Beste Grüße Michael Seevogel From postfixbuch at cboltz.de Mon Apr 24 18:45:09 2017 From: postfixbuch at cboltz.de (Christian Boltz) Date: Mon, 24 Apr 2017 18:45:09 +0200 Subject: Image only spam In-Reply-To: <1380771818.29.1493041917669@rock-bunker.de> References: <1380771818.29.1493041917669@rock-bunker.de> Message-ID: <2040626.7jSfytDorQ@tux.boltz.de.vu> Hallo Claas, hallo zusammen, Am Montag, 24. April 2017, 15:51:57 CEST schrieb Claas Goltz: > URIBL_BLOCKED=0.001 Das sieht nach der passenden Stellschraube aus. Du willst einen eigenen Nameserver (statt des Provider-Nameservers) betreiben, damit Dich URIBL mit sinnvollen Ergebnissen versorgt ;-) URIBL_BLACK und URIBL_DBL_SPAM sind recht zuverlässige Spam-Indikatoren und erwischen nur sehr selten (!= nie) Ham. Ggf. kannst Du die Scores dafür also etwas hochdrehen. Gruß Christian Boltz -- [Need tool to uncover Rootkits] Our approach is not to let rootkits enter the system :) [Marcus Meissner in https://bugzilla.novell.com/show_bug.cgi?id=199078] From t.berthel at gmx.net Mon Apr 24 19:31:34 2017 From: t.berthel at gmx.net (t.berthel at gmx.net) Date: Mon, 24 Apr 2017 19:31:34 +0200 Subject: warning: hostname foo.bar.us does not resolve to address IP-Adresse : Temporary failure in name resolution Message-ID: Hallo, ich habe ein Problem mit SPAMs die leider zugestellt werden obwohl hier ein Fehler besteht. Ich habe keine Ahnung wo ich noch suchen soll. Im Moment habe ich mir geholfen indem ich die IP sperre, jedoch geht der Bot immer eine IP weiter nach oben. Den Hoster habe ich auch schon darüber informiert, jedoch ist es wohl bei mir auch noch ein Failure by design den ich finden sollte um diese Art von SPAMS abhalten zu können. Was könnte hier der Grund sein, dass dieser Müll es schafft durchzukommen? Meine aktuelle config ist hier zu finden: https://listi.jpberlin.de/pipermail/postfixbuch-users/2017-January/064908.html Hier mal ein Logauszug bevor ich es blockiert habe: Apr 24 04:43:19 MAIL-GATEWAY postfix/smtpd[9824]: warning: hostname jake.metamug.us does not resolve to address 66.23.212.136: Temporary failure in name resolution Apr 24 17:07:58 MAIL-GATEWAY postfix/smtpd[4988]: warning: hostname shone.touchrs.us does not resolve to address 66.23.212.138: Temporary failure in name resolution Apr 24 17:08:46 MAIL-GATEWAY postfix/smtpd[4988]: warning: hostname shone.touchrs.us does not resolve to address 66.23.212.138: Temporary failure in name resolution Apr 24 17:10:36 MAIL-GATEWAY postfix/smtpd[5292]: warning: hostname shone.touchrs.us does not resolve to address 66.23.212.138: Temporary failure in name resolution Apr 24 17:51:56 MAIL-GATEWAY postfix/smtpd[6618]: warning: hostname grief.naminen.us does not resolve to address 66.23.212.139: Temporary failure in name resolution Apr 24 17:52:26 MAIL-GATEWAY postfix/smtpd[6618]: warning: hostname grief.naminen.us does not resolve to address 66.23.212.139: Temporary failure in name resolution Hier der incoming: Apr 24 17:08:46 MAIL-GATEWAY postfix/smtpd[4988]: warning: hostname shone.touchrs.us does not resolve to address 66.23.212.138: Temporary failure in name resolution Apr 24 17:08:46 MAIL-GATEWAY postfix/smtpd[4988]: connect from unknown[66.23.212.138] Apr 24 17:08:49 MAIL-GATEWAY postfix/smtpd[4988]: 164741CA010: client=unknown[66.23.212.138] Apr 24 17:08:50 MAIL-GATEWAY postfix/cleanup[5103]: 164741CA010: message-id=<8jFpiAWJoMy1mThcwtsVV2laD_lvBjefvYGV3BxLE0s.bgzvMX0f9hYw4MdPWeOb12NKnp_NKJ72XcC-cQg6LyI at hsome.stream> Apr 24 17:08:52 MAIL-GATEWAY postfix/qmgr[2306]: 164741CA010: from=, size=45412, nrcpt=1 (queue active) Apr 24 17:08:52 MAIL-GATEWAY amavis[5152]: (05152-02) LMTP :10024 /var/amavis/tmp/amavis-20170424T170828-05152-jCbBZM7U: -> SIZE=45412 BODY=8BITMIME Received: from Domain.de ([127.0.0.1]) by localhost (Domain.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP for ; Mon, 24 Apr 2017 17:08:52 +0200 (CEST) Apr 24 17:08:52 MAIL-GATEWAY amavis[5152]: (05152-02) Checking: S4K4TcW0Pw_J [66.23.212.138] -> Apr 24 17:08:52 MAIL-GATEWAY postfix/smtpd[4988]: disconnect from unknown[66.23.212.138] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 Apr 24 17:08:53 MAIL-GATEWAY amavis[5152]: (05152-02) spam-tag, -> , No, score=0.156 required=3 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RDNS_NONE=0.793, T_REMOTE_IMAGE=0.01, URIBL_ABUSE_SURBL=1.25, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Apr 24 17:08:53 MAIL-GATEWAY postfix/smtpd[5106]: EA3181CA051: client=localhost[127.0.0.1], orig_queue_id=164741CA010, orig_client=unknown[66.23.212.138] Apr 24 17:08:53 MAIL-GATEWAY postfix/cleanup[5103]: EA3181CA051: message-id=<8jFpiAWJoMy1mThcwtsVV2laD_lvBjefvYGV3BxLE0s.bgzvMX0f9hYw4MdPWeOb12NKnp_NKJ72XcC-cQg6LyI at hsome.stream> Apr 24 17:08:53 MAIL-GATEWAY postfix/smtpd[5106]: disconnect from localhost[127.0.0.1] ehlo=1 xforward=2 mail=2 rcpt=2 data=2 noop=1 quit=1 commands=11 Apr 24 17:08:53 MAIL-GATEWAY postfix/qmgr[2306]: EA3181CA051: from=, size=46153, nrcpt=1 (queue active) Apr 24 17:08:53 MAIL-GATEWAY amavis[5152]: (05152-02) S4K4TcW0Pw_J FWD from -> , BODY=7BIT 250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as EA3181CA051 Apr 24 17:08:54 MAIL-GATEWAY amavis[5152]: (05152-02) Passed CLEAN {RelayedInbound}, [66.23.212.138]:8920 [66.23.212.138] -> , Queue-ID: 164741CA010, Message-ID: <8jFpiAWJoMy1mThcwtsVV2laD_lvBjefvYGV3BxLE0s.bgzvMX0f9hYw4MdPWeOb12NKnp_NKJ72XcC-cQg6LyI at hsome.stream>, mail_id: S4K4TcW0Pw_J, Hits: 0.156, size: 45302, queued_as: EA3181CA051, 1471 ms Apr 24 17:08:54 MAIL-GATEWAY amavis[5152]: (05152-02) TIMING-SA [total 1309 ms, cpu 753 ms] - parse: 3.1 (0.2%), extract_message_metadata: 51 (3.9%), get_uri_detail_list: 7 (0.6%), tests_pri_-1000: 7 (0.5%), tests_pri_-950: 0.64 (0.0%), tests_pri_-900: 0.67 (0.1%), tests_pri_-400: 58 (4.5%), check_bayes: 58 (4.4%), b_tokenize: 20 (1.6%), b_tok_get_all: 30 (2.3%), b_comp_prob: 4.1 (0.3%), b_tok_touch_all: 0.35 (0.0%), b_finish: 0.55 (0.0%), tests_pri_0: 1175 (89.7%), check_dkim_signature: 1.23 (0.1%), check_dkim_adsp: 70 (5.3%), check_spf: 0.25 (0.0%), check_razor2: 648 (49.5%), check_pyzor: 0.14 (0.0%), tests_pri_500: 4.0 (0.3%), get_report: 0.58 (0.0%) Apr 24 17:08:54 MAIL-GATEWAY postfix/lmtp[5104]: 164741CA010: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=6, delays=4.5/0/0/1.5, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as EA3181CA051) Apr 24 17:08:54 MAIL-GATEWAY amavis[5152]: (05152-02) size: 45302, TIMING [total 1475 ms, cpu 780 ms, AM-cpu 27 ms, SA-cpu 753 ms] - SMTP greeting: 1.6 (0%)0, SMTP LHLO: 0.6 (0%)0, SMTP pre-MAIL: 0.6 (0%)0, SMTP pre-DATA-flush: 2.1 (0%)0, SMTP DATA: 37 (2%)3, check_init: 0.4 (0%)3, digest_hdr: 0.3 (0%)3, digest_body: 0.4 (0%)3, collect_info: 1.4 (0%)3, check_header: 1.1 (0%)3, AV-scan-1: 58 (4%)7, spam-wb-list: 0.5 (0%)7, SA msg read: 0.4 (0%)7, SA parse: 3.4 (0%)7, SA check: 1304 (88%)96, decide_mail_destiny: 4.8 (0%)96, notif-quar: 0.4 (0%)96, fwd-connect: 3.0 (0%)96, fwd-xforward: 0.4 (0%)96, fwd-mail-pip: 1.2 (0%)96, fwd-rcpt-pip: 0.2 (0%)96, fwd-data-chkpnt: 0.1 (0%)96, write-header: 0.3 (0%)96, fwd-data-contents: 1.0 (0%)97, fwd-end-chkpnt: 41 (3%)99, prepare-dsn: 0.6 (0%)99, report: 1.2 (0%)99, main_log_entry: 4.8 (0%)100, update_snmp: 2.0 (0%)100, SMTP pre-response: 0.3 (0%)100, SMTP response: 0.2 (0%)100, unlink-1-files: 0.2 (0%)100, rundown: 0.6 (0%)100 Apr 24 17:08:54 MAIL-GATEWAY amavis[5152]: (05152-02) size: 45302, RUSAGE minflt=144+0, majflt=0+0, nswap=0+0, inblock=0+0, oublock=264+0, msgsnd=0+0, msgrcv=0+0, nsignals=0+0, nvcsw=21+0, nivcsw=3+0, maxrss=88176+0, ixrss=0+0, idrss=0+0, isrss=0+0, utime=0.773+0.000, stime=0.007+0.000 Apr 24 17:08:54 MAIL-GATEWAY postfix/qmgr[2306]: 164741CA010: removed Apr 24 17:08:54 MAIL-GATEWAY postfix/smtp[5107]: EA3181CA051: to=, relay=MAIL-SERVER-IP[MAIL-SERVER-IP]:25, delay=0.11, delays=0.04/0/0/0.06, dsn=2.6.0, status=sent (250 2.6.0 <8jFpiAWJoMy1mThcwtsVV2laD_lvBjefvYGV3BxLE0s.bgzvMX0f9hYw4MdPWeOb12NKnp_NKJ72XcC-cQg6LyI at hsome.stream> Queued mail for delivery) Apr 24 17:08:54 MAIL-GATEWAY postfix/qmgr[2306]: EA3181CA051: removed Um ein paar Tipps wäre ich dennoch sehr dankbar! VG From Ralf.Hildebrandt at charite.de Mon Apr 24 21:55:47 2017 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Mon, 24 Apr 2017 21:55:47 +0200 Subject: Image only spam In-Reply-To: <2040626.7jSfytDorQ@tux.boltz.de.vu> References: <1380771818.29.1493041917669@rock-bunker.de> <2040626.7jSfytDorQ@tux.boltz.de.vu> Message-ID: <20170424195543.ls5cdr3rytfvqyrw@charite.de> * Christian Boltz : > Hallo Claas, hallo zusammen, > > Am Montag, 24. April 2017, 15:51:57 CEST schrieb Claas Goltz: > > URIBL_BLOCKED=0.001 > > Das sieht nach der passenden Stellschraube aus. > > Du willst einen eigenen Nameserver (statt des Provider-Nameservers) > betreiben, damit Dich URIBL mit sinnvollen Ergebnissen versorgt ;-) Korrekt Aber man darf halt nicht zuviel Abfragen machen... -- 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 claas.goltz at rock-bunker.de Tue Apr 25 07:55:08 2017 From: claas.goltz at rock-bunker.de (Claas Goltz) Date: Tue, 25 Apr 2017 07:55:08 +0200 (CEST) Subject: Image only spam In-Reply-To: <20170424195543.ls5cdr3rytfvqyrw@charite.de> References: <1380771818.29.1493041917669@rock-bunker.de> <2040626.7jSfytDorQ@tux.boltz.de.vu> <20170424195543.ls5cdr3rytfvqyrw@charite.de> Message-ID: <1121816680.44.1493099708436@mail.rock-bunker.de> Hallo! Danke für den Hinweis, URIBL scheint in der tat erst mal die beste Stellschraube zu sein. Ich habe den Score geringfügig erhöht und werde es beobachten. Von den OCR Plugins hatte ich auch schon gelesen, aber da hat es mich abgeschreckt, das teilweise mehr als 6-7 Jahre keine Weiterentwicklung stattfand. Daher dachte ich, dass OCR nun aus der Mode gekommen ist. Also, ich beobachte erstmal weiter und wenn es nicht reicht, werde ich die community nochmal um Rat fragen! Danke an alle beteiligten. - Claas > Ralf Hildebrandt hat am 24. April 2017 um 21:55 geschrieben: > > > * Christian Boltz : > > Hallo Claas, hallo zusammen, > > > > Am Montag, 24. April 2017, 15:51:57 CEST schrieb Claas Goltz: > > > URIBL_BLOCKED=0.001 > > > > Das sieht nach der passenden Stellschraube aus. > > > > Du willst einen eigenen Nameserver (statt des Provider-Nameservers) > > betreiben, damit Dich URIBL mit sinnvollen Ergebnissen versorgt ;-) > > Korrekt > > Aber man darf halt nicht zuviel Abfragen machen... > -- > 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 > -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From Helge.Wiethoff at thga.de Tue Apr 25 10:15:38 2017 From: Helge.Wiethoff at thga.de (Wiethoff, Helge) Date: Tue, 25 Apr 2017 08:15:38 +0000 Subject: Dialups-greylisting Message-ID: <194290040642FB4D952083D79F7F7D1D414B7070@BOHEMSX2010.rbbk.de> Hallo zusammen, am Mittwoch, 19. April 2017 15:46 hat Bjoern Meier hier auf der Liste den Vorschlag geschrieben, nur die Dialups über greylisting zu schicken: > jemand hier auf der Liste hat mir geraten eher eine Graylist-Klasse zu > machen. Quasi der umgekehrte Weg. Die FQDNs und IPs festzulegen die unter > graylisting kommen. Die entsprechende Konfiguration auch aus Bjoerns Mail: > smtpd_restriction_classes = greylisting > check_client_access pcre:/etc/postfix/maps/dialups.grey > > mit Inhalt > /(\-.+){4}$/ greylisting > /(\..+){4}$/ greylisting > # everything with 3 or more dots/hyphens in the hostname > > /(^|[0-9.x_-])(abo|br(e|oa)dband|cabel|(hk)?cablep?|catv|cbl|cidr| > d?client2?|cust(omer)?s?|dhcp|dial?(in|up)?|d[iu]p|[asx]?dsld?|dyn(a(dsl > |mic)?)?|home|in-addr|modem(cable)?|(di)?pool|ppp|ptr|rev|static|user| > YahooBB[0-9]{12}|c[[:alnum:]]{6,}(\.[a-z]{3})?\.virtua|[1-9]Cust[0-9]+|AC > [A-Z][0-9A-F]{5}\.ipt|pcp[0-9]{6,}pcs|S0106[[:alnum:]]{12,}\.[a-z]{2}) > [0-9.x_-]/ greylisting > > /(\.si$|\.ru$|\.br$|\.sk$|\.pe$|\.ro$|\.eg$|\.in$|\.lv$|\.gr$|\.za$| > \.net$|\.com$|\.br$|\.jp$|\.co$|\.in$|\.il$|\.it$|\.co$|\.mx$|\.pl$| > \.pt$|\.ua$|\.ar$|\.th$|\.cz$|\.no$|\.th$|\.nl$|\.cy$|\.ma$|\.nu$| > \.ee$|\.pe$|\.se$)/ greylisting > > /unknown/ greylisting Ich finde die Idee interessant, da es bei Mailgateways mit wenigen Nutzern (auch mit max-age=365 zB) eher zu Verzögerungen in der Zustellung kommen kann. Hat jemand positive wie negative Erfahrungen zum blacklisting im greylisting? Viele Grüße aus Bochum, Helge From sebastian at karotte.org Tue Apr 25 11:16:13 2017 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Tue, 25 Apr 2017 11:16:13 +0200 Subject: warning: hostname foo.bar.us does not resolve to address IP-Adresse : Temporary failure in name resolution In-Reply-To: References: Message-ID: <20170425091613.GA26280@danton.fire-world.de> * t.berthel at gmx.net [2017-04-24 19:31]: > Hallo, > > ich habe ein Problem mit SPAMs die leider zugestellt werden obwohl hier ein Fehler besteht. > Ich habe keine Ahnung wo ich noch suchen soll. Im Moment habe ich mir geholfen indem ich die IP sperre, jedoch geht der Bot immer eine IP weiter nach oben. Den Hoster habe ich auch schon darüber informiert, jedoch ist es wohl bei mir auch noch ein Failure by design den ich finden sollte um diese Art von SPAMS abhalten zu können. > > Was könnte hier der Grund sein, dass dieser Müll es schafft durchzukommen? Hi, du hast ja schon reject_unknown_reverse_client_hostname in deiner config, ich könnte mir nur vorstellen, dass irgendwo in check_client_access hash:/etc/postfix/smtpd_access, check_client_access hash:/etc/postfix/tld_access, ein whitelisting erfolgt das nicht beabsichtigt ist? Gruß Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From t.berthel at gmx.net Tue Apr 25 12:45:11 2017 From: t.berthel at gmx.net (t.berthel at gmx.net) Date: Tue, 25 Apr 2017 12:45:11 +0200 Subject: warning: hostname foo.bar.us does not resolve to address IP-Adresse : Temporary failure in name resolution Message-ID: Hallo und danke für deine Antwort. > du hast ja schon reject_unknown_reverse_client_hostname in deiner > config, ich könnte mir nur vorstellen, dass irgendwo in > check_client_access hash:/etc/postfix/smtpd_access, > check_client_access hash:/etc/postfix/tld_access, > ein whitelisting erfolgt das nicht beabsichtigt ist? Ich habe meine withlists alle auf die Möglichkeiten hin geprüft, jedoch keinen Fehleintrag gefunden. Erst nachdem ich die IP in meine Liste smtpd_access hinterlegt hatte wurde diese wie gewünscht blockiert. Aber da sehe ich mich "Don Quijote" vor der Windmühle wenn ich das immer befüllen darf ;) Jetzt habe ich einen neuen Fall aus Received: from xpijn.yandex.ru (unknown [14.162.204.43]): Apr 25 12:10:55 MAIL-GATEWAY postfix/smtpd[15724]: warning: hostname static.vnpt.vn does not resolve to address 14.162.204.43 Apr 25 12:10:55 MAIL-GATEWAY postfix/smtpd[15724]: connect from unknown[14.162.204.43] Apr 25 12:10:59 MAIL-GATEWAY postfix/smtpd[15724]: 6D52E1CA04A: client=unknown[14.162.204.43] Apr 25 12:11:00 MAIL-GATEWAY postfix/cleanup[15746]: 6D52E1CA04A: message-id=<1067707414.20170425131052 at freenet.de> Apr 25 12:11:00 MAIL-GATEWAY postfix/qmgr[10223]: 6D52E1CA04A: from=, size=1058, nrcpt=1 (queue active) Apr 25 12:11:00 MAIL-GATEWAY amavis[14080]: (14080-19) LMTP :10024 /var/amavis/tmp/amavis-20170425T112447-14080-FCNjE3M5: -> SIZE=1058 Received: from Domain.de ([127.0.0.1]) by localhost (Domain.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP for ; Tue, 25 Apr 2017 12:11:00 +0200 (CEST) Apr 25 12:11:00 MAIL-GATEWAY amavis[14080]: (14080-19) Checking: BSF2-kx5ntXW [14.162.204.43] -> Apr 25 12:11:01 MAIL-GATEWAY postfix/smtpd[15724]: disconnect from unknown[14.162.204.43] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 Apr 25 12:11:01 MAIL-GATEWAY amavis[14080]: (14080-19) spam-tag, -> , No, score=2.213 required=3 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, RDNS_NONE=0.793, T_PDS_FROM_2_EMAILS=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Apr 25 12:11:01 MAIL-GATEWAY postfix/smtpd[15749]: connect from localhost[127.0.0.1] Apr 25 12:11:01 MAIL-GATEWAY postfix/smtpd[15749]: BEC5A1CA051: client=localhost[127.0.0.1], orig_queue_id=6D52E1CA04A, orig_client=unknown[14.162.204.43] Apr 25 12:11:01 MAIL-GATEWAY postfix/cleanup[15746]: BEC5A1CA051: message-id=<1067707414.20170425131052 at freenet.de> Apr 25 12:11:01 MAIL-GATEWAY postfix/smtpd[15749]: disconnect from localhost[127.0.0.1] ehlo=1 xforward=1 mail=1 rcpt=1 data=1 quit=1 commands=6 Apr 25 12:11:01 MAIL-GATEWAY postfix/qmgr[10223]: BEC5A1CA051: from=, size=1835, nrcpt=1 (queue active) Apr 25 12:11:01 MAIL-GATEWAY amavis[14080]: (14080-19) BSF2-kx5ntXW FWD from -> , BODY=7BIT 250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as BEC5A1CA051 Apr 25 12:11:01 MAIL-GATEWAY amavis[14080]: (14080-19) Passed CLEAN {RelayedInbound}, [14.162.204.43]:49371 [14.162.204.43] -> , Queue-ID: 6D52E1CA04A, Message-ID: <1067707414.20170425131052 at freenet.de>, mail_id: BSF2-kx5ntXW, Hits: 2.213, size: 1058, queued_as: BEC5A1CA051, 906 ms Apr 25 12:11:01 MAIL-GATEWAY amavis[14080]: (14080-19) TIMING-SA [total 833 ms, cpu 250 ms] - parse: 0.79 (0.1%), extract_message_metadata: 10 (1.2%), get_uri_detail_list: 0.70 (0.1%), tests_pri_-1000: 2.7 (0.3%), tests_pri_-950: 0.77 (0.1%), tests_pri_-900: 0.89 (0.1%), tests_pri_-400: 11 (1.4%), check_bayes: 10 (1.3%), b_tokenize: 3.3 (0.4%), b_tok_get_all: 3.0 (0.4%), b_comp_prob: 1.88 (0.2%), b_tok_touch_all: 0.15 (0.0%), b_finish: 0.67 (0.1%), tests_pri_0: 748 (89.7%), check_dkim_signature: 0.41 (0.0%), check_dkim_adsp: 82 (9.9%), check_spf: 0.22 (0.0%), check_pyzor: 0.10 (0.0%), check_razor2: 614 (73.7%), tests_pri_500: 45 (5.5%), poll_dns_idle: 39 (4.7%), get_report: 0.77 (0.1%) Apr 25 12:11:01 MAIL-GATEWAY postfix/lmtp[15747]: 6D52E1CA04A: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=4.5, delays=3.6/0/0/0.91, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as BEC5A1CA051) Apr 25 12:11:01 MAIL-GATEWAY amavis[14080]: (14080-19) size: 1058, TIMING [total 910 ms, cpu 277 ms, AM-cpu 27 ms, SA-cpu 250 ms] - SMTP greeting: 1.6 (0%)0, SMTP LHLO: 0.6 (0%)0, SMTP pre-MAIL: 0.7 (0%)0, SMTP pre-DATA-flush: 2.0 (0%)1, SMTP DATA: 38 (4%)5, check_init: 0.4 (0%)5, digest_hdr: 0.3 (0%)5, digest_body: 0.1 (0%)5, collect_info: 1.3 (0%)5, check_header: 1.0 (0%)5, AV-scan-1: 9 (1%)6, spam-wb-list: 0.6 (0%)6, SA msg read: 0.5 (0%)6, SA parse: 1.1 (0%)6, SA check: 830 (91%)97, decide_mail_destiny: 4.8 (1%)98, notif-quar: 0.4 (0%)98, fwd-connect: 4.1 (0%)98, fwd-xforward: 0.7 (0%)98, fwd-mail-pip: 1.8 (0%)99, fwd-rcpt-pip: 0.1 (0%)99, fwd-data-chkpnt: 0.0 (0%)99, write-header: 0.3 (0%)99, fwd-data-contents: 0.0 (0%)99, fwd-end-chkpnt: 1.6 (0%)99, prepare-dsn: 0.6 (0%)99, report: 1.4 (0%)99, main_log_entry: 4.8 (1%)100, update_snmp: 2.1 (0%)100, SMTP pre-response: 0.3 (0%)100, SMTP response: 0.2 (0%)100, unlink-1-files: 0.2 (0%)100, rundown: 0.7 (0%)100 Apr 25 12:11:01 MAIL-GATEWAY amavis[14080]: (14080-19) size: 1058, RUSAGE minflt=39+0, majflt=0+0, nswap=0+0, inblock=0+0, oublock=328+0, msgsnd=0+0, msgrcv=0+0, nsignals=0+0, nvcsw=24+0, nivcsw=1+0, maxrss=99704+0, ixrss=0+0, idrss=0+0, isrss=0+0, utime=0.267+0.000, stime=0.010+0.000 Apr 25 12:11:01 MAIL-GATEWAY postfix/qmgr[10223]: 6D52E1CA04A: removed Apr 25 12:11:01 MAIL-GATEWAY postfix/smtp[15750]: BEC5A1CA051: to=, relay=MAIL-SERVER-IP[MAIL-SERVER-IP]:PORT, delay=0.05, delays=0/0/0/0.04, dsn=2.6.0, status=sent (250 2.6.0 <1067707414.20170425131052 at freenet.de> Queued mail for delivery) Apr 25 12:11:01 MAIL-GATEWAY postfix/qmgr[10223]: BEC5A1CA051: removed Ich habe so das Gefühl, dass mein DNS nicht schnell genügt auf die Anfrage reagiert und er diese dann entsprechend einfach weiter verarbeitet, was aber echt seltsam ist. Hatte das Problem noch nie, erst seit einer jetzt schon längeren Zeit. Zumal definitiv nicht aus "static.vnpt.vn does not resolve to address 14.162.204.43" kommen kann. Ich komm nicht weiter mit diesem Problem, forste schon alle Seiten ab bzgl diesen Fehlers. VG From sebastian at karotte.org Tue Apr 25 13:15:28 2017 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Tue, 25 Apr 2017 13:15:28 +0200 Subject: warning: hostname foo.bar.us does not resolve to address IP-Adresse : Temporary failure in name resolution In-Reply-To: References: Message-ID: <20170425111528.GC26280@danton.fire-world.de> * t.berthel at gmx.net [2017-04-25 12:45]: > Ich habe so das Gefühl, dass mein DNS nicht schnell genügt auf die > Anfrage reagiert und er diese dann entsprechend einfach weiter > verarbeitet, was aber echt seltsam ist. Hatte das Problem noch nie, > erst seit einer jetzt schon längeren Zeit. Zumal > definitiv nicht aus "static.vnpt.vn > does not resolve to address 14.162.204.43" kommen kann. Was hat denn die Mailadresse mit der Client-IP zu tun? In dem Fall: $ host 14.162.204.43 43.204.162.14.in-addr.arpa domain name pointer static.vnpt.vn. $ host static.vnpt.vn. static.vnpt.vn has address 203.162.0.78 Da hat Postfix also ganz recht, PTR<->A passt nicht zusammen. was steht denn in den beiden check_client_access Listen genau drin? Gruß Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From Hajo.Locke at gmx.de Tue Apr 25 13:17:37 2017 From: Hajo.Locke at gmx.de (Hajo Locke) Date: Tue, 25 Apr 2017 13:17:37 +0200 Subject: Image only spam In-Reply-To: <20170424195543.ls5cdr3rytfvqyrw@charite.de> References: <1380771818.29.1493041917669@rock-bunker.de> <2040626.7jSfytDorQ@tux.boltz.de.vu> <20170424195543.ls5cdr3rytfvqyrw@charite.de> Message-ID: <8850d0e1-3bf0-511f-4a98-38f96ac236e1@gmx.de> Hallo, Am 24.04.2017 um 21:55 schrieb Ralf Hildebrandt: > * Christian Boltz : >> Hallo Claas, hallo zusammen, >> >> Am Montag, 24. April 2017, 15:51:57 CEST schrieb Claas Goltz: >>> URIBL_BLOCKED=0.001 >> Das sieht nach der passenden Stellschraube aus. >> >> Du willst einen eigenen Nameserver (statt des Provider-Nameservers) >> betreiben, damit Dich URIBL mit sinnvollen Ergebnissen versorgt ;-) > Korrekt > > Aber man darf halt nicht zuviel Abfragen machen... Wir kann man eigentlich in Spamassassin die Nutzung dieser Liste abschalten. Listen mit Abfragelimits möchte ich gern vermeiden. Ich verwende bereits "skip_rbl_checks 1" in der local.cf des Spamassassin. Das scheint auch für die per default aktivierten RBLs zu greifen. URIBL wird aber wohl trotzdem getestet und finde ich in den Logauswertungen. Danke, Hajo From Christian.Hoyer-Reuther at cac-chem.de Tue Apr 25 13:17:49 2017 From: Christian.Hoyer-Reuther at cac-chem.de (Hoyer-Reuther, Christian) Date: Tue, 25 Apr 2017 13:17:49 +0200 Subject: AW: warning: hostname foo.bar.us does not resolve to address IP-Adresse : Temporary failure in name resolution In-Reply-To: References: Message-ID: <41E487BC91654544B2B8F31096F2D9D4F3F13516BE@ex1> Hallo, den Log-Eintrag "warning: hostname .* does not resolve to address .*" siehst Du, wenn reject_unknown_client_hostname _nicht_ gesetzt ist. Dieses ist restriktiver als reject_unknown_reverse_client_hostname, welches Du verwendest. Auszug Postfix-Doku: reject_unknown_client_hostname (with Postfix < 2.3: reject_unknown_client) Reject the request when 1) the client IP address->name mapping fails, 2) the name->address mapping fails, or 3) the name->address mapping does not match the client IP address. This is a stronger restriction than the reject_unknown_reverse_client_hostname feature, which triggers only under condition 1) above. Christian -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von t.berthel at gmx.net Gesendet: Dienstag, 25. April 2017 12:45 An: postfixbuch-users at listen.jpberlin.de Betreff: warning: hostname foo.bar.us does not resolve to address IP-Adresse : Temporary failure in name resolution Hallo und danke für deine Antwort. > du hast ja schon reject_unknown_reverse_client_hostname in deiner > config, ich könnte mir nur vorstellen, dass irgendwo in > check_client_access hash:/etc/postfix/smtpd_access, > check_client_access hash:/etc/postfix/tld_access, > ein whitelisting erfolgt das nicht beabsichtigt ist? Ich habe meine withlists alle auf die Möglichkeiten hin geprüft, jedoch keinen Fehleintrag gefunden. Erst nachdem ich die IP in meine Liste smtpd_access hinterlegt hatte wurde diese wie gewünscht blockiert. Aber da sehe ich mich "Don Quijote" vor der Windmühle wenn ich das immer befüllen darf ;) Jetzt habe ich einen neuen Fall aus Received: from xpijn.yandex.ru (unknown [14.162.204.43]): Apr 25 12:10:55 MAIL-GATEWAY postfix/smtpd[15724]: warning: hostname static.vnpt.vn does not resolve to address 14.162.204.43 Apr 25 12:10:55 MAIL-GATEWAY postfix/smtpd[15724]: connect from unknown[14.162.204.43] Apr 25 12:10:59 MAIL-GATEWAY postfix/smtpd[15724]: 6D52E1CA04A: client=unknown[14.162.204.43] Apr 25 12:11:00 MAIL-GATEWAY postfix/cleanup[15746]: 6D52E1CA04A: message-id=<1067707414.20170425131052 at freenet.de> Apr 25 12:11:00 MAIL-GATEWAY postfix/qmgr[10223]: 6D52E1CA04A: from=, size=1058, nrcpt=1 (queue active) Apr 25 12:11:00 MAIL-GATEWAY amavis[14080]: (14080-19) LMTP :10024 /var/amavis/tmp/amavis-20170425T112447-14080-FCNjE3M5: -> SIZE=1058 Received: from Domain.de ([127.0.0.1]) by localhost (Domain.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP for ; Tue, 25 Apr 2017 12:11:00 +0200 (CEST) Apr 25 12:11:00 MAIL-GATEWAY amavis[14080]: (14080-19) Checking: BSF2-kx5ntXW [14.162.204.43] -> Apr 25 12:11:01 MAIL-GATEWAY postfix/smtpd[15724]: disconnect from unknown[14.162.204.43] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 Apr 25 12:11:01 MAIL-GATEWAY amavis[14080]: (14080-19) spam-tag, -> , No, score=2.213 required=3 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, RDNS_NONE=0.793, T_PDS_FROM_2_EMAILS=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Apr 25 12:11:01 MAIL-GATEWAY postfix/smtpd[15749]: connect from localhost[127.0.0.1] Apr 25 12:11:01 MAIL-GATEWAY postfix/smtpd[15749]: BEC5A1CA051: client=localhost[127.0.0.1], orig_queue_id=6D52E1CA04A, orig_client=unknown[14.162.204.43] Apr 25 12:11:01 MAIL-GATEWAY postfix/cleanup[15746]: BEC5A1CA051: message-id=<1067707414.20170425131052 at freenet.de> Apr 25 12:11:01 MAIL-GATEWAY postfix/smtpd[15749]: disconnect from localhost[127.0.0.1] ehlo=1 xforward=1 mail=1 rcpt=1 data=1 quit=1 commands=6 Apr 25 12:11:01 MAIL-GATEWAY postfix/qmgr[10223]: BEC5A1CA051: from=, size=1835, nrcpt=1 (queue active) Apr 25 12:11:01 MAIL-GATEWAY amavis[14080]: (14080-19) BSF2-kx5ntXW FWD from -> , BODY=7BIT 250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as BEC5A1CA051 Apr 25 12:11:01 MAIL-GATEWAY amavis[14080]: (14080-19) Passed CLEAN {RelayedInbound}, [14.162.204.43]:49371 [14.162.204.43] -> , Queue-ID: 6D52E1CA04A, Message-ID: <1067707414.20170425131052 at freenet.de>, mail_id: BSF2-kx5ntXW, Hits: 2.213, size: 1058, queued_as: BEC5A1CA051, 906 ms Apr 25 12:11:01 MAIL-GATEWAY amavis[14080]: (14080-19) TIMING-SA [total 833 ms, cpu 250 ms] - parse: 0.79 (0.1%), extract_message_metadata: 10 (1.2%), get_uri_detail_list: 0.70 (0.1%), tests_pri_-1000: 2.7 (0.3%), tests_pri_-950: 0.77 (0.1%), tests_pri_-900: 0.89 (0.1%), tests_pri_-400: 11 (1.4%), check_bayes: 10 (1.3%), b_tokenize: 3.3 (0.4%), b_tok_get_all: 3.0 (0.4%), b_comp_prob: 1.88 (0.2%), b_tok_touch_all: 0.15 (0.0%), b_finish: 0.67 (0.1%), tests_pri_0: 748 (89.7%), check_dkim_signature: 0.41 (0.0%), check_dkim_adsp: 82 (9.9%), check_spf: 0.22 (0.0%), check_pyzor: 0.10 (0.0%), check_razor2: 614 (73.7%), tests_pri_500: 45 (5.5%), poll_dns_idle: 39 (4.7%), get_report: 0.77 (0.1%) Apr 25 12:11:01 MAIL-GATEWAY postfix/lmtp[15747]: 6D52E1CA04A: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=4.5, delays=3.6/0/0/0.91, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as BEC5A1CA051) Apr 25 12:11:01 MAIL-GATEWAY amavis[14080]: (14080-19) size: 1058, TIMING [total 910 ms, cpu 277 ms, AM-cpu 27 ms, SA-cpu 250 ms] - SMTP greeting: 1.6 (0%)0, SMTP LHLO: 0.6 (0%)0, SMTP pre-MAIL: 0.7 (0%)0, SMTP pre-DATA-flush: 2.0 (0%)1, SMTP DATA: 38 (4%)5, check_init: 0.4 (0%)5, digest_hdr: 0.3 (0%)5, digest_body: 0.1 (0%)5, collect_info: 1.3 (0%)5, check_header: 1.0 (0%)5, AV-scan-1: 9 (1%)6, spam-wb-list: 0.6 (0%)6, SA msg read: 0.5 (0%)6, SA parse: 1.1 (0%)6, SA check: 830 (91%)97, decide_mail_destiny: 4.8 (1%)98, notif-quar: 0.4 (0%)98, fwd-connect: 4.1 (0%)98, fwd-xforward: 0.7 (0%)98, fwd-mail-pip: 1.8 (0%)99, fwd-rcpt-pip: 0.1 (0%)99, fwd-data-chkpnt: 0.0 (0%)99, write-header: 0.3 (0%)99, fwd-data-contents: 0.0 (0%)99, fwd-end-chkpnt: 1.6 (0%)99, prepare-dsn: 0.6 (0%)99, report: 1.4 (0%)99, main_log_entry: 4.8 (1%)100, update_snmp: 2.1 (0%)100, SMTP pre-response: 0.3 (0%)100, SMTP response: 0.2 (0%)100, unlink-1-files: 0.2 (0%)100, rundown: 0.7 (0%)100 Apr 25 12:11:01 MAIL-GATEWAY amavis[14080]: (14080-19) size: 1058, RUSAGE minflt=39+0, majflt=0+0, nswap=0+0, inblock=0+0, oublock=328+0, msgsnd=0+0, msgrcv=0+0, nsignals=0+0, nvcsw=24+0, nivcsw=1+0, maxrss=99704+0, ixrss=0+0, idrss=0+0, isrss=0+0, utime=0.267+0.000, stime=0.010+0.000 Apr 25 12:11:01 MAIL-GATEWAY postfix/qmgr[10223]: 6D52E1CA04A: removed Apr 25 12:11:01 MAIL-GATEWAY postfix/smtp[15750]: BEC5A1CA051: to=, relay=MAIL-SERVER-IP[MAIL-SERVER-IP]:PORT, delay=0.05, delays=0/0/0/0.04, dsn=2.6.0, status=sent (250 2.6.0 <1067707414.20170425131052 at freenet.de> Queued mail for delivery) Apr 25 12:11:01 MAIL-GATEWAY postfix/qmgr[10223]: BEC5A1CA051: removed Ich habe so das Gefühl, dass mein DNS nicht schnell genügt auf die Anfrage reagiert und er diese dann entsprechend einfach weiter verarbeitet, was aber echt seltsam ist. Hatte das Problem noch nie, erst seit einer jetzt schon längeren Zeit. Zumal definitiv nicht aus "static.vnpt.vn does not resolve to address 14.162.204.43" kommen kann. Ich komm nicht weiter mit diesem Problem, forste schon alle Seiten ab bzgl diesen Fehlers. VG From Christian.Hoyer-Reuther at cac-chem.de Tue Apr 25 13:21:25 2017 From: Christian.Hoyer-Reuther at cac-chem.de (Hoyer-Reuther, Christian) Date: Tue, 25 Apr 2017 13:21:25 +0200 Subject: AW: Image only spam In-Reply-To: <8850d0e1-3bf0-511f-4a98-38f96ac236e1@gmx.de> References: <1380771818.29.1493041917669@rock-bunker.de> <2040626.7jSfytDorQ@tux.boltz.de.vu> <20170424195543.ls5cdr3rytfvqyrw@charite.de> <8850d0e1-3bf0-511f-4a98-38f96ac236e1@gmx.de> Message-ID: <41E487BC91654544B2B8F31096F2D9D4F3F13516C0@ex1> Hallo Hajo, Deaktivierung einzelner Listenabfragen geht wie folgt: dns_query_restriction deny sorbs.net Christian -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von Hajo Locke Gesendet: Dienstag, 25. April 2017 13:18 An: postfixbuch-users at listen.jpberlin.de Betreff: Re: Image only spam Hallo, Am 24.04.2017 um 21:55 schrieb Ralf Hildebrandt: > * Christian Boltz : >> Hallo Claas, hallo zusammen, >> >> Am Montag, 24. April 2017, 15:51:57 CEST schrieb Claas Goltz: >>> URIBL_BLOCKED=0.001 >> Das sieht nach der passenden Stellschraube aus. >> >> Du willst einen eigenen Nameserver (statt des Provider-Nameservers) >> betreiben, damit Dich URIBL mit sinnvollen Ergebnissen versorgt ;-) > Korrekt > > Aber man darf halt nicht zuviel Abfragen machen... Wir kann man eigentlich in Spamassassin die Nutzung dieser Liste abschalten. Listen mit Abfragelimits möchte ich gern vermeiden. Ich verwende bereits "skip_rbl_checks 1" in der local.cf des Spamassassin. Das scheint auch für die per default aktivierten RBLs zu greifen. URIBL wird aber wohl trotzdem getestet und finde ich in den Logauswertungen. Danke, Hajo From Ralf.Hildebrandt at charite.de Tue Apr 25 14:22:25 2017 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Tue, 25 Apr 2017 14:22:25 +0200 Subject: Image only spam In-Reply-To: <8850d0e1-3bf0-511f-4a98-38f96ac236e1@gmx.de> References: <1380771818.29.1493041917669@rock-bunker.de> <2040626.7jSfytDorQ@tux.boltz.de.vu> <20170424195543.ls5cdr3rytfvqyrw@charite.de> <8850d0e1-3bf0-511f-4a98-38f96ac236e1@gmx.de> Message-ID: <20170425122224.px3awgzmghvrkgsj@charite.de> * Hajo Locke : > Hallo, > > Am 24.04.2017 um 21:55 schrieb Ralf Hildebrandt: > > * Christian Boltz : > > > Hallo Claas, hallo zusammen, > > > > > > Am Montag, 24. April 2017, 15:51:57 CEST schrieb Claas Goltz: > > > > URIBL_BLOCKED=0.001 > > > Das sieht nach der passenden Stellschraube aus. > > > > > > Du willst einen eigenen Nameserver (statt des Provider-Nameservers) > > > betreiben, damit Dich URIBL mit sinnvollen Ergebnissen versorgt ;-) > > Korrekt > > > > Aber man darf halt nicht zuviel Abfragen machen... > Wir kann man eigentlich in Spamassassin die Nutzung dieser Liste abschalten. > Listen mit Abfragelimits möchte ich gern vermeiden. Score auf 0 setzen (local.cf von SpamAssassin) # DISABLE URIBL score URIBL_BLACK 0 score URIBL_RED 0 score URIBL_GREY 0 score URIBL_BLOCKED 0 -- 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 claas.goltz at rock-bunker.de Tue Apr 25 14:30:38 2017 From: claas.goltz at rock-bunker.de (Claas Goltz) Date: Tue, 25 Apr 2017 14:30:38 +0200 (CEST) Subject: Image only spam In-Reply-To: <20170425122224.px3awgzmghvrkgsj@charite.de> References: <1380771818.29.1493041917669@rock-bunker.de> <2040626.7jSfytDorQ@tux.boltz.de.vu> <20170424195543.ls5cdr3rytfvqyrw@charite.de> <8850d0e1-3bf0-511f-4a98-38f96ac236e1@gmx.de> <20170425122224.px3awgzmghvrkgsj@charite.de> Message-ID: <1546909607.49.1493123438164@mail.rock-bunker.de> Hallo Hajo, bewirkt das nicht das Gegenteil von dem was ich eigentlich möchte? Die EMail hatte ja zuwenig Punkte bekommen und durch das hochschrauben der URIBL_BLOCKED scores hätte sie die kritische Punktzahl 5.2 bekommen und wäre geblockt worden. > Ralf Hildebrandt hat am 25. April 2017 um 14:22 geschrieben: > > > * Hajo Locke : > > Hallo, > > > > Am 24.04.2017 um 21:55 schrieb Ralf Hildebrandt: > > > * Christian Boltz : > > > > Hallo Claas, hallo zusammen, > > > > > > > > Am Montag, 24. April 2017, 15:51:57 CEST schrieb Claas Goltz: > > > > > URIBL_BLOCKED=0.001 > > > > Das sieht nach der passenden Stellschraube aus. > > > > > > > > Du willst einen eigenen Nameserver (statt des Provider-Nameservers) > > > > betreiben, damit Dich URIBL mit sinnvollen Ergebnissen versorgt ;-) > > > Korrekt > > > > > > Aber man darf halt nicht zuviel Abfragen machen... > > Wir kann man eigentlich in Spamassassin die Nutzung dieser Liste abschalten. > > Listen mit Abfragelimits möchte ich gern vermeiden. > > Score auf 0 setzen (local.cf von SpamAssassin) > > # DISABLE URIBL > score URIBL_BLACK 0 > score URIBL_RED 0 > score URIBL_GREY 0 > score URIBL_BLOCKED 0 > > -- > 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 > -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From t.berthel at gmx.net Tue Apr 25 14:39:32 2017 From: t.berthel at gmx.net (t.berthel at gmx.net) Date: Tue, 25 Apr 2017 14:39:32 +0200 Subject: warning: hostname foo.bar.us does not resolve to address IP-Adresse : Temporary failure in name resolution Message-ID: Hallo, danke jetzt verändert sich auch das Verhalten noch im positiven Sinne! > den Log-Eintrag "warning: hostname .* does not resolve to address .*" siehst Du, wenn reject_unknown_client_hostname _nicht_ gesetzt ist. Dieses ist restriktiver als reject_unknown_reverse_client_hostname, > welches Du verwendest. Auszug Postfix-Doku: > reject_unknown_client_hostname (with Postfix < 2.3: reject_unknown_client) > Reject the request when 1) the client IP address->name mapping fails, 2) the name->address mapping fails, or 3) the name->address mapping does not match the client IP address. > This is a stronger restriction than the reject_unknown_reverse_client_hostname feature, which triggers only under condition 1) above. Ich habe jedoch noch etwas bezgl der reject_unknown_client_hostname im Kopf, dass bei einem fehler oder schlecht konfigurierten Mailserver diese Mails dann auch noch hängen bleiben. Dem ist doch so, oder? Es sollten ja nicht zuviele Server einen falschen / keinen PTR oder der A-Record nicht darauf verweist. Noch eine Frage, den reject_unknown_reverse_client_hostname kann ich mir dann ja ersparren in meinem Setting, oder? Danke an die Unterstützer! From Christian.Hoyer-Reuther at cac-chem.de Tue Apr 25 14:56:59 2017 From: Christian.Hoyer-Reuther at cac-chem.de (Hoyer-Reuther, Christian) Date: Tue, 25 Apr 2017 14:56:59 +0200 Subject: AW: warning: hostname foo.bar.us does not resolve to address IP-Adresse : Temporary failure in name resolution In-Reply-To: References: Message-ID: <41E487BC91654544B2B8F31096F2D9D4F3F13516D8@ex1> Hallo, du kannst die Option erstmal mit "warn_if_reject reject_unknown_client_hostname" verwenden. Postfix macht dann keinen Reject, sondern loggt das nur als reject_warning, z.B. "450 4.7.1 Client host rejected: cannot find your reverse hostname" und "450 4.7.1 Client host rejected: cannot find your hostname". Dann kannst Du das Log prüfen, ob Clients betroffen wären, die Du eigentlich zulassen willst. Die nimmst Du dann in eine Whitelist und kannst das "warn_if_reject" wegnehmen. Je nach Umgebung macht es sich gut, auch weiterhin das Log im Auge zu behalten und die Whitelist nachzupflegen. reject_unknown_reverse_client_hostname kann dann wegfallen, da dessen Check durch reject_unknown_client_hostname abgedeckt ist. Christian -----Ursprüngliche Nachricht----- Von: Postfixbuch-users [mailto:postfixbuch-users-bounces at listen.jpberlin.de] Im Auftrag von t.berthel at gmx.net Gesendet: Dienstag, 25. April 2017 14:40 An: postfixbuch-users at listen.jpberlin.de Betreff: warning: hostname foo.bar.us does not resolve to address IP-Adresse : Temporary failure in name resolution Hallo, danke jetzt verändert sich auch das Verhalten noch im positiven Sinne! > den Log-Eintrag "warning: hostname .* does not resolve to address .*" siehst Du, wenn reject_unknown_client_hostname _nicht_ gesetzt ist. Dieses ist restriktiver als reject_unknown_reverse_client_hostname, > welches Du verwendest. Auszug Postfix-Doku: > reject_unknown_client_hostname (with Postfix < 2.3: reject_unknown_client) > Reject the request when 1) the client IP address->name mapping fails, 2) the name->address mapping fails, or 3) the name->address mapping does not match the client IP address. > This is a stronger restriction than the reject_unknown_reverse_client_hostname feature, which triggers only under condition 1) above. Ich habe jedoch noch etwas bezgl der reject_unknown_client_hostname im Kopf, dass bei einem fehler oder schlecht konfigurierten Mailserver diese Mails dann auch noch hängen bleiben. Dem ist doch so, oder? Es sollten ja nicht zuviele Server einen falschen / keinen PTR oder der A-Record nicht darauf verweist. Noch eine Frage, den reject_unknown_reverse_client_hostname kann ich mir dann ja ersparren in meinem Setting, oder? Danke an die Unterstützer! From t.berthel at gmx.net Tue Apr 25 15:16:49 2017 From: t.berthel at gmx.net (t.berthel at gmx.net) Date: Tue, 25 Apr 2017 15:16:49 +0200 Subject: AW: warning: hostname foo.bar.us does not resolve to address IP-Adresse : Temporary failure in name resolution Message-ID: Hallo, jetzt versteh ich das auch mal :) > du kannst die Option erstmal mit "warn_if_reject reject_unknown_client_hostname" verwenden. Postfix macht dann keinen Reject, sondern loggt das nur als reject_warning, z.B. "450 4.7.1 Client host rejected: > cannot find your reverse hostname" und "450 4.7.1 Client host rejected: cannot find your hostname". Im Moment sehe ich eine Menge an "NOQUEUE: reject: RCPT from unknown...550 5.7.25 Client host rejected:" bei mir einfließen...sehr schön und den Tipp mit dem warn_if_reject muss ich mir merken! > reject_unknown_reverse_client_hostname kann dann wegfallen, da dessen Check durch reject_unknown_client_hostname abgedeckt ist. Gut, dann wirds wieder eindeutiger. Danke & bis demnächst! From Hajo.Locke at gmx.de Tue Apr 25 15:19:48 2017 From: Hajo.Locke at gmx.de (Hajo Locke) Date: Tue, 25 Apr 2017 15:19:48 +0200 Subject: Image only spam In-Reply-To: <1546909607.49.1493123438164@mail.rock-bunker.de> References: <1380771818.29.1493041917669@rock-bunker.de> <2040626.7jSfytDorQ@tux.boltz.de.vu> <20170424195543.ls5cdr3rytfvqyrw@charite.de> <8850d0e1-3bf0-511f-4a98-38f96ac236e1@gmx.de> <20170425122224.px3awgzmghvrkgsj@charite.de> <1546909607.49.1493123438164@mail.rock-bunker.de> Message-ID: <58597c60-99c4-1acb-47e3-ce9fa47f8668@gmx.de> Hallo, Am 25.04.2017 um 14:30 schrieb Claas Goltz: > Hallo Hajo, > bewirkt das nicht das Gegenteil von dem was ich eigentlich möchte? Die > EMail hatte ja zuwenig Punkte bekommen und durch das hochschrauben der > URIBL_BLOCKED scores hätte sie die kritische Punktzahl 5.2 bekommen > und wäre geblockt worden. Ja, du hast Recht. Ich hatte im Mailverlauf nur den Hinweis aufgegriffen, dass es sich um eine Liste mit Abfragelimits handelt und wie man es vermeidet diese Liste zu verwenden. Für deinen Zweck ist das sicherlich nichts und du könntest den score für vertrauenswürdige Tests nach oben schrauben. > > > Ralf Hildebrandt hat am 25. April 2017 > um 14:22 geschrieben: > > > > > > * Hajo Locke : > > > Hallo, > > > > > > Am 24.04.2017 um 21:55 schrieb Ralf Hildebrandt: > > > > * Christian Boltz : > > > > > Hallo Claas, hallo zusammen, > > > > > > > > > > Am Montag, 24. April 2017, 15:51:57 CEST schrieb Claas Goltz: > > > > > > URIBL_BLOCKED=0.001 > > > > > Das sieht nach der passenden Stellschraube aus. > > > > > > > > > > Du willst einen eigenen Nameserver (statt des > Provider-Nameservers) > > > > > betreiben, damit Dich URIBL mit sinnvollen Ergebnissen > versorgt ;-) > > > > Korrekt > > > > > > > > Aber man darf halt nicht zuviel Abfragen machen... > > > Wir kann man eigentlich in Spamassassin die Nutzung dieser Liste > abschalten. > > > Listen mit Abfragelimits möchte ich gern vermeiden. > > > > Score auf 0 setzen (local.cf von SpamAssassin) > > > > # DISABLE URIBL > > score URIBL_BLACK 0 > > score URIBL_RED 0 > > score URIBL_GREY 0 > > score URIBL_BLOCKED 0 > > > > -- > > 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 > > Hajo From postfixbuch at cboltz.de Tue Apr 25 21:26:44 2017 From: postfixbuch at cboltz.de (Christian Boltz) Date: Tue, 25 Apr 2017 21:26:44 +0200 Subject: Image only spam In-Reply-To: <1546909607.49.1493123438164@mail.rock-bunker.de> References: <1380771818.29.1493041917669@rock-bunker.de> <20170425122224.px3awgzmghvrkgsj@charite.de> <1546909607.49.1493123438164@mail.rock-bunker.de> Message-ID: <12148415.8Hm3zLsNsa@tux.boltz.de.vu> Hallo Claas, hallo zusammen, Am Dienstag, 25. April 2017, 14:30:38 CEST schrieb Claas Goltz: > Hallo Hajo, > bewirkt das nicht das Gegenteil von dem was ich eigentlich möchte? Die > EMail hatte ja zuwenig Punkte bekommen und durch das hochschrauben > der URIBL_BLOCKED scores hätte sie die kritische Punktzahl 5.2 > bekommen und wäre geblockt worden. URIBL_BLOCKED sagt "Du hast das Abfragelimit überschritten". _Dafür_ die Punkte hochsetzen ist vermutlich keine gute Idee. Die anderen URIBL_*-Regeln kannst Du eher hochdrehen, sie bringen aber auch schon von Haus aus einige Punkte mit. Probier also erstmal mit den Standardwerten. Und generell gilt: Im Zweifelsfall erstmal den Regelnamen in Google tippen/pasten, bevor man an den Punkten dreht ;-) Gruß Christian Boltz -- > Führst Du schon Selbstgespräche? ;-) Hm. Kann sein. Was meinst du? Nein, glaube ich nicht. Sicher? Ganz sicher. Nein, tun wir nicht. [> Christian Boltz und Ratti in fontlinge-devel] From Hajo.Locke at gmx.de Thu Apr 27 08:22:10 2017 From: Hajo.Locke at gmx.de (Hajo Locke) Date: Thu, 27 Apr 2017 08:22:10 +0200 Subject: Heinlein Spamassassinregeln Message-ID: <174debd1-ebe9-10f1-3ff9-41036f84f113@gmx.de> Hallo Liste bzw. Peer, habe eine Frage zu deinen Spamassassinregeln. Sind diese frei verwendbar, auch wenn ich einen kommerziellen Server verwende? Ist es gestattet die Namen der Regeln zu ändern? Ich hätte da gern meine eigenen Einträge. Danke, Hajo