Wir verwenden Office 365 als unseren primären E-Mail-Anbieter. Wir haben einen internen Mailserver, den wir zum Weiterleiten von Dingen wie Berichten von unserem SSRS, Scannen an den Posteingang für alte Scanner usw. verwenden. Es handelt sich um einen IIS SMTP auf Server 2008R2. Dieser Server ist durch die Firewall für keinen Dienst zugänglich, schon gar nicht für SMTP, und seine Verbindung und Weiterleitung sind auf die wenigen internen IP-Adressen in unserem Netzwerk beschränkt, die ihn als Weiterleitung verwenden. Wir verwenden ihn, weil nicht jedes von uns verwendete Gerät die Office 365-Dienste direkt nutzen kann (wir sind eine gemeinnützige Organisation und einige unserer älteren Geräte sind tatsächlich ziemlich alt), ebenso wie Prozesssteuerungsgeräte in unserer Fertigung, Dinge, die einfach kein authentifiziertes/TLS-SMTP zulassen. Um es kurz zu machen: Dieses System bietet dem lokalen Netzwerk mehrere wesentliche Annehmlichkeiten, und es sollte keinen Grund geben, warum wir diese Annehmlichkeiten nicht nutzen können sollten. Wir haben alle unsere Vorsichtsmaßnahmen getroffen, wir haben die richtigen DNS-Einträge für den Server. Ich habe SPF-Einträge für seine IP eingerichtet, der Name, den der Server bei der Zustellung ankündigt, wird in seine öffentliche IP aufgelöst. In dieser Konfiguration hat seit über 1,5 Jahren (seit der Migration zu Office 365) alles ohne Probleme wunderbar funktioniert.
Eines Tages wurden plötzlich alle von dort eingehenden E-Mails abgelehnt, weil sie in Spamhaus und CBL.abuseat gelistet waren. Spamhaus gibt an, dass sie dies über den CBL-Eintrag tun. CBL gibt an, dass wir wegen des Versands „erstaunlich großer Mengen Spam“ gelistet wurden. Sie geben den DNS-Namen dieses Servers als Quelle an. Sofern keine Telepathieprotokolle verwendet werden, sind es im Durchschnitt etwa 60, und wir haben nie mehr als 100 E-Mails pro Tag gesendet. Ich habe jetzt über drei Monate lang Datenverkehr aufgezeichnet, der nicht EINE EINZIGE Nachricht zeigt, die nicht von einer bekannten Quelle stammte und nicht für eine Adresse bestimmt war, an die wir normalerweise senden (99 % davon sind sowieso alle internen Adressen!). Also mal abgesehen von der Tirade, die die „Hilfeseite“ über alle möglichen Ursachen dafür ausspuckt, wie wir wahrscheinlich kompromittiert wurden, wie man nach Infektionen in Diensten sucht, die wir nicht einmal ausführen, usw. … Wir haben zweifelsohne verifiziert, dass diese Behauptung falsch ist, wir haben den gesamten Netzwerkverkehr von und zu dieser Maschine von einem gespiegelten Switch-Port mit Wireshark überwacht, wir haben den gesamten Verkehr an unserer Grenzfirewall überwacht, unser ISP hat uns dies von seiner Seite aus bestätigt, wir versenden einfach KEINE Mails, die wir nicht ausdrücklich versenden wollten. Von dieser Maschine oder dieser IP-Adresse. Dies ist nun bereits die vierte Anfrage zur Entfernung, die ich bei ihnen bearbeiten muss. Ich habe zwei E-Mails von ihrem System erhalten, da ich Beispiele der Mails angefordert habe, die angeblich von uns übermittelt wurden; eine ist eine wortwörtliche Kopie ihrer „Hilfeseite“ und eine Anfrage nach der fraglichen IP, die andere ist eine muntere Antwort, die wie ein Roboter formuliert ist, mit „Murray“ unterzeichnet ist und überhaupt nicht hilft. Eine davon schien eine vorgefertigte Antwort auf die IP-Anfrage der ersten zu sein, in der stand, dass diese bereits zur Entfernung übermittelt worden sei.
Wir haben Microsoft kontaktiert und erfahren, dass ihre Verbindungsfilterung vor unserer Administratorkontrolle erfolgt. Das bedeutet, dass das Festlegen eines „zugelassenen Absenders“ nutzlos ist, wenn die IP-Reputationsfilter uns trennen, bevor es dieses Niveau erreicht. Wir können uns also nicht selbst auf eine Whitelist setzen. Und sie übernehmen keinerlei Verantwortung für die Nutzung des Dienstes oder für die Tatsache, dass er den E-Mail-Verkehr zwischen unserem kostenpflichtigen Dienst und unserem Unternehmensnetzwerk auf eine Weise steuert, die keiner von uns ändern kann. Das Einzige, was wir uns überhaupt vorstellen können, ist, dassVielleichteine der Scan-to-Inbox-Nachrichten wird an einen übereifrigen Spamfilter irgendwo weitergeleitet und wir werden als Transportmethode in der Kette markiert. Ich stecke also fest und habe nichts, was ich tun könnte, ich kann Abuseat nicht bewegen, ich kann Microsoft nicht zum Einlenken bewegen, ich habe Beweise dafür, dass wir falsch gelistet sind, und keine gegenteiligen Beweise, die ich auch nur näher untersuchen könnte, und ich weiß überhaupt nicht, was ich tun soll, außer meine öffentliche IP-Adresse und alle davon abhängigen Dienste zu ändern. Ich habe mich in der Vergangenheit mit Open-Relay-Sicherung beschäftigt und die Folgen davon beseitigt, aber diese hier ist absolut nachweislich Schwindel und ich habe niemanden, mit dem ich mich befassen könnte. Aber sie haben uns in der Hand.