Fails von TrendMicro und Bosch

Ihr wollt, daß bei Euch auf dem Mailserver Emails von vaiden Absendern ankommen? Da nehmt mal nicht TrendMicros AI Appliance, deren Daten sind leider nicht so verläßlich, wie es das Thema erfordert. Nur weil AI dransteht, muß es nicht besser sein.

Was ist mit TrendMicro passiert?

Nun ja, ich wollte der Volkshochschule in Braunschweig eine Email senden und die ging fast 48h nicht raus, sondern wurde absichtlich in einer Warteschleife festgehalten, auf meinem Server wohlgemerkt. Das lag an der Antwort den die TendMicro Instanz von sich gegeben hat (450 temporärer Fehler), nur so temporär wie er sein sollte, war er nicht 🙂

Die IP des Servers, der keine Kundenpräsenzen hat und seit über 16 Jahren keine Spams gesendet hatte, stand bei der tollen KI Lösung in der Liste „kürzlich“ erfolgten Spamprobleme. Da scheint TrendMicro eine andere Vorstellung zu haben als ich, was „kürzlich“ meint. Da Sie keinen echten Grund angegeben haben, was auch schwierig werden dürfte nach 16 Jahren, werden wir das wohl nie erfahren 😉

Einzig positiver Lichtblick: Das Entsperren per Removerequest ging deutlich schneller 😉

Und was ist jetzt mit Bosch?

Liebe Bosch-(Tochter)-IT,

wir schreiben das Jahr 2026. In 2016 gab es EU-weit eine eher unbeachtete Einführung von Datenschutz für Firmen, da steht drin zu lesen, daß der Transport von Personenbezogenen Daten dem Schutzniveau der Daten entsprechend nur noch verschlüsselt passieren darf, wenn das mit zumutbar geringen Aufwand leistbar ist. Ich stelle fest: Das ist es.

Da ich da nicht ganz unbeteiligt dran war, hier ein interessanter Link für Euch: 20210616_orientierungshilfe_e_mail_verschluesselung.pdf

Kommen wir wieder ins Jahr 2026 zu Bosch:

2026-11-02 13:49:01 H=mail.qbrx.com (mail.my.qbrx.com) [85.184.248.248] F=no-reply-portal@em-mail.bosch-nexospace.com rejected RCPT REDACTED@REDACTED.de: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.

und ja, das war heute, ja das waren Personenbezogene Daten, denn die DSK hat gesprochene Emailadressen wie name.vorname@ u.ä. als Personenbezogene Daten definiert und um noch eins drauf zu legen, der Server kann TLS 1.3, wenn man sich hin verbindet, er nutzt es nur nicht, wenn er Mails versendet. Das ist jetzt blöd gelaufen für Bosch 🙂

 

ABO-Betrugsemail von support@servicegpthtlp.com

Wer von Euch CHATGTP im ABO benutzt sollte jetzt unbedingt auspassen, daß er nicht abgezockt wird:

Die Mail ist, auch wenn Sie außerhalb des Sichtbereiches behauptet, nicht von Open AI. Die Domain des Absender wurde erst heute Nacht registriert und ich behaupte mal, die würde auch ohne mein Zutun in 2 Tagen wiede verschwinden, weil es bei Ami Registraren so etwas wie 3 TAGE PROBEDOMAINS gibt, ohne das man dafür zahlt 😉

Hier die Daten zur Domain servicegpthtlp.com

[Querying whois.verisign-grs.com]
[Redirected to whois.cloudflare.com]
[Querying whois.cloudflare.com]
[whois.cloudflare.com]
Domain Name: SERVICEGPTHTLP.COM
Registry Domain ID: 3130929456_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.cloudflare.com
Registrar URL: https://www.cloudflare.com
Updated Date: 2026-08-11T01:59:25Z
Creation Date: 2026-08-11T01:59:22Z

Der Server steht bei Hetzner in Finnland und das ist schon eine Besonderheit, weil deren Server erst nach 30 Tagen Mails senden dürfen, die das aber sofort geschafft haben.

Aber… Cloudflare hat schon den Stecker gezogen, die Domain ist nicht mehr erreichbar, weil es keine DNS Auflösung mehr gibt. Da hat es der Scammer wohl mächtig übertrieben 🙂

 

Ist imap sicherer als pop3?

Autsch.. der letzte Artikel über Outlook hat ganz schön viele  Kommentare im Netz erzeugt, weniger hier an der Quelle, sondern auf Reddit, FaceBlöd und Slashdot, weil ich mir dachte, ich schreib da mal einen „Danke dafür Fedora 43“ Artikel ins Fedora-Magazin. Tschuldigung, mache ich nie wieder 😀

Ist IMAP sicherer als POP3?

