IONOS SMTPAUTH Fail

Diesmal hat sich jemand zum Ziel gesetzt, meine Domain "carius.de" zu missbrauchen und indirekt mein Postfach mit NDRs (Siehe auch NDR-Backscatter) zu füllen. Natürlich bin ich kein Spammer aber es hätte ja sein können, dass mein Konto bei IONOS gehackt und damit missbraucht wurde. Also habe ich mir das dann mal genauer angeschaut, zumal ich mit einem SPF=-all doch alles richtig gemacht haben sollte:

Diese Seite beschreibt eine Spam-Welle, bei der meine Absenderadresse "carius.de" genutzt und damit eine schwache Konfiguration bei meinem Provider IONOS aufgedeckt hat. Was ich als Lücke bezeichne, ist für IONOS ein "works-as-expected". Machen Sie sich ihr eigenen Bild.

Randbemerkung: Ein Leser der MSXFAQ hat das gleiche Verhalten auch bei Strato/rzone.de nachstellen können.

Auslöser

Ich öffne ohne böse Vorahnung mein Outlook und der Posteingang präsentiert unaufgeräumt:

Ich habe sicher keine Mails versendet und damit ist schon schnell klar, dass jemand eine meiner Absenderadressen missbraucht haben muss und ich wieder mal Opfer eines NDR-Backscatter geworden bin. Die Hauptwelle hat nach einigen Stunden dann wieder aufgehört aber einige Nachzügler hab es noch die folgenden Tage. Die List hier ist also nur ein Ausschnitt.

Interessant waren aber auch die anderen Rückmeldungen, die ich begutachten durfte. Es gibt wohl immer noch Relay-Systeme und Spamfilter, die eine Mail erst annehmen und danach einen NDR senden. Auch einige "Automatische Antworten" und "Out of Office"-Meldungen waren dabei, die teils Informationen enthielten, die ich nicht so versenden würde. Die Krönung war aber eine Rückmeldung eines Empfängers, wie er denn sein Kennwort ändern könnte. Der ist also auf die Mail sogar eingefallen.

NDR-Retails

Ich habe mir dann so einen NDR einmal genauer angeschaut: Es ist ein NDR, der von "Kundenserver.de" erstellt wird. Der Server gehört zur IONOS-Gruppe, bei der ich zufällig auch einen Webserver und die Domain "carius.de" betreibe. Sollte mein Konto tatsächlich "gehackt" worden sein sein?

Ohne lange zu zögern habe ich mein IMAP/POP/SMTP-Kennwort vorsorglich geändert. Im Nachhinein war das aber nicht relevant.

Dennoch sah die Mail so aus, als ob ich sie wirklich gesendet hätte.

Interessant ist hier die erste und einzige "Received:"-Zeile, die der Spammer nicht fälschen kann, da "kundenserver.de" diesen Eintrag addiert. Hier versucht der einliefernde Server eine falsche Fährte zu legen, weil er sich mit einem "HELO 46.21.153.173" meldet, aber vom Provider gesehene reale IP-Adresse ist die 95.89.147.17.

95.89.147.17 -Vodafone/Kabel Deutschland

Der Absender steht also mitnichten in den USA bei  Hivelocity Inc sondern ganz regulär in Deutschland:


https://ipinfo.io/AS3209/95.88.0.0/14-95.89.144.0/22

Ich habe keine Dienste bei Vodafone, so dass damit auch keiner meiner Server hinter "Deutsche Glasfaser" als Quelle gelten kann.

Leider kann nicht aus dem Header nicht erkennen, ob der einliefernde Server irgendwie "authentifiziert" wurde, denn eigentlich dürfte ja niemand mit meiner Absenderadresse eine Mail versenden.

