March 2017 - postfix-users

Spam über ein Maillkonto - bei GMX geblacklistet
by Frank Röhm 06 Apr '17

06 Apr '17

Hallo Ich hab auf meinem root Server (Ubuntu 14 LTS) ein Postfix (Version 2.11.0-1ubuntu) laufen und da ging von einem Konto dessen Passwort gehackt wurde am 5. März um 14:20 etwa massenweise Spam raus. Der Spuk dauerte ca. eine halbe Stunde, bis ich es gemerkt hatte, da waren aber wohl schon zigtausend Spammails rausgegangen, mit der Folge, dass GMX unseren Server geblacklistet hat. 1. wie krieg ich unseren Server aus der Blacklist von GMX raus? Ich hab da schon über so ein Kontaktformular hingeschrieben, aber keine Antwort gekriegt und noch ist er gelistet. Muss ich einfach warten? Der Fehler ist ja erst mal behoben. 2. wie kann ich solche Massen an Mails auf ein Mal von vorne herein verhindern, da gibt es doch sicher eine Einstellung, oder? Das braucht doch keiner. Danke Gruß frank Walter

7 23

ich werde der Spamflut nicht Herr - postfix amavis-new dovecot
by Christoph Kukulies 06 Apr '17

06 Apr '17

Seit Wochen versuche ich nun schon, die Spamflut an meinen account auf einem Server (Ubuntu 16.04 LTS) einzudämmen. Schicke immer manuell täglich allen Junk aus meiner Thunderbird inbox in den Junk-Folder (das sind täglich ca. 70-100, alle der Sorte Nagelpilz, Betriebshaftpflicht, Reichwerdeprogramme, PKV, und andere Dienstleistungen aus dem XXX-Bereich). Manchmal ist eine Mail dabei, die mit ***** SPAM ***** markiert ist, ich habe aber extra das SPAM-Pattern in ++++ SPAM ++++ geändert, damit ich sehen kann, daß es von meinem lokalen Filter generiert wurde und nicht bereits im Subject vorhanden war, als die Mail eintraf. Ich habe hier mal so einen Header herausgegriffen (Adressen modifiziert): Return-Path: <spammer(a)spamsite.com> Delivered-To: thatsme(a)mydomain.org Received: from mail.mydomain.org by mydomain.org (Dovecot) with LMTP id QgXsNmItxlikaQAAXmd1zw for <thatsme(a)mydomain.org>; Mon, 13 Mar 2017 06:25:54 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.mydomain.org (Postfix) with ESMTP id D6DD82106AB for <thatsme(a)mydomain.org>; Mon, 13 Mar 2017 06:25:54 +0100 (CET) X-Spam-Flag: NO X-Spam-Score: 1.275 X-Spam-Level: * X-Spam-Status: No, score=1.275 required=5 tests=[HTML_MESSAGE=0.001, RDNS_NONE=1.274] autolearn=no autolearn_force=no Received: from mail.mydomain.org ([127.0.0.1]) by localhost (mail.mydomain.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8AeaCeujJbg for <thatsme(a)mydomain.org>; Mon, 13 Mar 2017 06:25:54 +0100 (CET) Received: from www.spamsite.com (unknown [67.231.106.60]) by mail.mydomain.org (Postfix) with ESMTP id 0ACC82106AA for <thatsme(a)mydomain.org>; Mon, 13 Mar 2017 06:25:53 +0100 (CET) Date: Sun, 12 Mar 2017 23:25:47 -0600 To: thatsme(a)mydomain.org From: Megan <spammer(a)spamsite.com> Subject: =?utf-8?Q?Having_invested_1000$_i=E2=80=99ve_earned_12000$_for_a_week?= Message-ID: <413bcf25601d2543b66f351d177c82d2(a)www.spamsite.com> X-Priority: 3 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_413bcf25601d2543b66f351d177c82d2" Content-Transfer-Encoding: 8bit --b1_413bcf25601d2543b66f351d177c82d2 Content-Type: text/plain; charset=us-ascii Developer wrote application of market trading without human interaction. This application is available to every man. With every new man has downloaded it and installed - it becomes smarter. For year it successfully trades on market making huge income for every owner of the app. Make it in time to become rich. Earn lots of money before app became forbidden! [ http://www.spamsite.com/menu.php?n=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx… ] It is free and you can get it here Auch schicke ich mittlerweile immer mal wieder "gute" Mail in einen ham-Ordner zum Lernen. Nützt alles nichts. Wäre jetzt dieses Forum ein Platz für derartige Fragen oder gibt es noch was spezielleres? Grüße Christoph

7 17

reject_unverified_sender
by Joachim Fahrner 30 Mar '17

30 Mar '17

Hallo Liste, wie sind denn so eure Erfahrungen mit reject_unverified_sender? Ich hab das mal vor ein paar Tagen aktiviert um zu sehen ob das hilfreich gegen Spam ist. Gestern wurde zum ersten Mal was damit geblockt, ich vermute dass es ein Newsletter eines Online-Shops war. Mar 29 17:17:33 server postfix/smtp[16325]: 570F1100F8D: to=<bounce+dac578.447f5-jf=fahrner.name(a)dilling-unterwaesche.de>, relay=aspmx.l.google.com[74.125.133.26]:25, delay=0.2, delays=0.01/0.03/0.12/0.04, dsn=5.1.1, status=undeliverable (host aspmx.l.google.com[74.125.133.26] said: 550-5.1.1 The email account that you tried to reach does not exist. Please try 550-5.1.1 double-checking the recipient's email address for typos or 550-5.1.1 unnecessary spaces. Learn more at 550 5.1.1 https://support.google.com/mail/?p=NoSuchUser k17si8875408wrc.180 - gsmtp (in reply to RCPT TO command)) Kommt sowas häufiger vor, dass Newsletter-Software unzustellbare Absender verwendet? Ich bin ja eigentlich der Meinung, warum sollte ich Post von jemand annehmen dem ich nicht antworten kann? Jochen

2 2

Verständnisproblem access restrictions
by Joachim Fahrner 27 Mar '17

27 Mar '17

Hallo Liste, ich habe jetzt die Seite http://www.postfix.org/SMTPD_ACCESS_README.html gefühlte 100 mal durchgelesen, aber immer noch ein Verständnisproblem damit. Ursprünglich wurden die unterschiedlichen Prüfungen zu unterschiedlichen Zeitpunkten gemacht. Heute werden die jedoch zurückgehalten bis zum Zeitpunkt "RCPT TO" oder "ETRN". Welchen Sinn macht dann die Trennung nach Zeitpunkten überhaupt noch? Dann könnte man doch gleich alles in smtpd_recipient_restrictions reinpacken, und bräuchte die anderen restrictions nicht mehr. So muss man nur einige Prüfungen mehrfach wiederholen (z.B. permit_mynetworks). Ich finde das ziemlich verwirrend, und weiß nie wann welche Prüfung wo reingehört, und welche permits ich davor benötige. Das führt dazu, dass man sich immer an irgendwelchen Beispielen aus dem Netz orientiert, die dann oft für irgendwelche uralt-Versionen gemacht sind, oder wo auch nur einer woanders abgeschrieben hat, ohne es wirklich verstanden zu haben. Kann das jemand mit einfachen Worten erklären? Gruss Jochen

5 12

Re: SRS nur für bestimmte Mails? Oder andere Lösung?
by Martin Sebald 23 Mar '17

23 Mar '17

Hallo Uwe, >> <user(a)user.pushyourmail.de> (expanded from <user(a)domain.de>): host >> mx1.hostedcloud.me[185.160.1.4] said: 550 88.99.90.187 is not allowed to >> send mail from gmx.de. Please see >> http://www.openspf.net/Why?scope=mfrom;identity=gmxuser@gmx.de;ip >> =88.99.90.187 >> (in reply to end of DATA command) > Das hört sich eher an als ob ein Fremder Host über GMX mit GMX Adresse ohne Anmeldung versucht zu relayen > (no go, meine Domain dann melde dich an weil du EINER MEINER USER bist oder sende nicht unter meiner Flagge) > Oder aber es ist Weiterleitung zur Weiterleitung, da die Mailadresse maskiert sind ist das recht schwer den ECHTEN Weg nachzuvollziehen. > Wer da über wen mit welcher Adresse versucht an wen zuzustellen und wer die Fehlermeldung auf welchem Weg wirft. Nein nein, das passt so schon so wie beschrieben. Habe dann ja selbst auch getestet. In o.g. Beispiel ist das so (die echten User habe ich natürlich maskiert): Absender ist gmxuser(a)gmx.de (ein echtes GMX Konto, mit dem der Test dann lief) und der Empfänger ist user(a)domain.de (ein Forward Alias auf meinem Mailserver), das Ziel des Forwards ist dann die Exchange Mailbox bei United Hoster namens user(a)user.pushyourmail.de - und von Mailserver von United Hoster kam dann die Fehlermeldung an den GMX User zurück. Soweit ist das ja auch alles nachvollziehbar für mich. Mit Ausnahme des Zeitpunkts des Feedbacks (konnte keine Hinweise finden, dass GMX/web.de vor einigen Tagen ihre SPF Einstellungen entsprechend umgestellt hat - das sollte im Gegensatz dazu wieder seit einiger Zeit so eingestellt sein, sodass das Problem seit vielen Monaten existiert) und, dass sich nur einer meiner User beschwert hat, die nach United Hoster weiterleiten. > Und eine Hetzner Ip wird nie in der Lage sein eine Mail OHNE Anmeldung über GMX oder an GMX vorbei an einen anderen zu senden (der SPF prüft) > Das wäre dann Absenderfälschung (tut fast jeder Spamer so) und da wirkt SPF in dem Fall Nein, das wird nicht gehen. Soweit ja auch nachvollziehbar durch mich. Die Frage ist, wie ich das Problem vom Tisch bekomme. Bei GMX/web.de werde ich die SPF Einträge nicht ändern können, egal auf welchem Wege. Dass United Hoster die SPF Checks bei ihnen selbst raus nimmt ist ebenso unwahrscheinlich. Daher meine Nachfrage nach SRS, aber nur eine Behandlung von Mails, die bestimmten Kriterien entsprechen. Also eben Absender von einer Domain, die "harte" SPF Einstellungen hat. Empfänger leitet (direkt oder indirekt) auf eine externe Adresse um. Dann wäre das finde ich halbwegs sauber. Die meisten Mails unangetastet und die, die ansonsten nicht ankommen, werden eben verbogen. Und da habe ich eben keine Lösung gefunden, die mir das so machen würde bzw die ich so einstellen kann. Viele Grüße, Martin

3 2

Selektives Greylisting
by Joachim Fahrner 23 Mar '17

23 Mar '17

Hallo Liste, ich bin wieder mal am Tuning meiner Konfiguration ;-) Vor einiger Zeit hatte ich mal blind Roberts selektives Greylisting übernommen, wie hier beschrieben: https://sys4.de/de/blog/2013/10/09/selektive-rbl-spf-greylisting-checks-mit… Jetzt habe ich die Beschreibung nochmal genauer gelesen, und dabei ist mir etwas aufgefallen: In smtpd_client_restrictions wird zuerst mynetworks und sasl_authenticated erlaubt. Als nächstes werden die 3 access Tabellen geprüft, und bei Treffern die 3 Klassen ausgeführt. Diese beginnen jeweils wieder mit permit_mynetworks und permit_sasl_authenticated. Ist das nicht doppelt gemoppelt? mynetwork und sasl_authenticated müsste doch schon ganz am Anfang mit permit die client_restrictions verlassen haben. Oder hab ich da was falsch verstanden? Jochen

2 1

SRS nur für bestimmte Mails? Oder andere Lösung?
by Martin Sebald 23 Mar '17

23 Mar '17

Guten Morgen, habe ein Problem mit einem User. Dieser beklagt sich, dass seit einigen Tagen Mails von web.de und GMX nicht mehr an seinen externen Exchange Provider (United Hoster) weitergeleitet werden. Folgende Information erhält der Absender (also der web.de bzw GMX User) per Mail: <user(a)user.pushyourmail.de> (expanded from <user(a)domain.de>): host mx1.hostedcloud.me[185.160.1.4] said: 550 88.99.90.187 is not allowed to send mail from gmx.de. Please see http://www.openspf.net/Why?scope=mfrom;identity=gmxuser@gmx.de;ip=88.99.90.… (in reply to end of DATA command) Soweit, so gut. Das Thema ist ja nicht ganz neu, kann man ja an einigen Stellen im Netz nachlesen. Seltsamerweise beklagt sich nur ein User über den Umstand - dabei habe ich einige, die zu United Hoster auf Hosted Exchange Mailboxen weiterleiten. Das finde ich doch seltsam. Gut, eventuell haben sich die anderen schlich noch nicht beschwert oder erhalten üblicherweise keine Mails von web.de und GMX. Nun aber meine konkrete Frage, denn dazu habe ich trotz einiger Recherche nicht wirklich befriedigendes gefunden: Wie damit umgehen? Meine Idee war nach anfänglicher Recherche, mittels SRS (Sender Rewriting Scheme) Mails zu bearbeiten, die von Absendern kommen, wo der SPF Recors der Domain "scharf" geschaltet ist und die bei mir auf einen externen Empfänger (eventuell auch erst nach einigen internen Forwards) weitergeleitet werden. Irgendwie konnte ich dazu nichts finden und alle Mails mit SRS zu bearbeiten, das will ich nicht. Eine andere Möglichkeit für das konkrete o.g. Problem wäre, dass man die Mails ein einer Mailbox belässt und zyklisch abholt. Aber k.A., ob United Hoster das unterstützt. Des Weiteren hat dies ja auch Nachteile. Mails kommen nicht sofort an und das grundsätzliche Problem der Weiterleitungen bei scharfem SPF Eintrag existiert ja weiterhin. Grundsätzlich will ich vorausschicken, dass ich zwar selbst für einige eigene Domains SPF aktiviert habe (allerdings Softfail), aber naja, dennoch nicht allzu viel davon halte. Bzw ich gehe dann ganz konform mit der Meinung von Peer in seinem bekannten Beitrag: https://www.heinlein-support.de/blog/news/gmx-de-und-web-de-haben-mail-reje… Mir geht es hier halt darum, eine befriedigende Lösung zu erhalten, im konkreten Fall für den besagten Benutzer, aber auch allgemein, eventuell sind ja auch andere betroffen bis hin zu mir selbst. ;-) Also denke ich können wir die Grunsatzdiskussion zumindest ein Stück weit zurückstellen. Danke und viele Grüße, Martin

1 0

nolisting MX record
by Christoph Kukulies 22 Mar '17

22 Mar '17

Nachdem ich mittlerweile der Verzweiflung nahe bin, weil spam immer noch - trotz postgrey - scheinbar ungehindert durchkommt, habe ich jetzt zum letzten Mittel gegriffen und in dem DNS-record meines Servers einen "fake" MX Eintrag gemacht, derart, daß da jetzt steht @ IN 10 nolisting @ IN 20 mail Normale Mail kommt ungehindert an (darüber bin ich schon mal froh). Aber eben kam wieder eine Spam mail der Sorte amanda durch. Hier ist sie (habe versucht, die möglicherweise bösartigen Links zu neutralisieren). Wenn da das nolisting nichts nütt , scheint sie über einen regulären Server gelaufen zu sein, der wiederholt zuzustellen versucht, oder? Grüße Christoph

6 8

master.cf content_filter=
by Christoph Kukulies 21 Mar '17

21 Mar '17

Mal eine Frage zu den Einträgen in der master.cf, die bei mir beginnt mit: # smtp inet n - n - - smtpd -o content_filter= smtp inet n - n - - smtpd Ist das richtig so? Ich hänge die ganze master.cf noch mal dran. Und auch die main.cf. Ist da irgendwas falsches zu entdecken? postgrey läuft als daemon postgrey --pidfile=/var/run/postgrey.pid --daemonize --inet=127.0.0.1:10029 --delay=120 --max-age=20 Für jede Hilfe bin ich dankbar. Grüße Christoph

1 0

Re: ich werde der Spamflut nicht Herr - postfix amavis-new dovecot
by Christoph Kukulies 21 Mar '17

21 Mar '17

Nehme an, Du meinst postgrey (/etc/default/postgrey). Wenn ich die Zeile greylisting = permit_dnswl_client list.dnswl.org, permit_dnswl_client swl.spamhaus.org, check_policy_service inet:127.0.0.1:10029 einbaue, bekomme ich postconf: warning : /etc/postfix/main.cf unused parameter: greylisting=permit_dnswl_client list.dnswl.org, permit_dnswl_client swl.spamhaus.org, checkp_policy_service inet:127.0.0.1:10029 Habe jetzt postgrey als daemon an port 10029 laufen (/etc/default/postgrey ) Die Meldung geht weg, wenn ich smtpd_restriction_class = greylisting, internal reinsetze. Kann ich zwei Einträge in smtpd_restriction_class setzen? Grüße Christoph Am 20.03.2017 um 11:56 schrieb simoon: > HI, > > ja, du musst die zeile auf den postgrey port ändern, kanste du im > postgrex configuriern. > > gruss > > alex > > > > Am 14.03.2017 um 11:01 schrieb Christoph Kukulies: >> Ich habe eine postgrey zwar laufen, wird aber wohl nicht im Eingriff >> sein, oder? >> >> Wie sieht der postgrey Eintrag in der master.cf bei Dir aus? >> 1200 ? Ss 0:00 postgrey --pidfile=/var/run/postgrey.pid >> --daemonize --inet=127.0.0.1:60000 --delay=120 --max-age=20 >> >> Zumindest nicht auf dem port. Würde es reichen, in Deinem Beispiel >> die 10026 auf 60000 zu ändern? >> >> Grüße >> Christoph >> >> >>> And then there is a postgrey instance running on 127.0.0.1:10026 >>> >>> hth >>> André >> >> >

2 2