Frank Carius hat mich die Woche auf Twitter auf einen neuen Blog-Beitrag von ihm aufmerksam gemacht. Im Beitrag IONOS SMTPAUTH Fail beschreibt Frank, wie seine Absenderadresse carius.de in einer Spam-Welle missbraucht wurde. Bei der Analyse stieß Frank darauf, dass eine schwache Konfiguration bei seinem Provider 1&1/IONOS existiert. Jeder mit gültigem 1&1-Mail-Konto kann beliebige Absenderadressen in Mails angeben, also unter fremden Segeln unterwegs sein. Carius sieht eine Lücke in der Mail-Sicherheit, während das für IONOS ein "works-as-expected" ist.
Anzeige
Der Stein des Anstoßes
Als Frank Carius eines Tages sein E-Mail-Konto in Outlook inspizierte, wurde er regelrecht von einer Welle an Mails erschlagen, die nicht an den Empfänger zugestellt werden konnten. Nachfolgender Screenshot zeigt die Mail delivery failded: returning message to sender Einträge in Outlook.
Mail unzustellbar-Fehler, Quelle: Carius
Wenn man sieht, dass da massenhaft Mails als unzustellbar zurückkommen, und die Zeitstempel sieht, könnte man auf die Idee kommen: "Mein Postfach wurde gehackt und ein Spammer verschickt darüber Mails" – jedenfalls solange man selbst keine Massen-E-Mails über sein Postfach verschickt. Frank Carius war sich sicher, dass er dies nicht getan habe und begann mit der Analyse, was wohl passiert sein könnte. Schnell war klar, dass er Opfer einer NDR-Backscatter-Geschichte geworden ist. Microsoft erklärt es hier genauer:
Backscatter sind Unzustellbarkeitsberichte (auch als Unzustellbarkeitsberichte oder Unzustellbarkeitsnachrichten bezeichnet), die Sie für Nachrichten erhalten, die Sie nicht gesendet haben. Der Rückläufer wird durch Spammer verursacht, die in ihren Nachrichten die Absenderadresse (auch als
5322.FromP2-Adresse bezeichnet) fälschen (Spoofing). Spammer verwenden häufig echte E-Mail-Adressen als Absenderadresse, um ihren Nachrichten Glaubwürdigkeit zu verleihen. Wenn Spam an einen nicht vorhandenen Empfänger gesendet wird, wird der Ziel-E-Mail-Server im Wesentlichen dazu verleitet, die unzustellbare Nachricht in einem NDR an den angegebenen Absender in der Mail zurückzuschicken.
Der Spammer hatte wohl Mails mit der Antworten-Adresse carius.de verschickt – und jede unzustellbare Mail wurde dann bei Frank Carius in dessen Postfach gespiegelt. Bei dieser Gelegenheit erhielt Frank Carius von den Empfängern, die existieren, noch eine Reihe weiterer Rückläufer – beispielsweise "Out of Office"-Abwesenheitsmeldungen mit Informationen, die Dritte eher nichts angehen. Und es gab einen Empfänger, der auf die SPAM-Mail hereinfiel und nachfragte, wie das Kennwort zu ändern sei.
Anzeige
Die Analyse und unschöne Erkenntnisse
Frank Carius analysierte das Ganze und kam zum Schluss, dass die Nachrichten von "Kundenserver.de" erstellt wurden. Das war auch der Server, den Carius bei 1&1 für seinen Webserver, die Mail-Server seiner Domain carius.de verwendete. Die Vermutung eines Hacks bestätigte sich glücklicherweise nicht.
Backscatter Mail Header, Quelle Carius.de
Da es immer heißt "schaut euch den Mail-Header an", denn Absenderadressen kann der Spammer fälschen, hat Frank Carius einen Blick in die Details geworfen und obigen Screenshot veröffentlicht. Sieht wirklich so aus, als ob die Mail von carius.de verschickt worden wäre. Aber die received-Zeile des Servers gab eine IP-Adresse an, die Carius bei Vodafone verortete.
Frank Carius hat das Ganze im Beitrag IONOS SMTPAUTH Fail dokumentiert. Sein Versuch, bei Vodafone mit einer Abuse-Meldung weiter zu kommen, lief ins Leere. Dann der Versuch, per Telefon bei Vodafone jemanden zu erreichen, um weiter zu kommen, scheitete auch. Ein Telefon-Bot versucht die Anrufe zu kanalisieren und verlangt dann eine Kundennummer, die Carius aber nicht hat (ist ja kein Kunde).
Erinnert mich an meinen Versuch, ein Guthaben auf einer wegen längerer Nichtbenutzung gesperrten Vodafone Prepaid SIM-Karte erstattet zu bekommen. Ich habe keine Kundennummer, ohne diese lässt der Bot einen aber ins Leer laufen. Das ist ein Saftladen, wo Du als Kunde bei Problemen verhungerst. Die Prepaid SIM-Karte stammte noch von Mannesmann, die ja von Vodafone feindlich übernommen wurden.
Nachdem Carius bei Vodafone nicht weiter kam, versuchte er noch bei IONOS nachzuforschen, warum die Mails angenommen wurden, obwohl sie offenbar nicht von carius.de stammen konnten. In seinem Beitrag IONOS SMTPAUTH Fail dokumentiert er dann einen Hammer. Wie es sich darstellt, existiert bei der Konfiguration des IONOS 1&1-Mailservers eine Lücke. Denn jeder authentifizierte Benutzer eines 1&1-Mail-Kontos kann eine beliebige Absender-Adresse in Mails verwenden. Das umfasst auch Absenderadressen aus einer Domain, die nicht zum eigenen Benutzer oder zum Vertrag passt.
Damit stand fest: Carius war nicht gehackt und das Mail-Konto nicht von einem Spammer missbraucht worden. Vielmehr hat Carius die Schwachstelle in der Konfigurierung bei IONOS 1&1 verortet. Der Kontakt mit dem 1&1-Security-Team war dann aber doch etwas ernüchternd. Das beschriebene Verhalten wurde als "works-as-expected" bezeichnet, wie man nachfolgender Mail entnehmen kann.
Antwort von IONOS, Quelle: Carius
Ich habe hier nur einen kurzen Abriss dessen, was Frank herausgefunden hat, dokumentiert. Den Spammer, der wohl einen MaxBulk-Mailer verwendet, konnte er nicht identifizieren. Carius will aus den gewonnenen Erkenntnissen heraus wohl seine Domain bei 1&1/IONOS zu einem anderen Anbieter verlagern. Die Details lassen sich bei Frank Carius im Beitrag IONOS SMTPAUTH Fail nachlesen.
Anzeige
ich bin auch bei 1&1 und froh, dass ich deren SMTP-Server als smart host für meine verschiedenen Email-Adressen verwenden kann.
Das Problem liegt woanders: Mailserver sollen derartige Fehlermeldungen gar nicht verschicken, sondern am besten schon bei der Aushandlung eine Verbindung ablehnen, genau weil es so einfach ist den Absender zu fälschen. Typischerweise führt dieses Verhalten dazu, dass der Mailserver in Spamlisten landet und dann gar keine Mails mehr losbringt bis das in Ordnung gebracht ist. Ich gebe zu, dass mir das vor vielen Jahren auch schon passiert ist…
das Problem ist, dass diese Mailserver überhaupt einen NDR schicken. Üblich ist schon den Verbindungsaufbau abzulehnen, wenn es den Empfänger nicht gibt. Und das sollte man auch so einstellen, da man sonst ganz schnell auf den bekannten Spammer-Listen landet.
IIRC verschickt die zum Teil der Kundensever.
Sie mussten den SMTP Server auf eine Art proxy umbauen, der sofort eine Verbindung mit dem Ziel aufbaut, so das dieser Server den Empfänger prüfen und rejecten kann damit der Kundensever die Email noch auf den letzten Drückermit einer 550 abschließen kann und keinen NDR schicken muß.
Geht, gibt es. Aber… You get what you pay vor.
DkIM ist da einfacher
You get what you pay for.
.
Das ist keine Lücke sondern Standard. Jeder kann sich selbst mit einem SPF Eintrag schützen.
In diesem Fall greift der SPF-Eintrag aber nicht. Damit der legitime Besitzer mit SPF Mails versenden kann, müssen die IONOS Mail-Server in diesem enthalten sein. In der beschriebenen Konstellation verwendet der Spammer dann den gleichen Server. Durch den korrekten SPF-Eintrag wird ehr noch eine Sicherheit suggeriert, welche tatsächlich gar nicht exisitiert.
Auch ist SPF ehr eine Krücke, da man als Inhaber einer Domain keinen Einfluss hat, ob ein Mail-Server beim Empfang einer Mail den SPF-Eintrag auch wirklich prüft. Klar sollte man trotzdem einen setzen, aber eine Wunderwaffe ist das nicht.
Gruß Singlethreaded
Ich kamn ionos vollkommen verstehen.
Der Kunde hat sich Autentisiert, also darf er alle Domains benutzen die er mag.
Es ist halt die Aufgabe des Kunden meinen Mailserver für seine Domain frei zugeben. Ich habe i. D. R. keine Möglichkeit festzustellen ob der Kunde das darf (whois Abfrage? Ne)
Ich kann meinen Mailserver veranlassen nachzusehen ob er im SPF der verwendeteb Domain steht, fas also seitens des Domain besitzers darf.
Würde ich, wie z. Telekom Kunden nur erlauben telekom Domains zu versenden wäre das unlauter.
Wobei Telekom noch den Vorteil gat, das ihr auch die IPs gehören.
Dieses Wettbewerb verzerren Verhalten ist das, was Frank fordert.
Der Fehler liegt aber trotzdem bei Ionos:
Sie hätten die Email garnicht annehmen dürfen, wenn nicht sicher war, das die diese zustellen konnen.
Ihr Mailserver hätte den Empfänger fragen müssen, kennst Du den? Dafür gibt es den Befehl VRY(verify).
Ein weiteres, das ein großer Teil der Empfänger auch nicht prüfen ob sie den Empfänger kennen, und wenn nicht rejecten (da aber ionos die Email angenommen hat, schickeb sie den NDR an den falschen Absender.
Mit einem Reject würde die Email an die einliefernde IP zurucj geehen. Frank würde davo nihts mitbekommen.
Aber so schön ist due Welt nicht.
Und sollen die Terroristen uns wieder ein Stück Freiheit genommen haben?
Das ich zufällig seine Domains hoste, wie soll das geprüft werden?
Klar, jeder Mailer hat die Option zu gucken welcher DNS dafür zuständig ist. Wenn es meiner Ist, geht es duch.
Da steht aber nicht, wem die Domain gehört.
Das Problem wird vielleicht mit etwas Geschichte klarer.
Es gab einmal eine Zeit da kannte sich jeder im Internet und man vertaute sich.
So entwickelte man ein einfach Email Protokoll. SMTP.
Viele User hatten nur ein Modem, konnten u. U. Nur uucp. Die due ein IP bekamen waren sauer wenn der, der die Email bekommen sollte nicht auch online war.
Sie warfen daher die Email auf einen stationären Email Server, oft an einer uni, ab.
Ich sehe gerade die großen Augen bei den jüngeren.
Ja, damals gehörte es zum guten Ton, ein offenes Relay betreiben. Also emails von Dritten an Dritte weiter zuleiten. Wahnsinn aus heuiger Sicht.
Aber es hat funktioniert.
Dann ging das mit dem Spamen los, und man musste die offene Relays zu bekommen ohne seine eigenen User zu bemachtigen.
Als Uni oder Provider kannte man die IP seiner Kunden und schaltete diese IP frei.
Dass ging solange gut, bis die Kunden einen eigenen Provider nutzen konnten.
Das war dann der Moment in dem es zu smtp-after-pop3 kam. Später smtpauth.
Fällt wem auf, das die Absender-Domain nie eine Rolle gespielt hat?
Nein das ist nicht korrekt.
Schau dir Office 365 an. Dort muss ein Konto für den Versand einer bestimmten Adresse freigegeben.
Alles andere geht gar nicht …
Outlook als Referenz Implementation?
Wenn dem Client verboten wird eine Bestimmte Absender Adresse zu nutzen ist das das Problem den absendenden SMTP Servers. Spammer interessiert das aber nicht.
Das das mit dem Triätylenblei so schlimm ist hätte ich nicht gedacht :)
Wieso Problem. Es sollen von diesem Server, den ich bspw. mittels SPF explizit dazu berechtige, nur Emails verschickt werden bei denen der Domaininhaber einem Nutzer dafür die Berechtigung erteilt hat. Und eben nicht jemand wildfremdes.
Spätestens wenn Nutzer in deiner Organisation, Emails mit gültigem Absender und dubiosen Inhalt aller IT-Hotline@deindomain.com, Admin@deinedomaim.com, Drucker@deinedomain.com usw. bekommen, dann wirst auch du feststellen, dass das ein Problem ist.
Bei mir* gibt es bspw. keinen Grund wieso Nutzer Emails von Emailadressen meiner Domain bekommen, die außerhalb des Tenant erzeugt wurden. Und nichts anderen ist SPF inkl. einer funktionierenden Berechtigungssteuerung.
*) Kann bei anderen anders sein, aber deswegen erlaube ich trotzdem nicht die Einlieferung von beliebigen Absendern…
Bei dem SPF zur carius Domain fiel mir auf, das dort 3 andere SPF-records eingebunden werden.
Ich habe jetzt weder Zeit noch Lust das zu analysieren,
Aber SPF erlaubt eine nur 2 stellige Anzahl an Hosts in der Liste. Ist diese Liste zu kang, wird der SPF einfach ignoriert, weil soviel DNS Aufrufe zu teuer werden.
Aber SPF hätte hier eh nicht geholfen.
3 Weiterleitungen zu eigenen SPF (performa, ionos, outlook) hat er drin.
Insgesamt kommt er dadurch, daß ganze Subnetze(!) durchgereicht werden, auf
_spf.perfora.net
62+30 (IPv4)
_spf.kundenserver.de
126+62+126+30+62 (IPv4)
spf.protection.outlook.com
131070+65534+262142+32766 (IPv4)
spfd.protection.outlook.com (inkludiert in spf.protection.outlook.com) (IPv4)
254+254+30+1+30
Die IPv6-Adressen klemme ich mir mal, weil ich keinen Bock habe zu prüfen, ob sie auf die IPv4 gelegt wurden, oder tatsächlich eigenständige Adressräume sind.
Wir kommen also in Summe auf eine Anzahl von 492.579 legitimierten Servern, die von der Url carius.de aus Mails senden dürfen.
Schön: Hard-Fail, statt Soft-Fail. Unschön: Bei der schieren Anzahl potentieller Systeme, kann man sich SPF als Funktion auch gleich schenken.
*Bevor nun wieder Kommentare kommen alá "Du hast aber jeweils 2 IP-Adressen abgezogen!". Richtig. Erste Ziffer des Subnetzes = Netzadresse, Letzte Ziffer des Subnetzes = Broadcast; für eigene Nutzung tabu (RFC 950).
Danke für's Rechnen.
Das ist auch der Preis den man für die Cloud zahlt:
Man hat keine feste IP mehr.
Das ist so als wollte man Emails von einem dynamischen Dialup versenden (was früher mal absolut üblich und gängig war)
Sehe ich wie ionos, works-as-expected. Das Problem ist ja nicht das Feature, sondern dass ein gültiger ionos Account für Spam misbraucht wurde und DKIM ist ja schon angekündigt.
Das der Email Absender als Information generell keinen Wert besitzt, ist jetzt hoffentlich keine Neuigkeit.
Ich verstehe nicht wie man das als "works-as-expected" sehen kann?
Dh jeder andere 1&1 Kunden bzw. der Verwender eines entsprechenden Kundenaccounts kann Emails mit deiner Absenderadresse mit relativ hohem Trust verschicken.
Dh es wäre ok für dich, wenn ich bspw. "du bist 1 Pimmel" vermeintlich mit deiner Absenderadresse verschicken würde.
Unter Verwendung von SPF sollte soetwas eigentlich gar nicht möglich sein.
Spammer verwenden gültige Adressen nicht, um glaubwürdiger zu erscheinen. Sondern um überhaupt haupt die Email loswerden zu können, da Smtp prüfen müssen ob der Absender funktioniert, um später den NDR zustellen zu können.
Auch gibt es immer noch Systeme, die im NDR die komplette Spammail enthalten. Da seriöser Host…
Es gibt Möglichkeiten zu erkennen, ob das ein legimtimer Bouce ist.
Vermutlich meint Ionos das, wenn sie von DKIM etc sprechen.
Ja, das würde wohl helfen wenn die Emails von 3 kamen
Aber nicht hier…
Das ist so einfach nicht richtig, da SMTP nur einen Empfänger vorschreibt, gibt es keine Möglichkeit einen Absender zu testen oder authentifizieren. Es gibt nur SPF um zumindest das Problem etwas zu entschärfen.
Wenn Du eine email zur Weiterleitung annimmst, bist Du für die Zustellung verantwortlich, oder?
Was machst Du, wenn es den Empfänger nicht gibt?
Und den Absender auch nicht?
Kippst Du das in /dev/null weil, wenn der Absender so blöd ist, seinen Absender richtig zu schreiben dann ist er selbst schuld…
Echt, ist das Deine Denke?
Wenn auf meinen Mailserver eine Email ankommt prüfe ich ob ich sie Zustellen kann und wenn nicht, rejekte ich die Email. So bekommt auch jeder DAU mt, das die Email nicht angekommen ist, weil sein Server ihm das sagt.
Kann ich aber nicht während des conneczs sehen ob es den Empfänger gibt, dann muß ich den Absender prüfen damit ihn der Ziel host erreichen kann
Denn es besteht das große Risiko, das dieser auch deb Absender prüft. Und dann steht mein Server da, mit einer Email, die er angenommenen hat und wirft sie weg?
Für den Absender (es gibt nicht nut Spammer) siegt es so aus, als wäre die Email angekommen.
Wird klar wo das Problem ist?
Warum man schon einen Absender braucht und diesen ggf. Prüfen muss?
(wenn es bulk email ist, für die man keine Antwort braucht nimmt man natürlich ""… Aber da einige Admis einfach zu ungebildet sind, wird "no-reply@.." verwendet…
HTH?
PS
Natürlich muß man auch für den Fehler fall wie"msil box voll" den Absender erreichen können.
Ich sofern würde ich gerne wissen, woher du das aast, dass kein Absender nötig sei?
Emails können nicht verloren gehen!
Es gibt im Prinzip eigentlich noch eine "Error Mail box", in die völlig umzustellbare Emails landen sollten, die ein Mensch lesen und abarbeiten muss.
Em, wer soll das heute noch machen?
Natürlich kann ich während dem Empfang der Email diese ablehnen bspw auf Basis der Server IP, des to, from, subject oder sontiger Parameter.
Der Vorteil ist, dass sich der MTA nicht mit NDR aufhalten muss. Es besteht aber das Risiko von Brute Force Angriffen, bspw. auf die Empfänger Emailadressen (To). Das muss man dann eben anders kompensieren.
Ich finde den reject auf Basis von ungültigen Domains, hohem Spamverdacht oder Bulk Emails aber gar nicht so verkehrt. Va. weil es die Spam Mails in den Junk-Foldern erheblich reduziert.
Ja, reject ist heute das Mittel der Wahl.
"Stand der anerkannten Technik"
Nun stell Dir Anbieter von Schlangenöl, die auch dicke fette Email Server an bieten um Spam und Viren zuscannen vor. Der ungebildete Admin will das haben.
Je mehr er ausgelagert hat, desto weniger Verantwortung muß er haben. Ausserdem fragen neue Arbeitgeber schon mal danach für welches Budget er verantwortlich war und welche Systeme er kennt…
Der Preis den die Schlangenölverkäufer verlangen hängt vom Volumen ab. Ab z. B. 100000 Emails wird es teuer. Admin schaut in sen log:
Wenn'S hoch kommt 1000.. 3000Emails pro Tag.
Mit Spam 10000.
Also ein super lohnes Angebot.
Was der Admin nicht weiß: Spammers nutzen nur einen Teil der Bandbreite (Kuh die man melkt..)(frag mich nicht wie sie das hinbekommen)
Je höher die Bandbreite, desto mehr Spam.
Und diese Schlangenöl Verkäufer haben fette Bandbreite und etliche MX parallel.
"Leider leider" können sie nicht prüfen, ob es den Empfänger gibt und leiten alles zum Ingress Server des Kunden weiter. Der verschickt dann zig tausende NDR von seiner IP. Da der Admin zwar ganz toll mit dem AD um kann, hat er noch nie etwas von RBLs gehört hat, auf dem sein egress Server nun wegen Back-scatter landete. Da auch niemand den Abuse Account von allen spamfiltern freigeschaltet hat und ihn eh niemand liest (wie auch den postmaster-account) bekommt er gar nicht mit..
Und für Franks NDR Problem haben sie auch eine eigene, properitare, patentierte Lösung, gegen Aufpreis.
Natürlich nicht DKIM. Aber der von NDR genervte Admin bestellt es, Chefffle zahlt ja…
Derartige Dienstleister braucht man nicht. Heutzutage gibt es bei den großen Clouddiensten integrierte Lösungen.
Und jetzt komm mir nicht mit bösen Clouddiensten. Wenn ich einen externen Anbieter mit der Spamfilterung beauftrage, dann macht es anschließend auch keinen Unterschied mehr, ob ich die Emails in der Cloud speichere oder nicht.
Anyway, ich habe auch kein Bock mich mit meinen beiden Dienstleistern zu beschäftigen, die sich ewig die Schuld gegenseitig in die Schuhe schieben, wenn etwas nicht funktioniert.
Das Problem mit rejects in großen MX Systemen ist aber, die Brute Force Versuche zuverlässig zu erkennen, wenn die Anfragen mittels Load Balancer auf unterschiedliche Zielsystem laufen.
Exchange Online ist da aber eben nicht "Stand der anerkannten Technik". Wenn die Domain gültig ist, dann wird die Email angenommen. Gut Microsoft hat aber vermutlich auf ausreichend Bandbreite um fast jeden On-prem Server zu DDos'en :-) Was aber vrmtl. auch daran liegt, dass einen Serverpool (inkl. gesonderte IP Bereiche) haben, der nur für NDRs zuständig ist …
Es gibt den SMTP Befehl VRFY
Damit kann man einen Server fragen, ob er die Email zustellen kann.
Leider ist dieser heute zumeist gesperrt.
Aber man man kann mit einem RCPT auch feststellen, ob der Absender gültig ist.
Ob der zum Schreiben mit dieser Adresse berechtigt ist, ist erstmal egal, einst SMTP vom Guten im Menschen ausging.
Würden alle Server Reject machen, wäre vieles einfacher. Aber bei Groskampfkisten wird das sehr aufwendig.
"Leider ist dieser heute zumeist gesperrt."
ZU RECHT! In der heutigen Zeit ein Problem, denn der wird missbraucht, um herauszufinden, welche Mail-Adressen in einer Domain existieren. Warum soll der Server so 'blöde' sein und treudoof Auskunft geben?
Konnte man 'früher' mal machen, als das Internet noch 'in Ordnung' war.
Noch mal an Frank:
Ja, das ist total ärgerlich, aber es hört rel schnell auf, da die Postmaster der Opfer Deine Domain ganz flott in den Spam Filter packen. Ist ja einfach.
So läuft auch so ein DDos rel. schnell aus.
Hat sich ja schon gezeigt.
Hallo Paul du hast ja einige Postings hier geschieben und ich möchte nur eines zu bedenken geben
1. IONOS betreibt ein "shared Hosting", d.h. viele Kunden und Domains nutzen die gleichen Mailserver
2. Als Kunde kann ich per SMTP AUTH eine Mail an IONOS geben, damit diese die Mail weiter senden. Das ist gelebte Praxix
ABER
3. IONOS prüft dabei nicht, ob der authentifizierte Benutzer dazu berechtigt ist. Und das ist der Fail Der Mailserver sollte nach dem SMTPAUTH prüfen, ob die versendete FROM/SENDER-Adresse auch dem Benutzer oder zumindest dem Kunden gehört.
und das macht IONOS nicht.
Ich kann mich also mit meinen Zugangsdaten anmelden und dann eine beliebige Absenderadresse spoofen, solange die andere Domain selbst Kunde bei IONOS ist.
Das Telekombeispiel trifft nicht. Wenn jemand eine "T-online.de"-Adresse nutzt und den Mailserver der Telekom zum Versand verwendet, dann sollte auch auf genau diese T-Online-Adresse beschränkt sein. ODER der Provider bietet im den Service als andere benannte Domain zu senden.
Wir sind hier noch lange vor einer Analyse des Zielsystems über SPF o.ä.
Der SPF-Record ist laut https://mxtoolbox.com/SuperTool.aspx?action=spf%3acarius.de&run=toolpage auch OK. die Include sind legitim, solange man nicht mehr als 10 DNS Queries damit produziert. Dass es am Ende "viele" Adressen sind, ist den großen Providern geschuldet.
Aber noch mal. Es geht hier nicht um die anonyme Einlieferung von Mails von irgendwo an mein Postfach bei IONOS, welches IONOS danke SPF nicht verhindert, sondern um den Versand einer Mail mit meiner "guten" Adresse über legitime Server von IONOS nach extern. Kein externe Empfänger kann diese Mail als Phishing aussortieren, weil SPF, DKIM und DMARC korrekt sind. Der Fehler ist beim SMTP-Service, der authentifizierte Verbindungen annimmt.
Die anderen Dinge wie VRFY (greift nicht bei der Nutzung als Smarthost mittels SMTPAUTH) und NDR Backscatter sind nur Folgeerscheinungen.
Meine Entscheidung ist gefallen. Die Domain wird zu einen anderen Provider wechseln. Ich muss nur noch schauen, wer einen besseren Spamschutz bietet und das mit den anderen Familienmitgliedern (neue IMAP-Adresse) zeitlich abstimmen :-)
"Works as expected" sagt IONOS.
Dann seht euch mal das an:
https://www.borncity.com/blog/2022/04/26/vorsicht-rechnungs-spam-e-mail-von-ionos-mit-verschlsselungstrojaner/
Unterm Strich unterstützt IONOS hier die Ransomware-Mafia. Danke auch, toller Service.
Alle E-Mailprodukte der United Internet AG (zu der auch die Ionos SE (früher 1&1 Ionos SE (früher 1&1 Internet SE (früher 1&1 Internet AG))) zählt) waren schon immer fail.
Welcher Provider ist denn nicht fail?