Wenn die Quell-IP 95.89.147.17 dynamisch vergeben wird, kann der Provider diese zu einem Kunden zuordnen. Sollte es sich aber um eine im Rahmen von CarrierGradeNAT gemeinsam genutzte Adresse handeln, dann wird es knifflig, denn der Header enthält z.B. nicht den Source-Port der Verbindung. Der Provider müsste dann schon mehr Daten durchforsten, um viele SMTP-Verbindungen von einem Kunden zu erkennen. Aber auch dann könnte sich der Kunde drauf herausreden, dass er selbst gehackt wurde oder jemand über sein Gäste-LAN den Zugang missbraucht habe. Ich habe dennoch mal eine Meldung an die ABUSE-Adresse gesendet. 

Datum Vorgang

21.7

Telefonanruf - kein Erfolg

Ich habe am 21.7.2022 um 22:09 versucht, per Telefon bei vodafone jemanden zu erreichen, um hier Licht ins Dunkel zu bringen. Der normale Weg per Web oder Telefon habe ich dann entnervt abgebrochen. Der Web-Bot verweist mich nach kurzer Zeit auf 022146619100 und der Versuch dann über den Sprachcomputer eine sinnvolle Auswahl zu erreichen, gelang nicht ohne Identifizierung als Kunde über eine Rufnummer oder Kundennummer. Über diese Wege spricht man wohl nur mit Kunden.

22.7 01:09

Mail an abuse.de@vodafone.de

Zu dem Subnetz ist diese Adresse angegeben worden. Ich habe in einer Mail die Zusammenhänge beschrieben und um die Möglichkeiten einer Identifizierung des realen Absenders gebeten.

??

keine Antwort

Diese Mailadresse scheint entweder niemand zu lesen oder meine Mail wurde einfach ignoriert oder nicht ernst genommen. Warum richtet man dann einen Abuse-Account ein, den niemand liest und anscheinend hat man kein Interesse. Da braucht man sich nicht zu wundern, wenn die IP-Adressen mal auf einer Blacklist landen.

Das hilft IONOS hier aber nicht, denn eine authentifizierte Verbindung der eigenen Kunden sollte man ja schon annehmen.

Anscheinend reagiert Vodafone nicht auf formlose Informationen oder Anfragen. Hier würde es dann wohl nur mit einer Strafanzeige weiter gehen. Da eine Spam-Mail bzw. NDR-Spamming aber nicht mit Drohmails, Mordaufrufen, Terrorismus, Kinderschändung o.ä. zu vergleichen ist, erspare ich erst mal den Aufwand.

Open Relay 213.165.67.119?

Eigentlich bin bin ich recht sicher, dass IONOS kein offenes Relay betreibt. Aber vielleicht gibt es ja einen Konfigurationsfehler und da wollte ich dann doch mal schnell was testen. Im Header steht ja auch die IP-Adresse (213.165.67.119) des Mailservers drin. Also mal schnell einfach einen TELNET auf Port 25 gemacht und ein Spoofing versucht:

Ich bin auch zufällig auf dem gleichen Server gelandet und eine so einfache Anfrage hat der Server natürlich unterbunden. Ein "offenes Relay" ist der Server zumindest von meiner Client-IP-Adresse nicht. Ich denke aber nicht, dass Vodafone oder Kabel Deutschland eine andere Konfiguration bekommt. Testen kann ich es nicht.

Relay mit Authentication Lücke?

Der "richtige Spammer" könnte sich aber irgendwie authentifiziert haben. Auf der Seite SMTP-Telnet habe die technischen Hintergründe beschrieben aber es geht auch bequemer. Ich habe mir also ein Tool gesucht, welche eine SMTP-Mail mit meiner Mailadresse senden kann, aber ein anderes IONOS/1und1-Konto nutze. Dabei hilft das SMTPDiagPro-Tool von Stefan Kittel sehr gut:

Ich habe es wie folgt parametrisiert und als "Authentication User" ein gültiges Konto eines anderen IONOS-Vertrags genutzt, was nichts mit "carius.de" zu tun hat.

Nach einem Druck auf "Start" war die Mail auch weg. Zur Sicherheit habe ich noch mal in das Logfile (etwas gekürzt) geschaut:

SMTPDiagPro Version 1.14
Created: 21.07.22 22:21:53

Preparing frank.carius@netatwork.de

Sending mail to frank.carius@netatwork.de
Send mail from frank@carius.de to frank.carius@netatwork.de

Type: Single hostname
Remote host: 213.165.67.119:25
Local hostname: FC-T480S
Encryption: No encryption
Username: xxxxxxxxx@mantke.de
Subject: SMTPDiagPro testmail 21.07.22 22:21:53 (1 of 1)
Attachments: no attachments

Info::Connect 213.165.67.119:25
Recv::220 kundenserver.de (mreue106) Nemesis ESMTP Service ready
Send::EHLO FC-T480S
Recv::250-kundenserver.de Hello FC-T480S [94.31.82.213]
Recv::250-8BITMIME
Recv::250-AUTH LOGIN PLAIN
Recv::250-SIZE 140000000
Recv::250 STARTTLS
Send::AUTH PLAIN
Recv::334 
Send::**********
Recv::235 Authentication succeeded
Send::MAIL FROM:frank@carius.de
Recv::250 Requested mail action okay, completed
Send::RCPT TO:frank.carius@netatwork.de
Recv::250 OK
Send::DATA
Recv::354 Start mail input; end with .
Send::From: frank@carius.de
Return-Path: frank@carius.de
To: frank.carius@netatwork.de
Content-Type: text/plain
Subject: SMTPDiagPro testmail 21.07.22 22:21:53 (1 of 1), remote type:
, remote host: 213.165.67.119:25 (No encryption), localhost: FC-T480S,
username: erich@mantke.de, from: frank@carius.de, to: frank.carius@netatwork.de,
attachments: no attachments, no attachments
SMTPDiagPro testmail 21.07.22 22:21:53 (1 of 1)
remote type: 
remote host: 213.165.67.119:25 (No encryption)
localhost: FC-T480S
username: erich@mantke.de
from: frank@carius.de
to: frank.carius@netatwork.de
attachments: no attachments