Ich hätte nie gedacht, daß ich mich mal damit befassen müßte, aber ok, hier ist die Antwort…. Trommelwirbel… Pompongeraschel… „Nein!“

Ok, Danke, ich bin dann mal weg …   ok, also, das ist so:

DISCLAIMER: Der Inhalt stark simplifiziert, so daß alle folgen können, wers genau wissen will, zieht Euch die RFCs aus der Zeit rein. 

Das letzte Jahrtausend

POP3 und IMAP haben mit unverschlüsselten Verbindungen auf Port 110 und 143 angefangen und das schon weit vor 1998. Dabei wurden wegen PLAIN TEXT die Passwörter in Klarschrift übermittelt. Da das irgendwann abgefangen wurde, hat man tatsächlich erstmal nur die Authentifizierung verschlüsselt… oder so ähnlich… unglaublicherweise galt BASE64 damals als Schutz und die simple Login Methode war BASE64.encode(„username:password“). Ja, Facepalm ich weiß.

Als irgendwann Verschlüsselung in die Welt Einzug hilt, dachte man sich: Machen wir doch einfach einen TUNNEL von einem anderen Port (995) auf dem wir eine SSLv2/3 Verbindung vor den Klartextport ( 110 ) schalten .. dann leiten wir einfach das normale Protokoll was sonst zu 110 gegangen wäre dadurch. Das hat das Problem bis heute an sich gelöst.Das gleiche machte man für IMAP mit Port 993 der dann intern auf 143 ging.

SSL/TLS

Diese Tunnel hatten aber ein Problem dessen Ursache im SSLv2/3 liegt: Man kann vorher nicht sagen für welche Domain das ist, deswegen gibt es so nur ein Zert vom Server zurück, das meisten dann den Hostnamen vom Server hatte. Das hat sich erst mit der Einführung von SNI geändert, wo man vor dem Zertaustausch sagen konnte welches Zert für welche Domain man sehen will. Das machte es etwas besser. Das TLS nach der SSL Nachfolger ist, hatte es zu Beginn die gleichen Probleme.

Der Nachteil: man hatte zwei Ports, einen für alte unsichere Klienten, und einen neuen Port für begabte Programme mit Verschlüsselung. Resultat: Erhöhung der Komplexität in der Programmlogik und der Grafischen Bedienung und was das zur Folge hatte steht hier:

Outlook hat Emailverbindung nicht verschlüsselt

STARTTLS

Es gab aber noch einen konkurrierenden Ansatz: STARTTLS (STLS) . Dabei wird erstmal eine Klartextverbindung aufgebaut und gefragt „Hey Server, was kannst Du denn so an Zeugs“ und dann konnte man sehen, ob der STLS konnte oder nicht. Wenn er es konnte, wurde eine sichere Verbindung ausgehandelt und dann erst Username und Passwort übermittelt.

Der Vorteil: man brauchte die GUI nicht umbauen, weil das mit dem Portwechsel nicht nötig war. Man mußte also nur im Programm einen Block einfügen, der tested ob STARTTLS geht und es ggf. tun, danach gings normal weiter.

Im Endeffekt ist das beides gleichwertig, weil das Ergebnis das gleiche ist, mit einem nicht so entscheidenden Unterschied, bevor man STLS aktivierte wäre es möglich gewesen zu sagen, für welche Domain das Zert gebraucht wird und das ohne SNI. AFAIk, hat das aber so keiner implementiert.

Was die Fehleranfälligkeit angeht, liegt STARTTLS nach Punkten vor, trotzdem war das am Anfang eher unbekannt und POP3S und IMAPS haben sich zunächst durchgesetzt. Das konnten am Anfang fast alle Programme.

Fazit

Nehmt bitte eins von beiden, aber testet auch, ob das wirklich funktioniert. Wie ich das im Fedora Artikel beschrieben habe, könnt Ihr das einfach testen: Schickt Euch selbst eine Email und schaut in die Emailheader rein. Ihr findet Zeilen wie diese:

Received: from bastion01.fedoraproject.org ([38.145.32.11] helo=bastion.fedoraproject.org)
by s113.resellerdesktop.de with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384
(Exim 4.99.2)
(envelope-from <updates@fedoraproject.org>)
…

Jeder gute MTA( MailTransportAgent) aka Server wie Exim,Postfix usw. schreiben das dazu. Wenn man da nichts sieht ist es entweder nicht verschlüsselt gewesen, oder der MTA ist ein Ignorant 😉  Dann braucht Ihr ein ROOT-Terminal und TCPDUMP um den Netzwerkverkehr zu analysieren:

tcpdump -A -n -n port 110 or port 143

Wenn Ihr dabei den Inhalt Eurer Email sehen könnt, wars nicht verschlüsselt. Ende der Geschichte.