16
"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:
Oder 2. Beispiel:
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
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 524719
Url: https://administrator.de/forum/delivery-reports-von-auslaendischer-domain-blocken-524719.html
Ausgedruckt am: 08.01.2025 um 23:01 Uhr
16 Kommentare
Neuester Kommentar
Wahrscheinlicher ist, dass Deine Webseite gehackt ist und Du selbst als Spamschleuder wirkst.
Hast du schon probiert neu zu starten?
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 :/
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 :/
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.
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.
Unser Mailserver hat hingegen kein Webserver oder PHP o.ä.
Blacklist-Check bei mxtoolbox hat auch für keine unserer IP-Adressen was gefunden.
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
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:
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.
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
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.
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.
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
SPF-Record haben wir eigentlich... hm.
Ich schau mal was ich mit dem wegfiltern von "Null-Sendern" erreichen kann.
Gruß
bloody
Seid ihr schon weitergekommen; wir haben das gleiche Problem.
Hallo @jannen nein leider nicht bisher. Sind das bei euch die selben ausländischen Domains?
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.
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.>'
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.>'
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.
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.
Hi @Lueder,
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
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
1
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?
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?
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):
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".
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- 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:
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.
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.
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
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