This mail was send with SMTPDiagpro (http://www.smtpdiagpro.com)
.
Recv::250 Requested mail action okay, completed: id=1M5g68-1o8ZD92G3m-007Ddf
Send::quit
Info::Disconnect

Done...

Die Mail wurde versendet und die Anmeldung erfolgte mit dem Konto eines anderen IONOS-Vertrags. Da hat es mich dann auch nicht weiter verwundert, dass die Mail in meinem Firmenpostfach angekommen ist:

Ein Blick in den Header hat auch hier keine Spur auf den angemeldeten Benutzer geliefert.

Da scheint bei der Konfiguration des Mailservers eine Lücke offen zu stehen, über die jeder authentifizierte Benutzer eine beliebige Absender-Adresse verwenden kann. Auch aus einer Domain, die nicht zum eigenen Benutzer oder zum Vertrag passt. Das ist so hoffentlich nicht "Standard".
Allerdings bin ich schon etwas beruhigter, dass wohl doch keine Zugangsdaten von meinem Konto gehackt wurde.

Ich konnte sogar eine Mail mit einer komplett anderen Domain senden, die definitiv nicht bei IONOS gehostet ist. Allerdings sind diese Mails nicht angekommen, was aber auch an SPF liegen könnte. Einen NDR gab es aber auch nicht. Ich kann mir nur vorstellen, dass IONOS zumindest hier einen Schutz bei den ausgehenden Mailservern hat und Mails mit fremden Absender-Domains still unterdrückt werden. Wobei ich in dem Fall dann erst recht einen NDR erwartet hätte, wenn ich als Absender ja authentifiziert und damit zahlender Kunde von IONOS bin.

IONOS Security

Ich bin mit meiner "carius.de"-Domain noch Kunde bei IONOS und jeder sollte eine Chance bekommen, Konfigurationsfehler oder Sicherheitslücken erst einmal vertraulich gemeldet zu bekommen. Der Prozess dazu lautet "Responsible Disclosure" und hat bei BMW und Intel ja auch schon geklappt.

Entsprechend habe ich nach einem Zugang zum Security-Team gesucht

Datum Vorgang

21.7.22

2x Telefonanruf

Als Kunde von IONOS haben ich am 21.7 erst per Telefon den Kontakt gesucht aber für die Hotline war das Thema wohl nicht zu greifen und man bat mich eine Beschreibung an support@ionos.com zu senden. Für den normalen Support ist das aber wohl auch zu knifflig. Aber unter der "WellKnownUrl" https://www.ionos.de/.well-known/security.txt habe ich dann die Mailadresse als auch einen PGP-Key gefunden zum Security Teams gefunden. Also habe ich meine Entdeckung dort per Mail gemeldet.

21.7.22
23:20

Mail an security@ionos.com

Meine Ergebnisse habe ich als Art "Responsible Disclosure" an IONOS gemeldet. Ich gehe mal davon aus, dass diese "Funktion" so nichts gewünscht ist, dass jeder angemeldete Benutzer jede beliebige Domain eines anderen IONOS-Kunden missbrauchen kann. Ich habe eine Mail mit allen mir bis dahin bekannten Details und Schritte zur Nachvollziehbarkeit gesendet. Eigentlich hatte ich gehofft, dass sich jemand recht schnell meldet. Wenn die Adresse so gut versteckt ist, sollten ja vielleicht wirklich Menschen reagieren. Auch eine Verschlüsselung per PGP habe ich erst mal verzichtet, da ich meine Mails per STARTTLS an die Mailserver von IONOS einliefere und der Provider doch hoffentlich seine eigenen Server unter Kontrolle hat.

22.7..22
08:13

Auto Reply

Interessanterweise hat es dann doch bis zum nächten Morgen gedauert, bis eine automatisierte Meldung angekommen ist. Ich kann nur vermuten, dass hier dann jemand die Mail gelesen und intern an die Fachabteilung weiter gereicht hat.

22.7.22
11:29

Antwort: "works-as-expected"

Schneller als Intel und BMW ist IONOS hier allgemein. Allerdings hat mich dann die Antwort doch etwas verwundert.

Das Verhalten ist wohl nicht nur bekannt sondern sogar gewünscht, damit Kunden auch mit anderen SMTP-Adressen ihrer eigenen Domain versenden können.

Das ist aber keine Erklärung, warum es keine Einschränkung auf die Domains des Vertrags gibt

Der Absender hat wohl auch verstanden, welche negativen Einfluss dieses aktuelle Verhalten auf die SPF-Bewertung hat.

22.7.22
16:32

In einer Rückantwort hatte ich darauf auch hingewiesen und gefragt, wie ich denn nun an die Information über den authentifizierten Benutzer kommen könne und ob ich die Antworten zitieren darf.

25.07.22
08:56

Für diese Antwort hat das Team nun doch ein paar Tage länger gebraucht.

02.08.22
15:16

IONOS Support meldet sich per Mail und bittet mich, Beispiele der NDR samt Header über eine URL bereitzustellen. Anscheinend schlägt dieser Artikel doch noch die ein oder andere Welle. Auszug aus der Mail, der mich schon etwas zum schmunzeln gebracht hat. :-)

KD hat sich öffentlich beschwert und wirft mit Fachbegriffen um sich. Bitte mal prüfen:

02.08.22
19:18

Die Bereitstellung per Browser hat leider nicht geklappt. Vielleicht lag es an der ZIP-Anlage, was aus der Meldung aber nicht hervorgeht.

Ich habe dann einige Mails als ZIP-Anlage als Antwort unter Beibehaltung der TicketID gesendet und bekam eine automatische Antwort als Eingangsbestätigung mit dem Hinweis, dass nach 12h eine Rückmeldung erfolgt

8.8.22

Noch keine Rückmeldung.

