bloodstix
Goto Top

"Delivery reports" von ausländischer Domain blocken

Hallo zusammen,

wir bekommen seit gestern vermehrt E-Mails mit Betreff "Delivery report" von postmaster@airsar.asf.alaska.edu, postmaster@advance.ucdavis.edu, postmaster@epubs.surrey.ac.uk und 1-2 weiteren mit z.B. folgendem Inhalt:
Hello, this is the mail server on epubs.surrey.ac.uk.

I am sending you this message to inform you on the delivery status of a
message you previously sent.  Immediately below you will find a list of
the affected recipients;  also attached is a Delivery Status Notification
(DSN) report in standard format, as well as the headers of the original
message.

  <ashley.aguilar@hotmail.com>  delivery failed; will not continue trying


Original-Envelope-Id: 24088_912317_49201_0
Reporting-MTA: dns;epubs.surrey.ac.uk
X-PowerMTA-VirtualMTA: 172.31.37.250
Arrival-Date: Thu, 12 Dec 2019 12:03:23 +0000

Final-Recipient: rfc822;ashley.aguilar@hotmail.com
Action: failed
Status: 5.5.0 (unknown protocol-related status)
Remote-MTA: dns;hotmail-com.olc.protection.outlook.com (104.47.14.33)
Diagnostic-Code: smtp;550 5.5.0 Requested action not taken: mailbox unavailable.
X-PowerMTA-BounceCategory: hardbnc