Was aus meiner Sicht ein "Fehler" ist, wird bei IONOS wohl nicht so schlimm eingeschätzt und soll erst 2023 mit der Einführung von DKIM vielleicht beschränkt werden. Ein Eigeninteresse, den realen authentifizierten Absender zu ermitteln scheint es nicht zu geben.
Ob ich deswegen nun eine Strafanzeige stelle, lasse ich mal offen. Kunde. Das dürfte aber nichts bringen, denn bei den Millionen Kunden und damit kompromittierbaren Konten reicht ja ein beliebiges Konto, um Mails mit Adressen anderer Kunden zu senden und der Absender könnte ja einfach behaupten, er selbst wäre gehackt geworden.

SPF/DMARC ausgehebelt

Nun könnte ich sagen, dass das doch kein Problem ist. Schließlich könnte ja jeder einen Mailserver aufsetzen und als "carius.de" senden. Das stimmt soweit schon, aber als Inhaber von "carius.de" kann ich z.B per SPF, SenderID und DMARC dem Internet schon mitteilen, wer ein legitimer Absender ist. Die Einträge habe ich auch entsprechend gesetzt.

  • Der SPF-Eintrag endet mit einem "-ALL"
C:\>nslookup -q=TXT carius.de

carius.de       text = "v=spf1 include:_spf.perfora.net 
                               include:_spf.kundenserver.de 
                               include:spf.protection.outlook.com 
                               -all"
  • Und auch der DMARC-Eintrag hat ein "p=reject"
C:\>nslookup -q=TXT _dmarc.carius.de

_dmarc.carius.de        text =   "v=DMARC1; 
                                  p=reject; 
                                rua=mailto:p1myzbnv@ag.DMARCian-eu.com,mailto:dmarc2@carius.de,mailto:dmarc_agg@vali.email; 
                                ruf=mailto:dmarc2@carius.de"

Das ganz hilft dem Internet aber nicht, wenn die Mail über den gleichen Mailserver versendet wird, über den ich auch regulär sende und der damit auf der Liste enthalten ist. Das hier hier nämlich der Fall, weil die Domain "carius.de" noch bei IONOS gehostet ist und damit auch der Spammer, der das Mailrelay von IONOS mit einer fremden Anmeldung missbrauchen kann, davon profitiert.

Damit verschlimmert sich sogar das SPF-System, da ein Empfänger irrtümlich davon ausgehen könnte, dass die Mail authentisch ist. Da kann ich von Glück sagen, dass IONOS immer noch keine DKIM-Signatur anfügt oder sogar SMIME/PGG auf dem Gateway anbietet.

MaxBulkMailer-Details

Der Spammer war aber nicht ganz so schlau, da das verwendete Mailprogramm seine "Berichte" ebenfalls an meine Mailadresse sendet. Damit verrät er, dass er das Programm "MaxBulk Mailer Version 8.8.2-US) auf einem Windows 2012R2 Server nutzt und sich an "smtp.ionos.fr" per TLS1.2 anmeldet.

Laut dem Report ist das Programm sogar "registriert" aber leider ist keine Seriennummer o.ä. ersichtlich, um einen Rückschluss auf den Käufer zu bekommen. Im SMTP-Header der versendeten Mails gibt es auch keine entsprechenden Hinweise auf eine Seriennummer oder Käufer.

Return-Path: <frankx@carius.de>
Authentication-Results: kundenserver.de; dkim=none
Received: from mout.kundenserver.de ([212.227.17.13]) by mx.kundenserver.de
(mxeue010 [212.227.15.41]) with ESMTPS (Nemesis) id 1MJUU4-1nugut2sMi-00JqqH
for <frank@carius.de>; Thu, 21 Jul 2022 17:33:43 +0200
Received: from [46.21.153.173] ([95.89.147.17]) by mrelayeu.kundenserver.de
(mreue108 [213.165.67.119]) with ESMTPSA (Nemesis) id
1MPGNn-1nr6PT2m2n-00Pgo7 for <frankx@carius.de>; Thu, 21 Jul 2022 17:33:43
+0200
Message-Id: <AYPLHPRU-K7AZ-XHWP-1XV5-0DPM46OBLDTE@carius.de>
Date: Thu, 21 Jul 2022 16:33:41 +0100
To: "Support_Desk" <frankx@carius.de>
From: "MaxBulk Mailer" <frankx@carius.de>
Subject: [MaxBulk Mailer Delivery Report #280] Action Required:[Short Date]
X-Mailer: MBM 8.8.2-US (7)
Mime-Version: 1.0
Content-Type: multipart/alternative; Boundary="--=BOUNDARY_7211633_UVVE_NGVN_TJNC_ORVC"
X-Provags-ID: V03:K1:/LXB/BQx5rwx5uj6diZ5HEne1GnqCsntp8ojGU+rsKqUpMEkO1n
DKwyHdgjyXmj3PRg8/NsRJaY+FROfWhVPmsD6YDF7h4FZw2tuAJCyMkIMSb88CrtcgSlqgU
WUMlD3GWWJN5An9SWNjE3mfiuWf+BgpDb6f0NQBgFYNOSzDNluw+agdpDEi/lajzI6B6672
0fXj7WKoUXYl4mHoJyh6Q==
X-Spam-Flag: NO
...

Ich habe schon einige Reports bekommen:

So kann man auch gut die Wellen sehen, die der Service versendet.

Datum Vorgang

21.7 16:41

Anschreiben

Natürlich habe ich auch den Hersteller von MaxBulk Mailer gefragt. Vielleicht basiert die Lizenz auf der "Domain" und er könnte ermitteln, wer die Software für "´carius.de" gekauft hat.

25.7. 00:00

Rückantwort

Die Antwort war recht kurz und eigentlich auch korrekt. Schade nur, dass SPF aufgrund des Verhaltens von IONOS natürlich nicht greift.

The problem is piracy. Despite we try hard some people are sending pirated copies. I guess if your server spam filter checks for SPF headers most of the messages will be deleted.

25.7 00:56

Rückschluss über Domain?

Da SPF bei dem Problem nicht hilft, habe ich noch mal nachgefragt, ob die Lizenz nicht über die SMTP-Domain gebunden ist. Die Antwort hat das elegant ausgelassen:

Yes, our software is a standard mail client like any others. It requires a SMTP server. Nowadays there is no other way to send email. By the way any mail client can be used to send spam, even a free Gmail webmail account.
There is a post on our site about this: https://www.maxprog.com/site/blog/post.php?id=773&topic=Unusual-but-frustrating-support-requests The day everybody use DKIM/SPF/DMARC a lot of spam will disapear. 

Alles keine Neuigkeiten und schon lange bekannt.

Meldung im Portal

Ich habe mich während den Analysen auch auf meinem IONOS-Portal unter https://mein.ionos.de/hosting-overview angemeldet und hier habe ich eine interessante Meldung gefunden

Ich bezweifle aber, dass dies etwas mit dem SMTP-Missbrauch zu tun hat sondern eher Zugriffe per HTTP auf die Webseite sind. Das Wordpress wird durch ionos "gemanaged" und ansonsten gibt es keine PHP-Dateien oder andere Tools sondern nur statisch HTML-Dateien. Hier erwarte ich keine Probleme. Der Link auf "Weitere Details" zeigt dann auch keine Informationen zu diesen 77 Angriffsversuchen sondern landet direkt auf der Bestellplattform, mit der ich den Zusatzschutz "Site Scan + Repair" käuflich erwerben könnte. Im Portal sieht die Meldung dann viel ungefährlicher aus:

Ein Blick in die recht überschaubaren Logfile liefern nur "ungefährlicher" Zugriffe und ein Pentabot (https://webmaster.petalsearch.com/site/petalbot) sucht immer noch die ganz alten MSXFAQ-Seiten, die schon lange umgezogen wurden. Allerdings ackern sich wohl einige Anwender auf den Wordpress-REST-API herum und versuchen unsichere Wordpress-Installation zu ermitteln.

GET /frank/fcedv/frank/familie/frank/fcedv/fcedv/logbuch.htm 
GET /404.htm 
GET /wp-json/wp/v2/users/
POST /xmlrpc.php
POST /wp-cron.php?doing_wp_cron=xxxxxxxxxx
GET /wp-json/oembed/1.0/embed?url=http://carius.de
GET /?author=1
GET /?author=2
GET //wp-includes/wlwmanifest.xml
GET //blog/wp-includes/wlwmanifest.xml
GET /web/wp-includes/wlwmanifest.xml
GET //wordpress/wp-includes/wlwmanifest.xml
GET //website/wp-includes/wlwmanifest.xml
GET //wp/wp-includes/wlwmanifest.xml
GET //news/wp-includes/wlwmanifest.xml
GET //2018/wp-includes/wlwmanifest.xml
GET //2019/wp-includes/wlwmanifest.xml
GET //shop/wp-includes/wlwmanifest.xml
GET //wp1/wp-includes/wlwmanifest.xml
GET //test/wp-includes/wlwmanifest.xml
GET //media/wp-includes/wlwmanifest.xml
GET //wp2/wp-includes/wlwmanifest.xml
GET //site/wp-includes/wlwmanifest.xml
GET //cms/wp-includes/wlwmanifest.xml
GET //sito/wp-includes/wlwmanifest.xml
GET /typo3/sysext/felogin/ext_tables.sql
GET /typo3/sysext/impexp/ext_tables.sql
GET /3index.php
GET /wikindex.php

Damit muss wohl jeder Webserver leben, dass er abgescannt wird. Das hat aber alles nichts mit dem Spam-Mail-Versand zu tun und ich habe auch keine URL gefunden, die per HTTP einen Mailversand über eine mir nicht bekannte Lücke ausgenutzt hätte. Aber dann wäre auch sicher nicht die IP-Adresse von Kabel Deutschland aufgetaucht.

Zwischenstand

Was IONOS hier liefert ist aus meiner Sicht nicht zufriedenstellend und ich plane den Umzug meiner Domains zu einem anderen Hoster. Das geht nur nicht von heute auf morgen, da die carius.de-Domain auch von anderen Personen genutzt wird, bei denen ich dann auch die IMAP4/SMTP-Zugangsdaten anpassen und vor allem die Mails migrieren muss. Der unbekannte Spammer hat diese Lücke mit meiner Adresse auch nur für einige Stunden missbraucht. Der Leidensdruck ist aktuell also überschaubar aber es fühlt sich nicht nur falsch an, sondern es ist aus meiner Sicht auch eine Fehlkonfiguration mit Risikopotential. Wenn ich schon per SPF den Versand von Mails als "*@carius.de" auf meinen Provider beschränke, dann sollte der Provider sicherstellen, dass die Absenderadresse nicht gefälscht werden kann. Ein besonderes Risiko sind dabei natürlich all die Mailinglisten, die ein Management per Mail erlauben und sich auf die korrekte Absenderadresse stützt.

Da wäre die geplante DKIM-Einführung in 2023 auch nur ein Tropfen auf den heißen Stein und eigentlich müsste ich eine Domain bei IONOS lassen, um genau dann das Verhalten noch einmal zu prüfen. Es gibt ja durchaus noch weitere Seiten zum Thema 1&1/IONOS auf der MSXFAQ wie 1und1 Phishing und 1&1/IONOS und SBL

Eine Strafanzeige gegen Unbekannt werde ich wohl nicht stellen, denn welcher "Schaden" ist denn entstanden? Der Spammer hat ja nicht die Schlagworte Kindesmissbrauch, Terrorismus, Reichsbürger o.ä. verwendet sondern "nur "einen Brief mit meinem Namen versenden. Das könnte er theoretisch auch per Briefpost tun.

Weitere Links