MIME-Version: 1.0
From:  BitcoinCode <Support@Lv8.de>
Subject: Become a Bitcoin millionaire today! 
Reply-To: BitcoinCode <reply@surrey.ac.uk>
Received: from surrey.ac.uk (172.31.37.250) by surrey.ac.uk id kfCsrwflLErR for <ashley.aguilar@hotmail.com>; Thu, 12 Dec 2019 13:03:24 +0100 (envelope-from <Support@77z.de>
To: ashley.aguilar@hotmail.com
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="UTF-8"  
Date: Thu, 12 Dec 2019 13:03:24 +0100
List-Unsubscribe: <mailto:axnkDEklawrNVt.sara@wetteam.asia?subject=unsubscribe&body=unsubscribe>

Oder 2. Beispiel:
Hello, this is the mail server on airsar.asf.alaska.edu.

I am sending you this message to inform you on the delivery status of a
message you previously sent.  Immediately below you will find a list of
the affected recipients;  also attached is a Delivery Status Notification
(DSN) report in standard format, as well as the headers of the original
message.

  <flyingpigs_69@hotmail.com>  delivery failed; will not continue trying


Original-Envelope-Id: 23305_912286_266992_0
Reporting-MTA: dns;airsar.asf.alaska.edu
X-PowerMTA-VirtualMTA: 172.31.22.133
Arrival-Date: Wed, 11 Dec 2019 12:41:22 +0000

Final-Recipient: rfc822;flyingpigs_69@hotmail.com
Action: failed
Status: 4.4.4 (unable to route: dns lookup failure)
X-PowerMTA-BounceCategory: routing-errors


MIME-Version: 1.0
From:  Exclusive offer for deodorant <Support@God.de>
Subject: This deodorant gives the ultimate protection under your armpits!
Reply-To: Exclusive offer for deodorant <reply@asf.alaska.edu>
Received: from asf.alaska.edu (172.31.22.133) by asf.alaska.edu id iZ0fHBgjy7t1 for <flyingpigs_69@hotmail.com>; Wed, 11 Dec 2019 13:40:43 +0100 (envelope-from <Support@TZd.de>
To: flyingpigs_69@hotmail.com
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="UTF-8"  
Date: Wed, 11 Dec 2019 13:40:43 +0100
List-Unsubscribe: <mailto:hPGRpCzlACVtua.sara@wetteam.asia?subject=unsubscribe&body=unsubscribe>

Das sieht mir irgendwie so aus als ob es Bounce-Spam o.ä. ist. Weiss aber nicht, wie die auf unsere Adresse kommen.
Ich habe schon probiert die über "check_sender_access" im Postfix in den "smtpd_recipient_restrictions" abzuweisen, leider ohne Erfolg, die kommen weiterhin durch.
Jemand ne Idee dazu wieso wir diese Mails plötzlich erhalten und wie ich sie los werden kann?

Grüße
bloody

Content-Key: 524719

Url: https://administrator.de/contentid/524719

Ausgedruckt am: 29.03.2024 um 12:03 Uhr

Mitglied: NordicMike
NordicMike 12.12.2019 um 16:12:37 Uhr
Goto Top
Wahrscheinlicher ist, dass Deine Webseite gehackt ist und Du selbst als Spamschleuder wirkst.
Mitglied: 142244
142244 12.12.2019 um 16:20:29 Uhr
Goto Top
Hast du schon probiert neu zu starten?
Mitglied: bloodstix
bloodstix 12.12.2019 aktualisiert um 16:37:03 Uhr
Goto Top
Ne unsere Adresse taucht in der gesamten Mail nicht auf und ein Problem mit unserem Webserver kann ich auch ausschließen.
Komisch ist, das unsere Domain in der Empfänger-Kennung so geschrieben ist das einer der Buchstaben immer mittendrin groß geschrieben ist.
Blocken kann ich sie scheinbar nicht, weil im mail.log für diese Mails immer "from=<>" auftaucht, somit kann natürlich keine Absenderadresse geprüft werden :/
Mitglied: NordicMike
NordicMike 12.12.2019 um 17:50:02 Uhr
Goto Top
Deine Domain muss nicht vorkommen, es reicht, wenn Dein Webserver Mails versenden kann und dabei fremde Absender verwendet. Ist der Mailserver und der Webserver auf der gleiche IP? Mach mal ein Blacklist Check mit Eurer IP.
Mitglied: bloodstix
bloodstix 12.12.2019 aktualisiert um 19:45:40 Uhr
Goto Top
Hallo @NordicMike der Webserver, auf dem ein Wordpress läuft, hat keinerlei Mailkonfiguration aber ich sag meinem Kollegen der dafür zuständig ist er soll mal das WP prüfen.
Unser Mailserver hat hingegen kein Webserver oder PHP o.ä.
Blacklist-Check bei mxtoolbox hat auch für keine unserer IP-Adressen was gefunden.
Mitglied: LordGurke
LordGurke 12.12.2019 aktualisiert um 22:20:36 Uhr
Goto Top
Hast du eure Domain hier in den Beispielen eventuell mit "TZd.de" und "77z.de" anonymisiert und es steht in Wirklichkeit eure Domain darin?
Und werden diese Bounces an jeweils diese Adresse "Support@TZd.de" bei euch geschickt?

Falls ja: Das ist "normaler" Backscatter, der mit sehr hoher Wahrscheinlichkeit nicht von euren Systemen ausgeht - zumindest behaupten die Mailserver in den Bounces, sie hätten die Mail von irgendeiner internen RFC1918-IP erhalten und es sind keine weiteren Received:-Header vorhanden.
Das kann nur aus deren internen Netz kommen face-wink

Mehr zu dem Thema hier: Wenn die eigene Domain für Spamversand missbraucht wird und was man dagegen tun kann

NACHTRAG:
Realistisch betrachtet dürfte das aber den Backscatter schlechtestenfalls noch verschlimmern - hier haben wir offenbar das Problem, dass die internen Mailserver der Uni keine Absenderverifikation machen und dann Bounce-Nachrichten senden.
Wenn man jetzt mit den oben genannten Tipps dafür sorgt, dass das möglichst weitreichend als gespoofete Absender erkannt und dadurch abgelehnt wird, bekommt man in dieser speziellen Konstellation mehr Backscatter.
Du könntest E-Mails von extern mit Null-Sender ("<>") ablehnen oder wegsortieren und würdest damit erstmal die Auswirkungen bei euch reduzieren.
Nichtsdestotrotz kann ein SPF-Record helfen, damit die Spammer aufhören, eure Domain zu missbrauchen.


@NordicMike:
Zitat von @NordicMike:

Deine Domain muss nicht vorkommen, es reicht, wenn Dein Webserver Mails versenden kann und dabei fremde Absender verwendet. Ist der Mailserver und der Webserver auf der gleiche IP? Mach mal ein Blacklist Check mit Eurer IP.

Dann bekäme er auch keine Bounces sondern die gespoofeten Absender-Adressen. Und erst Recht nicht mit solchen Received:-Headern, die ausschließlich RFC1918-Adressen enthalten.
Das kann schlichtweg nicht durchs Internet gekommen sein.
Mitglied: bloodstix
bloodstix 13.12.2019 um 09:20:49 Uhr
Goto Top
Hallo LordGurke, nein an den Listings oben ist nichts anonymisiert. Die sind genau so bei uns eingegangen.
SPF-Record haben wir eigentlich... hm.
Ich schau mal was ich mit dem wegfiltern von "Null-Sendern" erreichen kann.

Gruß
bloody
Mitglied: jannen
jannen 13.12.2019 um 10:32:29 Uhr
Goto Top
Seid ihr schon weitergekommen; wir haben das gleiche Problem.
Mitglied: bloodstix
bloodstix 13.12.2019 um 10:57:45 Uhr
Goto Top
Hallo @jannen nein leider nicht bisher. Sind das bei euch die selben ausländischen Domains?
Mitglied: jannen
jannen 13.12.2019 um 13:54:09 Uhr
Goto Top
Ja, epubs.surrey.ac.uk und airsar.asf.alaska.edu und mittlerweile auch telegraph.co.uk. Alles hotmail/MSN Adressen. Unser Server ist bei DF - hatten hier schon verdacht, dass es hier etwas nicht stimmt.
Mitglied: jouric
jouric 13.12.2019 aktualisiert um 14:20:10 Uhr
Goto Top
Hallo, wir sind auch betroffen:
Generierender Server: epubs.surrey.ac.uk
xMorphineStar-nVts-@hotmail.co.uk
hotmail-com.olc.protection.outlook.com (104.47.38.33)
Remote Server returned '<hotmail-com.olc.protection.outlook.com (104.47.38.33) #5.5.0 smtp;550 5.5.0 Requested action not taken: mailbox unavailable.>'
Mitglied: Lueder
Lueder 13.12.2019 aktualisiert um 15:13:36 Uhr
Goto Top
Wir sind hier auch betroffen.
Die sendenden Maschinen sind alle irgendwelche AWS-Maschinen, ich habe Dutzende gefunden.

Die Maschinen melden sich aber alle mit einem falschen bzw. gefälschten HELO, z.B. airsar.asf.alaska.edu

Ich habe folgendes im Postfix getan:

In der main.cf

smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks
check_helo_access hash:/etc/postfix/helo_access
...

In der /etc/postfix/helo_access:

airsar.asf.alaska.edu REJECT
epubs.surrey.ac.uk REJECT

Dann eben

postmap /etc/postfix/helo_access
und postfix reloaden.

Funktioniert ganz prima und geht lediglich von der Annahme aus, dass wir von epubs.surrey.ac.uk und airsar.asf.alaska.edu ohnehin keine Mails erhalten werden.
Mitglied: bloodstix
bloodstix 13.12.2019 aktualisiert um 16:11:28 Uhr
Goto Top
Hi @Lueder,

jau das funktioniert. Besten Dank. Bei uns sinds mittlerweile schon 6 verschiedene.
Hab mich leider zu früh gefreut. Beim direkten Test per Telnet wurd das EHLO abgelehnt.
Wir erhalten aber leider unsere Mails von nem vorgeschalteten Spam-Filter-Provider, und kriegen
daher auch bei diesen Mails natürlich nur den EHLO von diesem unserem Anbieter zu sehen und nicht
den von "epubs.surrey.ac.uk". Also zurück ans Reißbrett *g*

Grüße
bloody
Mitglied: Lueder
Lueder 13.12.2019 um 17:57:01 Uhr
Goto Top
Dann bliebe noch die Möglichkeit einer Content-Filterung.
Alle Mails enthalten "sara@wetteam.asia?subject=unsubscribe&body=unsubscribe".
Das ist aber auch doof, denn dazu muss man die Mail erstmal annehmen.

Andererseits, dieser Spamfilter-Provider kann nicht erkennen, das die HELOs alle gefaked sind?
Mitglied: LordGurke
LordGurke 14.12.2019 aktualisiert um 20:10:24 Uhr
Goto Top
Ich habe hier bemerkt, dass auf einer Domain von uns auch sowas versucht anzukommen - allerdings auf einer Domain, unter der wir keine E-Mails annehmen, weshalb das bisher nicht aufgefallen ist.
Daraufhin habe ich mal die Mailserver-Logs von den Servern, die ich für Kunden betreue, danach dursucht und erkenne ein Muster:

Diese Art von Spam kommt nur auf Domains die exakt drei Zeichen lang sind und auf ".de" enden.
Eine ebenfalls dreistellige Domain, allerdings auf ".at" endend, bekommt diese Mails nicht.
Die Mails werden immer an "Support@xyz.de" adressiert, wobei "Support" immer exakt so geschrieben wird und das Casing des Domainteils variiert.

Hier habe ich mal auf unserer eigentlich ungenutzten (drei Zeichen langen) Domain eine solche E-Mail angenommen und mir genauer angesehen.


Die E-Mail wurde eingeliefert von der IP 176.34.129.221 (Amazon Cloudfront Ireland):
< 220 mx-in1.xxxxxxxxxxxx.de ESMTP
> EHLO eventbrite.co.uk
< 250-mx-in1.xxxxxxxxxxxx.de
< 250-PIPELINING
< 250-SIZE 68157440
< 250-STARTTLS
< 250-ENHANCEDSTATUSCODES
< 250-8BITMIME
< 250 DSN
> MAIL FROM:<> BODY=8BITMIME
> RCPT TO:<Support@xxx.de>
> DATA
< 250 2.1.0 Ok
< 250 2.1.5 Ok
> 354 End data with <CR><LF>.<CR><LF>


Zugestellt wird dann diese Nachricht - auch hier ist wieder das Muster erkennbar: Alle Mailadressen, die als Absender in der NDN genannt werden, sind alle drei Zeichen lang und liegen unter ".de".
Date: Sat, 14 Dec 2019 16:16:35 +0000
From: postmaster@eventbrite.co.uk
Subject: Delivery report
To: Support@xxx.de
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
    boundary="report5DF52117@eventbrite.co.uk"  


--report5DF52117@eventbrite.co.uk
Content-Type: text/plain

Hello, this is the mail server on eventbrite.co.uk.

I am sending you this message to inform you on the delivery status of a
message you previously sent.  Immediately below you will find a list of
the affected recipients;  also attached is a Delivery Status Notification
(DSN) report in standard format, as well as the headers of the original
message.

  <snickerz_nc@hotmail.com>  delivery failed; will not continue trying

--report5DF52251@eventbrite.co.uk
Content-Type: message/delivery-status

Original-Envelope-Id: 24173_919394_34211_0
Reporting-MTA: dns;eventbrite.co.uk
X-PowerMTA-VirtualMTA: 172.31.18.78
Arrival-Date: Fri, 13 Dec 2019 16:12:02 +0000

Final-Recipient: rfc822;snickerz_nc@hotmail.com
Action: failed
Status: 4.4.2 (bad connection)
Remote-MTA: dns;hotmail-com.olc.protection.outlook.com (104.47.45.33)
X-PowerMTA-BounceCategory: bad-connection

--report5DF52117@eventbrite.co.uk
Content-Type: text/rfc822-headers

MIME-Version: 1.0
From:  Breaking Deals UK  <Support@Ciy.de>
Subject: Final Message for snickerz_nc
Reply-To: Breaking Deals UK  <reply@co.uk>
Received: from co.uk (172.31.18.78) by co.uk id xCsKaWEn15a for <snickerz_nc@hotmail.com>; Fri, 13 Dec 2019 17:16:33 +0100 (envelope-from <Support@yRH.de>
To: snickerz_nc@hotmail.com
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="UTF-8"  
Date: Fri, 13 Dec 2019 17:16:15 +0100
List-Unsubscribe: <mailto:nhwzlsuaacxhh.sara@wetteam.asia?subject=unsubscribe&body=unsubscribe>

--report5DF52117@eventbrite.co.uk--

In der (angeblich) gebounceten Mail enthalten ist ein "X-PowerMTA"-Header.
PowerMTA ist eine Software, die für den massenhaften Versand von E-Mails eingesetzt wird und dabei Analysefunktionen bietet, welche Adressen erreicht werden konnten und welche nicht.

Ich würde sagen, dass wir sehr sicher ausschließen können, dass die Empfänger dieser Mails dafür selbst verantwortlich sind.
Filtern lassen dürften sich solche E-Mails mit einem Filter, der kombiniert prüft auf:
  • Envelope-Sender ist "<>"
  • Envelope-Recipient beginnt mit "Support@" (Case-Sensitive)

Envelope-Sender- und Recipients sind die Adressen, die während der SMTP-Transaktion angegeben werden.
Wenn sich diese nicht per Filterregel prüfen lassen kann man testen auf:

  • Header "From:" beginnt mit "postmaster@"
  • Header "To:" beginnt mit "Support@" (Case-Sensitive)
  • Message-Body enthält "X-PowerMTA" (optional)


Ich habe aber beim Besten willen keine Idee, was dahinter steckt.
Interessanterweise kommen alle Mails, die auf dieses Muster passten, von IP-Adressen aus der Amazon-Cloud.
Einige Absender-Domains (eventbrite.co.uk, telegraph.co.uk) verwenden tatsächlich die Amazon-Cloud und sitzen auch basierend auf den IP-Adressen in der selben Region wie die Server, die die Mails geschickt haben.
Es könnte daher möglicherweise sein, dass das PowerMTA-Installationen sind, die tatsächlich von Eventbrite oder Telegraph genutzt werden und schlecht gesichert sind, sodass jetzt irgendwelche Bots diese Installationen missbrauchen.
Immerhin hat laut Privacy Statement der Telegraph tatsächlich eine Verbindung zu Eventbrite.
Mitglied: bloodstix
bloodstix 14.12.2019 aktualisiert um 21:41:20 Uhr
Goto Top
Hi @LordGurke,

nicht schlecht. Ist mir auch schon ins Auge gestochen mit den 3-Buchstaben-Domains.
Ich werd mal ne Mail an die Abuse-Abteilung von Amazon schicken, ma schauen was da zurück kommt.

Vielen Dank für die Mühe.

Grüße
bloody