Kurzer Beitrag zum netten Thema Mailversand mit Exchange Online und der Problematik, dass Mails blockiert werden. Ein Nutzer bzw. Administrator hat mich kontaktiert, weil er in das Problem gerauscht ist, dass sein Mails blockiert werden und hofft auf die Schwarmintelligenz der Blog-Leserschaft. Ich stelle den Sachverhalt mal hier im Blog ein, vielleicht gibt es ja zielführende Hinweise.
Anzeige
Exchange Online verschickt keine Mails
Der Blog-Leser schreibt, dass er seit Anfang Mai 2024 mit einem massiven Problem seiner O365 Instanz kämpft und frage sich, ob er da wirklich alleine betroffen ist. Seine Hoffnung, dass ich vielleicht von anderer Seite, auch von Problemen mit dem Defender, gehört habe, muss ich verneinen. Es gibt zwar Beiträge im Blog, die sich mit Mail-Problemen unter Exchange beschäftigen. Aber das Problem des Lesers scheint anders gelagert zu sein, weil es immer mal wieder funktioniert.
Probleme seit Anfang Mai 2024
Der Leser schrieb: "Es hat am 02.05. begonnen". Ausgehende Mails mit Anhang bleiben seitdem massenhaft in der eigenen Quarantäne des Tenants hängen und werden als "Malicious" klassifiziert. Auf den ersten Blick findet der Nutzer keine Hinweise, was genau an diesen Mails "malicious" sein sollte. Er hat die Anhänge mit Bitdefender und VirusTotal überprüft – keine Funde. Dann hat er die Mails als Administrator "einfach released" und sich vorgenommen, dass zu beobachten.
URL in Link als Ursache
Am übernächsten Tag schriebt ihm ein befreundeter Admin, dass die Mails des Blog-Lesers bei ihm blockiert wurde, "weil der Link https://www.purple-tec.at malicious sei". An dieser Stelle hat der Administrator natürlich sofort diese (eigene) Site überprüft. Aber die genannte Seite wird als sauber klassifiziert. Dann hat der Leser einige Tests durchgeführt. Ergebnis: Immer wenn https://www.purple-tec.at im Mail-Body enthalten war, wurde die Mail geblockt, die Seite https://purple-tec.at war jedoch sauber, wie der Leser schreibt. Die beiden URLs zeigen natürlich auf den selben Content, es wurde nur ein www in der URL ergänzt. Das sieht auch Sicht des Lesers nach einem Fehler von Microsoft aus.
Zwei Support-Tickets bei Microsoft
Der Leser hat dann gleich zwei Tickets für dieses Problem eröffnet. Ein Ticket wurde über den Distributor, wo die Lizenzen gekauft wurden, eingereicht. Und ein Ticket wurde über den eigenen Tenant eingereicht.
Anzeige
Lange Rede, kurzer Sinn, meint der Leser: Der Support des Distributors meldet sich, macht eine Fernwartung, ließ sich alles möglich zeigen, kopiert sich diverse IDs und wollte sich "wieder melden". Leider scheint der Distributor durch den Fehler "in den digitalen Orkus" gerauscht zu sein, seitdem herrscht "Schweigen im Walde", keine Rückmeldung, nichts. Vielleicht ist deren Exchange Online auch kaputt gegangen, man rätselt.
Nach mehreren Nachfragen und Eskalation über die Betreuerin des Leser bekommt er die Rückmeldung "Bitte andere IDs schicken, die passen nicht zu dem Tenant, für den ich das Ticket eröffnet habe". Wie schrieb der Leser: "Meine Antwort, dass ich keine Idee habe, was sie von mir wollen und ich bitte einfach nur das false positive repariert haben möchte, blieb bis heute unbeantwortet."
Der Microsoft Support hat mit mit dem Leser mehrmals telefoniert, und Testmails verlangt (die alle wunderbar angekommen sein sollen). Am Ende des Tages kam vom Microsoft Support der Ratschlag, der Leser soll alle seine Email-Empfänger bitten, die oben genannte Domain in ein White-Listing zu stellen. Ist wohl "gelebte Hilflosigkeit" und mir geht "wenn man nicht mehr weiter weiß, gründet einen Arbeitskreis" aus meiner Angestellten-Tätigkeit vor 30 Jahren durch den Kopf.
Fazit des Lesers, wie er mir schrieb: "Ich bin sehr stolz auf mich, die Contenance behalten zu haben und hab ihm [dem Supporter] mitgeteilt, dass das eine nicht gangbare Lösung sei und er doch bitte sich drum kümmern soll, dass diese false postives behoben werden." Dort fällt mir der Spruch aus einer TV-Sendung ein: "Gelesen, gelacht, gelocht und abgeheftet", als es um Beschwerden an Behörden ging. Der Supporter drückt es eleganter aus: "Er wird sich mit Experten beraten und sich wieder melden."
Es wird immer schlimmer
Der Leser schrieb noch: "Natürlich haben wir sofort versucht, bei allen Links das böse www wegzunehmen". Spannende Frage: Hat sich da was gebessert? Leider nein, denn inzwischen nehmen die Phänomene, so der Leser, zu. Die Administratoren sehen auch ankommende Mails, die als malicious eingestuft, in der Quarantäne des Tenants landen. Die Mails sind aber zu 100% nicht schädlich, es handelt sich z.B. um Log-Mails der Fortigate-Firewall. "Davon bekommen wir hunderte, ein paar landen in der Quarantäne. Auch die geänderten AGBs eines Geschäftspartners sind böse und wurden mehrfach weggefressen." merkt der Leser an.
Ohne jedem einzelnen Verdacht nachgegangen zu sein, haben die Leute offenbar auch Zustellprobleme mit Mails ohne Anhang. Verschiedenste Empfänger melden, dass sie keine Nachricht von dem Unternehmen bekommen hätten. Der Leser schrieb: "Selbst wenn wir jetzt sofort offboarden, würde das ja gar nichts ändern. Ich bin mir nicht mal sicher, ob es besser würde, wenn wir unsere Maildomain von der purple-tec.at auf purple-tec.com ändern. So wie im März 2023 dürfte es wohl nicht sein, ich finde online sonst keine Hinweise auf eine globale Störung."
Das ist ein ziemlich krudes Fehlerbild – daher stelle ich es hier im Blog ein. Hat jemand da etwas ähnliches beobachtet oder noch einen Tipp, was der Leser probieren kann?
Problem gelöst?
Der Blog-Leser hat mich im Nachgang nochmals kontaktiert und schrieb zum Status: "ich bedanke mich nochmal für das veröffentlichen meines Problems. Es sind ja sehr viele Kommentare geschrieben worden. Mit Sicherheit kann ich es nicht sagen, aber möglicherweise war ein Hinweis von Sandra nützlich und hat schlussendlich zur Lösung geführt. Diese war eine Eskalation zu einem Produkt-Support, welcher dann 'das Problem gelöst hat'. Wie genau, hat man mir nicht gesagt. Es ist aber auch nach ~2 Wochen noch stabil." Wie besagt ein altes chinesisches Sprichwort "Ente gut, alles gut".
Anzeige
Die Lösung hat 3 Buchstaben:
F A X
sry, ich kann die Verzweifelung des Admins nachvollziehen.
Es ist erstaunlich in welcher Hilflosigkeit MS seine Kunden lässt.
Ja mit zynischen "Tipps" wie, bitten Sie den Empfänger doch ihre Domain zu white listen. offensichtlich verarscht werden soll.(so blöde kann doch niemand sein?) Sorry für die wenig diplomatische Ausdrucksweise, aber mir fehlen die Worte.
Ich erinnere mich, dass Google mal sehr sauer reagierte, wenn eine IP unter 2 Namen erreichbar war(wie mit und ohne www) und denselben Inhalt zeigte.
Aber das ist doch email…und kein Grund, E-Mails zu versenken.
Google hat diese "Strafe" eingeführt, weil sie nicht doppelt/zigfach das Gleiche scannen wollen.
Aber hier scheint es einen "move to" von http://www.purple... auf purple zugeben, also "eigentlich" OK. (hab das nur nicht genau untersucht)
es geht aber auch nicht um Google sondern False positives des eigenen Defenders…
der könnte sich am fehlenden SPF stören.
Die eignen Domain zu checken ist generell eine gute Idee.
Aber kein vernünftiges Log zu erzeugen?
Hallo Paul,
ich bin der betroffene Leser :-) SPF Eintrag habe ich von Anfang an immer gehabt, auf das achte ich sehr. Für detaillierte Logs braucht man eine teurere Lizenz. So bleibt mir nur die Nachrichtenablaufverfolgung und die globale Quarantäne.
Hey Willy,
auch wenn es recht weit von deinem Problem entfernt scheint: Gegen Ende 2023 wurde das Thema SMTP-Smuggeling beim CCC veröffentlicht.
Ich hatte bei einigen meiner Kunden das Problem, das Mails teilweise in der Quarantäne gelandet sind und teilweise abgelehnt wurden, weil in den Signaturen (leider nicht zentral verwaltet) zum Teil unterschiedliche Zeilenumbrüche (\n statt \r\n) verwendet wurden. Zum Teil wurden die Siganturen über Jahre kopiert und von Profil zu Profil mitgeschleppt…
Danke Max, aber das dürfte es in dem Fall nicht sein. Wir haben zentral verwaltete Signaturen und alles Tests mit und ohne Sig haben sich gleich verhalten und lassen sich wirklich die die URL runterbrechen.
Aber auf jeden Fall auch ein arger Case – wegen so einen kleinen Detail, da muss man auch mal drauf kommen …
hi Willy,
have you tried to enable skim/dmarc on the domain?
best
Ehsan
DKIM is enabled, DMARC not yet. Didn't solve the problem …
Wir hatten mit ähnlichen Problemen zu kämpfen solange wir ein Hybrid Szenario mit CMT hatten. Ist das bei dir so? evtl enhanced filtering nicht oder falsch konfiguriert?
Nach wir vor werden bei uns auch harmlose URLs als schadhaft eingestuft. Hier hilft nur aus der Quarantäne freigeben und den Haken setzen, dass ähnliche Mails (zumindest für 30 Tage) nicht als schadhaft eingestuft werden. Auch das "submit to Microsoft for Review" und "initiate Automated investigation" hat schon was gebracht. Phishing Threshold evtl runterschrauben. URLs und Domains auf die Tenant Allow List setzen.
Den Microsoft Support kannst du bei solchen Themen fast immer vergessen, und das obwohl wir E5 und Unified Support (noch) haben…
Danke Marco, ist aber weder bei uns noch bei den von uns verwalteten Tenants der Fall. Alle nur rein Cloud. Und das Filtering ist überall auf Default. Bei Empängern, die wir nicht selbst managen, kann ich es nicht genau sagen und die alle aufzufordern, uns whitezulisten ist nicht nur peinlich sondern auch eigentlich unmöglich bei ~30% Konzernen.
Aber Deine Erfahrung mit dem Support teile ich zu 100%. Ein Skandal.
Das mit dem Whitelisten ist ein zynischer Witz des MS Supports.
Es gibt Firmen, die haben die Wartung ihres Exchanges geoutsourct und zahlen "pro Ticket".
Das whitelisten einer Domain würde ich mit 100 Euro veranschlagen.
Das soll jeder euer Kunden zahlen damit ihr ihm Emails schicken könnt die euer Domain enthalten?
Und bei neue Kunden solltet ihr erstmal anrufen:
"Wir wollen Ihnen ein Angebot schicken, bitte beauftragen Sie ihre IT unsere Domain zu Whitelisten. Faxen Sie uns, wenn Sie das gemacht haben"
Echt, ich weiß nicht wie hohl man als Mitarbeiter von Microsoft sein darf einen solchen Rat zu geben. Die Amerikaner sprechen von IQ wie Schuhgrößen, also maximal 60
Salve!
Jup, hatte ich bei EINEM Kunden und bei meinem EX Online ebenso. (ab 17.05. aber erst)
Dort lag es an der Signatur bzw. e-Mailadresse + website Link.
Dachte erst da bei dem Kunden noch mit http:// verschickt wurde, wars aber nicht.
Website + e-Mail entfernt – keine Probleme.
Seit 21.05. ist das problem aber wie es aussieht behoben
Es ist nur noch eine beschämende Umgebung mit MS geworden die letzten Jahre.
Das war auch unsere ErsteHilfe Maßnahme. Aber in ganz vielen Dokumenten, die wir immer noch mit schicken, ist irgendwo der Link drinnen. Ich überlege schon, eine Content-Disarm Technologie vorzuschalten, die mir den Link in den Dokumenten automatisch umbaut (kann ich mir aber nicht leisten *hihi*).
Genau, jetzt merke ich am eigenen Leib wie existenzgefährdend sowas sein kann, auch in Zeiten, wo ja niemand mehr telefonisch erreichbar ist oder zurück ruft. Mir geht echt der Reis …
hm, für purple-tec.at bekomme ich keinen SPF angezeigt.
das ist m.E. auf jeden Fall unschön (wenn das nicht ein problem hier bei mir ist) und diese Domain auch zum email versandt verwendet wird
dkim ist auch nicht definiert.
Das könnte schon das ein oder andere Problem auch auf der Gegenseite auslösen. Mails an die Telekom zum Beispiel werden ohne SPF und DKIM als Spam markiert
SPF und DKIM passen für mich aber irgendwie nicht zum beschriebenen Fehlerbild, wenn ausgehende Mails in der Quarantäne landen. Klar können auch fehlendes SPF oder DKIM Zustellfehler erzeugen, dann ist es aber doch meist der Server auf der Empfängerseite, welche die Annahme verzögert oder verweigert und so am Ende einen NDR auslöst.
wie gesagt:
Es ist besser selbst seine eigene Domain zu checken.
Denn überall gilt: Je früher ein Fehler gefunden wird, desto billiger ist dessen Reparatur.
Ich würde auch meine Mailout gegen RBL checken.
Natürlich geht das nicht, wenn ich in meinem SPF zig tausende IP freigeschaltet habe, weil ich nicht weiß, welche IP mein Cloud Anbieter zum Versand verwendet…
Ich denke da gerade an einen eMail Provider, der keine E-Mails von Systemen annimmt, dessen Helo-String sich nicht symmetrisch auflösen lässt.
Natürlich blockt man E-Mails aus dieser Quelle,weil man ja ggf. nicht antworten kônnte, weil der Helo (dank cloud) nicht symmetrisch auflösen kann.
Aber hier steht ja, das die eigene Email malicious sei, aber nicht was das Problem sein soll.
Sehr verwirrend ist auch, dass es zunächst notwendig war, das die Domain in einem Anhang erwähnt wurde, und dies inzwischen auch nicht mehr notwendig ist.
Aber wenn man keine Log Files bekommt oder diese teuer kaufen muss, ist eine Fehlersuche frustrierend.
Aber es ist ja Microsoft, die können das…
Wie gesagt:
Dienstanweisung:
"Wenn Sie einem Kunden schreiben und dieser sich nach 24h nicht gemeldet hat, rufen sie ihn an um die Fax Nummer in Erfahrung zu bringen und faxen sie" …
Das ist Email ala Microsoft im Mai 2024…echt jetzt?
purple-tec.at hat sehr wohl einen SPF Record. Ob DKIM da ist, kann man so nicht feststellen. DMARC fehlt jedoch. Das sollte aber nicht verursachen, dass die Email in der eigenen Quarantaine hängen bleibt. Es muss was anderes sein.
Idealerweise bräuchte man genaue Logs und Email Headers. Zudem müsste man wissen, wie die "Outbound Policy Settings" eingestellt sind.
Stimmt, SPF hab ich, DKIM / DMARC bis jetzt nicht, bin gerade am Einrichten (wollt ich eh immer schon mal machen :-))
Detaillierte Logs bekomme ich leider mit meiner Lizenz offenbar nicht, der Header hilft nicht viel weiter. Es werden ja auch Mails blockiert, wo die böse URL in einem der Anhänge enthalten ist.
Und die Policy Settings sind in meinem Tenant allesamt Default, ich hab da noch nie was verändert. Auch bei den Kunden, wo Mails von uns blockiert werden und wir den Tenant verwalten, ist alles Default.
die domain ist triggert safe links
international outlook an MS via report email plugin zusaetzlich manuell im portal admin submission
dann vorher und nachher einen trace bzw in der quarantäne den Header runterladen
all das im ticket und dann level2 an level3 an PG (product team) eskalieren (erfordert fehlgeschlagene admin submission als Voraussetzung)
und immersion schön ALT Tags in den links setzen (gilt seit 30 jahren)
DKIM hilft auch gelegentlich
Danke Jan, ich werde das mal versuchen. Manche der Submissions kommen ohne Resultat zurück "… kann derzeit keine Aussage getroffen werden", vielleicht reicht das ja um den Support zu überzeugen, das Ticket zu eskalieren.
Wenn schon SPf und DKMI nicht definiert sind bezweifle ich dass man keine anderen Konfigurationsfehler gemacht hat.
Nutzerfehler.
hmm okay, SPF hatte ich immer schon, DKIM habe ich nach ein paar Tagen eingerichtet. Welchen Fehler genau habe ich Deiner Meinung nach sonst noch gemacht, so dass https://www.purple-tec.at malicious ist (nur in Emails, der reine URL check gibt ein OK zurück), https://purple-tec.at jedoch nicht, obwohl gleicher Webspace/Content? Bin für jeden sachdienlichen Hinweis dankbar.
Was geht das Microsoft an, wenn eine URL in der Mail vorhanden ist, die womöglich NICHT für Mailverkehr verwendet wird und somit keinen SPF/TXT Record benötigt?!
Selbst wenn diese URL, die in der URL im Mailtext mit angegeben ist, als Spam-Server gilt, hat das auch nicht Microsoft was an zu gehen, da sie für einen anderen Zweck in der Mail, also dem "Brief" enthalten ist!
Diese und jegliche andere Bevormündungen eines Unternehmens, dass selbst nicht seinen Mailverkehr im Griff hat und Pornos versendet, muss man scharf ankreiden!
mein Video "Microsoft versendet Pornos" findet Ihr unter YouTube.
SPF ist hier nicht das Problem. Der wird bei eingebetten URLs nicht abgefragt, sondern deren Reputation auf SURBLs. Ein Klick auf den Hyperlink leitet dann oft weiter auf eine täuschend echtaussehende Phishing Seite.
Ich verwende für meinen OnPrem Exchange einen Smarthost/Firewall, der auch Online SURBLs abfragt, was dann so aussieht:
====================================
SURBL: abfragen von qnhd.info )
SURBL: qnhd.info ist auf multi.surbl.org
Spam: surbl
Was: Vernichte Nachricht
Warum: Erkannt durch SURBL für auf multi.surbl.org
====================================
Die Nachrichten gehen dann ins Nirwana.
Auch ausgehende Mails werden überprüft.
Das ist in den letzten 6 Jahren immer richtig gewesen.
Falls man da falsche Listen abfragt, ist das halt blöd. Speziell für MS, die einen solchen Dienst selbst anbieten sollten, oder einen zuverlässigen nutzen sollten.
Also wenn die Domain nicht zum mailen verwendet werden soll, dann würde ich einen SPF machen, der das allen verbietet, logo.
SPF gibt 66 Address Bereiche frei.
Cloud halt.
wie gesagt:
Es ist besser selbst seine eigene Domain zu checken.
Denn überall gilt: Je früher ein Fehler gefunden wird, desto billiger ist dessen Reparatur.
Ich würde auch meine Mailout gegen RBL checken.
Natürlich geht das nicht, wenn ich in meinem SPF zig tausende IP freigeschaltet habe, weil ich nicht weiß, welche IP mein Cloud Anbieter zum Versand verwendet…
Ich denke da gerade an einen eMail Provider, der keine E-Mails von Systemen annimmt, dessen Helo-String sich nicht symmetrisch auflösen lässt.
Natürlich blockt man E-Mails aus dieser Quelle,weil man ja ggf. nicht antworten kônnte, weil der Helo (dank cloud) nicht symmetrisch auflösen kann.
Aber hier steht ja, das die eigene Email malicious sei, aber nicht was das Problem sein soll.
Sehr verwirrend ist auch, dass es zunächst notwendig war, das die Domain in einem Anhang erwähnt wurde, und dies inzwischen auch nicht mehr notwendig ist.
Aber wenn man keine Log Files bekommt oder diese teuer kaufen muss, ist eine Fehlersuche frustrierend.
Aber es ist ja Microsoft, die können das…
Wie gesagt:
Dienstanweisung:
"Wenn Sie einem Kunden schreiben und dieser sich nach 24h nicht gemeldet hat, rufen sie ihn an um die Fax Nummer in Erfahrung zu bringen und faxen sie" …
Das ist Email ala Microsoft im Mai 2024…echt jetzt?
https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-protection-service-description/exchange-online-protection-feature-details?tabs=Anti-spam-and-anti-malware-protection
Standardmäßig werden auch rausgehende EMails überprüft. Man kann aber die Standardfilter durch eigene ersetzen.
Absolut richtig.
Es ist schon megapeinlich von einem Kunden gefragt zu werden, warum man denn Werbung für Viagra mache…Er hatte sich einen infizierten PC ins Netz geholt der nun lustig seine Kunden zu spamte…
Er könnte die Quelle schnell identifizieren, dank den Logs seiner Firewall. (Er war nicht in der Cloud).
Shit Happens.
Man kann die Filter rules auch durch Mail Flow Rules ersetzen. Ist weit effektiver und dauerhafter als die Filter…
Hatte so ein Problem bei einem Kunden auch. Neuer Tenant und O365 stuft alle ausgehenden Mails als Phishing ein. Trotz SPF/DKIM/DMARC.
Der MS Support hat das gefixt.
Wie?
Es wird Out going nicht mehr geprüft?
Wäre ja schon interessant, wieso die E-Mails so eingestuft worden waren.
Lernen durch Schmerzen.
Ähnlicher Fall bei uns vor 1 Jahr:
Exchange Online Protection blockt ausgehende Emails mit dem Verdict "Malware". Ursache: eine URL unseres Lieferantenportals wird als "malicious" eingestuft. Wir können beim besten Willen keinen Grund für die Einstufung unserer URL finden. Da ja Exchange Online Protection weltweit dieselben Regeln anwendet, werden die von uns ausgehenden Emails bei allen O365-Tenants eingehend natürlich auch mit dem Verdicht "Malware" in die Quarantäne geschickt.
Damit hat MS einen wichtigen Geschäftsprozess unseres nicht allzu kleinen Tenants komplett lahmgelegt.
Lösung: Es gibt definitiv eine Second-/Third/Fourth-(?)Level Product-Group-Instanz von Exchange Online Protection, die solche falsch-positiven Einstufungen aufheben kann. Wir mussten bei unserem MS-Ticket ca. 14 Tage eskalieren, damit final diese URL wieder als "gut" eingestuft wurde.
2 Tipps:
1/ Im Threat-Explorer nachschauen, welcher Grund für die Einstufung für die Quarantäne angegeben wird: Da gibt es so Dinge wie "Advanced filter", "Fingerprint matching", "URL detonation" …
2/ Eine Stufung als Malware oder High confidence phish lässt sich mit KEINER Einstellung im MS Defender for Office übersteuern.
HTH.
Max
interessant und wohl auch hilfreich.
und wenn ihr das alles bei MS in deren Cloud hättet laufen lassen wäre der false Positive gar nicht erst aufgetreten oder innert 14 Stunden behoben worden, nicht 14 Tagen …?
?
cloud rulez
Habe jetzt DKIM aktiviert und nochmal ein Testmail an eine Email-Adresse eines Kunden gesendet. Dort ist eine Weiterleitung wieder zurück in unseren Tenant eingestellt. Wenn ich die kurze URL ohne www verwendet, klappt es. Wenn ich die lange URL verwende, geht das Mail bei mir raus, beim Kunden rein, aber die Weiterleitung wird ausgehend quarantänisiert.
Grund: Schadsoftware
Richtlinientyp: Antischadsoftware-Richtlinie, Name: Default
Ursprüngliche Bedrohungen: Schadsoftware, Spam / Normal
Neueste Bedrohungen: Schadsoftware, Spam / Normal
Erkennungstechnologien: URL-Detonationszuverlässigkeit, Erkennung mittels verschiedener Analysen
Hab auch diese Richtlinie nochmal kontrolliert, da kann man ja eh kaum was einstellen …
manchmal kann es etwas dauern ehe DNS Änderungen bei allen angekommen sind.
DKIM/DMARC zu haben ist schon Mal gut, weil es spammern das fälschen wirklich schwer macht und SPD inzwischen albern geworden ist, wenn da das halbe MSN freigeschaltet ist.
purp… gibt einen 301 moved to http://www.purp.
gut.
aber bei mir nölt das wget, das das Zertifikat Common Name *.ssl-net.net sei, was nicht so Recht zu http://www.purp passt.
auch sei das ein self-signed cert von let's encrypt.
ssl Checker findet aber alles sei OK
seltsam.
irgendwie ein crlf wo nur ein LF sein sollte oder warum spinnt wget (auf Windows)?
früher gab es mal Echo Server für email im Netz.
Der schickte einfach alles was er bekam inkl..aller Header an den Absender zurück.
Sind alle wohl dicht gemacht worden.
Wäre für solche Fälle schon hilfreich…
echo.tu-Berlin.de !!!! ;-)
Das war super, damals ….
Es ist schon seltsam, das das Problem immer nach 14 Tagen verschwindet….
Danke Max, beruhigend, dass ich mit dem Problem nicht ganz alleine bin. Ich nehme an, das war bei einer größeren Firma und/oder mit einem Support Vertrag? Meine Aufforderungen, das Ticket zu eskalieren, werden abgelehnt, weil der Support den Fehler nicht selber reproduzieren kann. Meine Screenshots alleine zählen offenbar nicht. Aber ich werde mal dran bleiben und versuchen, mit Verweis auf diesen Thread den Support zu bewegen, es zu eskalieren.
@Pau1: Du meinst: Wenn wir alles (= unseren Mailverkehr) NICHT in der MS-Cloud betrieben hätten, wäre das Problem nicht aufgetreten.
Klar, das stimmt natürlich: Wer sich mit MS ins Bett legt, muss auch deren Regel akzeptieren.
Solange die Vorteile der MS-Cloud die Nachteile überwiegen, bleiben wir dabei.
Und diese Aussage kommt von einer Firma, die mit Lotus Notes und Sametime einst alles on-premises betrieben hat.
Gruß Max.
ich dachte ihr seit nicht in der Cloud.
Doch wir sind in der Cloud. Der Vorfall spielte sich im Exchange-Online ab, wie ich schon schrieb.
wenn nichts in der Cloud wäre zumindest ein Zugriff auf alle Logos möglich und eine Fehlersuche einfacher, oder?
das ist schon ne geile Idee, den Leuten die eigenen logfiles zu verkaufen. Dreist kann Microsoft gut.
Na ja, Logs hat man schon im Threat-Explorer. Habe gerade mal in die Quarantäne geschaut und dies gefunden:
https:[:]https://15l7hbnz.r.ap-northeast-3.awstrack.me/L0/xxyyzz
MS meint diese URL sei High confidence phish. Die Technik, die das erkennt, ist "URL detonation reputation". Wenn es stimmt, sehr gut. Wenn falsch-positiv, dann leider keine Chance (außer Submission mit zeitlich begrenzter Freischaltung im eigenen Tenant, nicht aber in anderen Tenants).
Ja genau, aber der Threat Explorer ist in meiner Lizenz (Office365 E3 sowie Business Standard) nicht enthalten. Außer Ablaufverfolgung und Quarantäne ist hinter jedem Link nur Werbung für "Defender for Collaboration". Dass es die URL ist, hat mir ein Kollege geschickt, der offenbar eine höhere Lizenz hat. Auch das ist ein Mega-Skandal. "Wir tun was, was Du nicht beeinflussen kannst, Details zeigen wir Dir aber nur, wenn Du mehr Geld zahlst".
manchmal kann es etwas dauern ehe DNS Änderungen bei allen angekommen sind.
DKIM/DMARC zu haben ist schon Mal gut, weil es spammern das fälschen wirklich schwer macht und SPD inzwischen albern geworden ist, wenn da das halbe MSN freigeschaltet ist.
purp… gibt einen 301 moved to http://www.purp.
gut.
aber bei mir nölt das wget, das das Zertifikat Common Name *.ssl-net.net sei, was nicht so Recht zu http://www.purp passt.
auch sei das ein self-signed cert von let's encrypt.
ssl Checker findet aber alles sei OK
seltsam.
irgendwie ein crlf wo nur ein LF sein sollte oder warum spinnt wget (auf Windows)?
Hallo Zusammen,
DKIM ist ein sehr gutes Stichwort. Irgendwo steht, dass dort nichts eingestellt wurde.
Ich habe zufällig bei einem meiner Kundenworkshops erfahren, dass Microsoft die Sicherheitsstandards erhöht.
In diesem Fall ging es konkret darum, seine eigene Domain durch zwei CNAME Einträge beim Provider nochmals im Exchange Online zu bestätigen, um damit dann DKIM Keys zu nutzen, die einfach nochmal bestätigen, dass es keine Fakedomain ist.
Dazu muss man folgendermaßen vorgehen:
Beim Provider zwei CNAME Einträge anlegen (oder anlegen lassen):
1. Eintrag:
Hostname: selector1._domainkey.EIGENEDOMAIN
Ziel: selector1-DOMAIN-de0i._domainkey.DOMAIN.onmicrosoft.com
2. Eintrag:
Hostname: selector2._domainkey.EIGENEDOMAIN
Ziel: selector1-DOMAIN-de0i._domainkey.DOMAIN.onmicrosoft.com
EIGENEDOMAIN ist eure öffentliche Domain: purple-tec.at
DOMAIN ist eure eigene onmicrosoft.com Domain (nur der Kundenname, ohne onmicrosoft.com) also z.B. KUNDE .onmicrosoft.com.
WICHTIG: Kopiert euch diese Einträge sauber, sonst gibt´s Probleme die im DKIM anzulegen.
Danach geht ihr ins Microsoft Admin Center, Security zu DKIM (https://security.microsoft.com/dkimv2).
Dort sind eure genutzten Domänen aufgelistet, inklusive der onmicrosoft.com Domäne. Bei der muss übrigens maximal der DKIM Key aktiviert werden, CNAME Einträge sind dort standardmäßig gesetzt.
Für eure eigenen Domänen müsst ihr jetzt jeweils die erstellten CNAME Einträge hinterlegen und den DKIM Key aktivieren. Leider kann ich nicht beschreiben, wie es exakt funktioniert, da ich es nur einmal für unsere Domänen gemacht hatte und ich jetzt lediglich den DKIM Key aktualisieren, aber nichts mehr einstellen kann.
Ich hoffe das hilft weiter.
Grüße Benny
danke für den Hinweis
Derzeit braucht man bei keinem großen Provider DKIM für die Zustellung, sofern SPF korrekt hinterlegt ist.
Besser ist das aber für die Zukunft, wenn wieder an den Schrauben gedreht wird.
Und natürlich bei kleinen Providern, die ihr eigenes AntiSpam-Süppchen kochen.
bei http://: kommt vom Server ein 301 auf https:// www
Bei http://www. kommt ein 301 auf https://www.
warum ist der mit www OK?
weil ohne der 301 protocol und Hostname ändert?
was läuft da als web Server?
welcher csp distri macht denn fernwartung mit screensharing, bzw welcher distri hat eine hotline? also/adn beide nur schriftlich
Wir sind bei Arrow. Man kann das Ticket nur im Portal "ArrowSphere" öffnen, wurde aber dann recht bald um einen Termin gefragt. Inzwischen wurde dieses Ticket jedoch "wegen fehlender Rückmeldung" geschlossen, obwohl der Status "Arrow pending" war. Trotz intervention keine Rückmeldung mehr. Ich denke, diesen Pfad gebe ich auf.
Wir kennen das Problem mit ausgehenden Mails auch, wenn ein QR Code enthalten ist, der die URL qr.de enthält. Mails gehen alle in die Quarantäne
Wenn ich qr.de mit wget aufrufe kommt
Connecting to qr.de|188.40.28.36|:443… connected.
OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Unable to establish SSL connection.
em.. mein windows 10 oder das wget 1.11.4 kaputt?
Also
http://www.ssllabs.com/ssltest/index.html
This server supports TLS 1.0 and TLS 1.1.
This site works only in browsers with SNI support.
Das ist beides nicht schön.
Sollte TLS 1.0 nicht aktiviert werden?
Alsoprobieren wir mal
purple-tec
SS Labs – Not Available
Emm. der Server http://www.ssllabs.com stírbt , ist nicht mehr reichbar für mich
Wohl zufall
Schlaue Menschen blocken Exchange…
das ist jetzt in der Formulierung weniger hilfreich, imho
Scriptkiddie ohne Geschäftskontakte???
Schlau und intelligent sind unterschiedliche Eigenschaften.
Ich habe noch ein Bisschen gesucht, und hier einen interessanten Thread über dieses Problem mit False Positive URLs gefunden:
https://techcommunity.microsoft.com/t5/exchange/url-detonation-reputation-how-do-you-like-it/td-p/3944541
Sandra, 1000 Dank – das ist exakt mein Problem und bestätigt meinen Verdacht, dass das Problem wesentlich größer und global ist. Der letzte Beitrag enthält Ticket#, mit denen das Problem nach 6,5 Monaten (!) offenbar nachhaltig gelöst war. Ich hab das mal meinen Supporter geschrieben und ein ganz kleines bisschen Hoffnung geschöpft. Vielen herzlichen Danke an Dich und natürlich auch an alle anderen, die sich hier Zeit genommen haben :-) !!
Lese ich da richtig?
Microsoft in seinem Größenwahn/Verzweifelung und höchstem Grad an Inkompetenz und Kontrollverlust, nutzt UCEPROTECTL3?
Eine sehr umstrittene Realtime Blacklist für eMail(!) server um die Reputation von Webservern zu prüfen? Hallo?
Das kann doch nicht sein, das jemand das so falsch verstanden hat?
Microsoft scannt den Text allen eMails und prüft jede URL den gegen UCEPROTECTL3?
UCEPROTECTL3 ist für besonders renitente Provider und blockt u.U. ganze ASN, so das auch völlig unschuldige geblockt werden.
Microsoft in seiner Aroganz und Profitgier erzählt seinen Kunden, auch auf Nachfrage, nichts davon?
Sag das ich das falsch verstanden habe?
Sag das das nur ein Altptraum ist.
(Ich stelle mir gerade einen LKA Beamten vor, der per Exchange einem Kollegen eine Liste mit zu überwachenden Domains verschickn möchte(egal ob das das ne schlaue Idee ist). Und der Exchange server pullt all die Domians vom DNS des Kriminellen um die IP für eine UCEPROTECTL3 Abfrage zu bekommen?
Nein, das habe ich falsch verstanden.
Das kann nicht sein.
Wenn doch, sollten wir uns wirklich Sorgen machen, was für Idioten bei Microsoft Entcheidungen fällen dürfen.
Boa.
Ich stelle vermutlich das Thema morgen im englischen Blog mit Verweis auf den von Sandra ausgegrabenen Thread ein. Ggf gibt deinem Supporter dann den Link an die Hand.
Wie viel Prozent des Traffic geht denn eigentlich auf den EN im Vergleich zum DE Blog?
Ich lese bei den EN Artikeln meist nur Kommentare, wenn ich ein spezifisches Problem habe und eine Lösung suche, gefühlt ist dort aber weniger los als bei den DE Artikeln.
Whoow, der Link beschreibt umfassend und technisch fundiert, in welche Probleme man läuft, wenn Exchange-Online-Protection "Amok läuft":
"For a week now, all email communication to and from our organization, containing any notion of our own domain name has been directed to the quarantine based on the URL detonation reputation because our domain is marked to allegedly contain malware. We have had the servers scanned through and throughout and the website is clean and Microsoft has confirmed to us that it's an issue on their part. The consequences for our business are catastrophic. Even if I release every single message sent from the organization, there is not quarantee that the recieving organization will not quarantine it either on the way in or once it's responded to. A ticket with Microsoft has not helped solve the issue by now. This is like a Denial of Service attack on our company from the side of Microsoft.."
Das deckt sich exakt mit den Erfahrungen bei unserem Vorfall.
Und nochmals: Das Schlimme daran ist, dass man beim Verdict "Malware" oder "High confidence phish" KEINERLEI Einflussmöglichkeiten hat.
Achso, die Anwesenheitzeit auf der uceprotectlvl3 beträgt 7 Tage.
Danach wird man gelöscht falls keine neuen Vorfälle gab.
Man kann diese Sippenhaft vermeiden in dem man sich bei uceprotect auf eine White list setzen lässt.
Ist natürlich nicht kostenlos.
Ja genau. Ich werde nächste Woche mal testhalber unsere ausgehende Domain auf die purple-tec.com schwenken. Wenn damit das Phänomen dann verschwunden ist, bestätigt das die Analysen.
Wir haben jetzt bezifferbaren Schaden von 53 Stunden für Fehlersuche und Workarounds und nicht bezifferbaren Schaden für verzögerte Mails, geplatzte Termine, Stress und Ärger und unglaublich große Wut auf Microsoft.
irgendwo in den Weiten des Netzes las ich:
ein Web Server soll auf Anfrage alle seine ssl Zertifikate übertragen, außer dem root.
Es gibt Webserver die machen das einfach nicht.
Browser stört das nicht, die benutzen "AIA".
Nun meckert ja eher über das certificate,das das nicht zum Hostnamen passt.
Ich kann mir gut vorstellen das Microsoft das auch feststellt und die URL als kaputt deklariert.
Kann das wer nachvollziehen oder begründen?
Ich habe einfach "wget purple…at" auf der Commando Zeile aufgerufen.
ich sehe den 301 moved to und dann bei http://www.purple... dass das Cert nicht zur Domain passt.
Bug in wget der nur bei dem Server auftritt?
Danke für die Hinweise, Pau1, ich muss mir das noch genauer anschauen. Das ist einfach ein Webspace beim Provider Domaintechnik, wie genau der redirect von https://www.pur… auf https://pur… stattfindet, weiß ich gar nicht mehr. Möglicherweise ist das, was Du gesehen hast, ein Zwischenschritt, wenn Du . aufrufst, dass zuerst in https://www.pur… umgeleitet und dann weiter auf https://pur…
Ich bin nicht so der Experte mit Webserver, mehr so der Infrastruktur und Security-Dude.
wget -v –debug
zeigt die Zwischenschritte, also das die HTTP URL ohne www per 301 moved permanently auf HTTPS und mit www umgelenkt wird.
die IP löst rückwärts auf .ssl-net.net auf, was auch korrekt ist.
das ist halt der Hostname eures providers, einen Konkurrenten von Microsoft. Auf der IP werden hunderte andere Server laufen und in dessen Netz zig "böse" Rechner, die in RBLs stehen können wie uceprotect. Da kann weder ucrprotect, noch Du noch Dein Webprovider etwas für. Nur derjenige, der eine Liste wie uceprotect falsch anwendet Schäden bei seinen Kunden billigend inkauf nimmt. Natürlich wird es nie das Problem geben, das ein via Microsoft gehosteter Server als böse deklariert wird, oder hatten wir das neulich nicht?
Warum das wget da streikt weiß ich z.Zt. nicht.
Aber falls die Info richtig ist, das Microsoft völlig hirntot uceprotectlv3 benutzt um irgendwelche Websites in der Bonität abzustrafen, ist der Email Verkehr aller gefährdet, deren Webserver bei einem Massenholster liegen, ist das eine gute Erklärung für den Effekt.
das uceprotectlvl3 ist nicht für das gedacht für das MS es verwendet. Es erinnert mich an einen sehr jungen Admin, der mit Stolz mitteilte, er habe nun die ultimative Spam Regel gefunden!
99% des Spams würde damit geblovkt, und mit die Auswertung zeigte.
Was war seine tolle Regel?
Er hatte *.org *.com geblockt, weil er erkannt hatte, das der meiste Spam .org und .com hat…kein Scherz, war aber nicht so tragisch, da nur wenige Stunden aktiv.
ich vermute das Günter vielleicht einen Artikel dazu bauen wird?
qr.de steht tatsachlich über sein AS in der uce lvl3, wenn auch nur als Vor-Warnung.
http:#www.uceprotect.net/en/rblcheck.php?ipr=188.40.28.36
Aber es geht bei uce um emails.
Wer das zum Bewerten der Reputation von webservern nimmt hat nicht alle Tassen im Schrank.
mir graust es gerade:
konnte es sein, das MS eine KI benutzt um solche Entscheidunen zu fällen?
uce ist ja email und der defender findet die ip ja in emails.
für eine LLM würde das passen.
Ich glaub gar nicht, dass das das Problem ist. Vor allem, weil ich auch immer den Link mit https:// angebe, es also nie dazu kommt, dass das falsche Zertifikat präsentiert wird.
Ich dem von Sandra vorher verlinkten Posting schreiben die Kommentatoren, dass es immer dann auftritt, wenn die URL mit der Domain eines der Empfänger überein stimmt. Ich bin mir gerade nicht sicher, ob das bei mir auch immer so ist, auf jeden Fall bei dem am Meisten durchgeführten Test passt es.
BTW:
Es sei daran erinnert, dass man TLS1.0 und SSL3.0 unbedingt deaktivieren muss.
Beide Protokolle sind nicht sicher. (Poodle).
TLS 1.1 und 1.2 sind OK.
Man kann das auf der Webseite von ssllabs prüfen lassen und sollte erst bei einem "A+" Feierabend machen.
Es ist möglich, das MS in seiner völligen Hilflosigkeit auch Server mit veralteten Protokollen sperrt.
Ich habe nun mal von unserem MS Tenant eine Mail mit dem Inhalt
https://www(.)purple-tec(.)at (natürlich ohne die Klammern) im Body rausgeschickt.
Und tatsächlich bleibt sie in der ausgehenden Quarantäne hängen.
Unter Security > Explorer sehe ich dann folgende Details:
Threat: Malware, Spam / Normal
Detection Technologies: URL Detonation Reputation / Mixed Analysis Detection
Ich habe nun die URL an Microsoft zur Analyse geschickt ("Report Clean"):
"Thank you for your submission. We'll get back to you as soon as your submission has been analyzed. Any updates will be shown on the Submissions page."
Sobald ich eine Analyse habe, werde ich es hier schreiben.
Danke Sandra. War in Deinem Testmail eine Empfängeradresse @purple-tec.at drinnen? Laut dem Link von Dir dürfte das der Trigger sein. Wenn nicht, geht das Problem wohl sogar noch tiefer. Danke auch für das Reporten, vielleicht hilft es, wenn es von mehreren Tenants aus kommt.
@Willy K.: In meinem Test, in dem die Emails in der Quarantäne hängen blieben, habe ich wie folgt adressiert:
Outbound: Von: Adresse aus dem Tenant | An: Adresse bei t-online.de
Inbound: Von: Adresse von t-online.de | An: Adresse im Tenant.
Weder im To/CC oder BCC war eine @purple-tec.at-Adresse drin.
Vielen Dank Max, das ist spannend. Damit unterscheidet sich das Phänomen doch etwas von den in dem Microsoft-Artikel beschriebenen. Mal schauen, was der MS-Support zu den Referenzen sagt …
u.U. warnt auch edge vor eurer Website.
Aber wie gesagt:
Es ist schwer nachzuvollziehen denn nach 7 Tagen ist der Spuk vorbei und euere IP wieder von der Liste…
Du hast irgendwas gemacht (Dkim) und glaubst natürlich, dass das die Ursache für das Problem war.
Es müssten alle Webserver auf dieser IP betroffen sein.
Auch das nennen vom host34.ssl-net.net könnte zur Quarantäne der Email führen.
Den Edge hab ich am ersten Tag deinstalliert, als es technisch möglich war. Glaube aber nicht, dass der das blockieren würde. Ich bin mir gar nicht sicher, dass es wirklich mit dem Webserver zu tun hat. Die Überprüfungen der URL bzw. blockierter Mails hat als Ergebnis "keine Schadsoftware gefunden", wird aber trotzdem blockiert. Ich glaub, es liegt einfach nur an einem kranken Konzept, wie Microsoft verzweifelt versucht, "irgendwas" mit Security zu machen.
Ich habe sowohl den Link als auch ein blockiertes Mail zur Analyse eingeschickt, sowohl von meinem als auch von einem Kunden-Tenant. Die Analyse der URLs ergab jedes mal "keine Bedrohung gefunden", die Mails enden mit der selben "Malicious" Meldung wie in der Quarantäne. Ich fürchte, das bringt nix.
Ich habe ein ähnliches Verhalten Mails beobachtet welche einen Link auf eine URL mit selbstsigniertem Zertifikat (ein VPN Dienst) bei beinhaltet.
Fall 1: Ich habe die Mail mit der URL an den Internen Administrator des Kunden gesendet damit er den VPN Client auf Endgeräten einrichten kann die Mail kam zwar an (vermutlich da die Mail über ein Connector per Hornetsecurity empfangen wurde) aber der Administrator des Tenant (zufällig in dem Fall auch der Empfänger der Mail) bekam eine Warnung vom Microsoft Defender dass eine Bedrohung erkannt wurde).
Fall 2: Ich habe eine Mail mit dem Link an einen Mitarbeiter einer anderen Firma geschrieben da sich der Port des VPN Zugriffs geändert hatte und die Nutzer diesen im Client anpassen mussten. Die Mail kam beim Empfänger an, auch hier ist ein externer Spam-Filter von Hornetsecurity vorgeschalteten. Als er diese Mail aber intern an andere VPN Nutzer weiterleiten wollte kamen diese einfach nicht an. Als ich dann als Admin nachgesehen habe waren auch hier Logs des Defender vorhanden aus denen ersichtlich war das die Mails als "Phishing Mails" Blockiert wurden.
Nächster Fall:
Ich will einem Kunden der eine IP Adresse & darauf verweisende Domain und zwei Ports senden die er ausgehend in seiner Firewall freigeben sollte um einen Service bei uns zu erreichen.
Unter der Domain ist kein Webserver erreichbar aber unter der selben IP ist ein Reverse Proxy für andere Anwendungen erreichbar der einen SSL ERROR ausspuckt wenn man über die in der Mail genannten Domain darauf zugreift.
Ich habe auf dem Reverse Proxy jetzt mal einen VHost eingetragen der unter der Domain eine 404 Error Page ausspuckt aber mit einem Lets-Encrypt Zertifikat versehen ist eventuell kommen die Mails ja jetzt an.
Tatsächlich: Auch in unserem Produktiv- und Test-Tenant getestet. Outbound, aber auch Inbound (z.B. von t-online.de) genügt es, die URL in den Body aufzunehmen, so dass die Emails in der Quarantäne landen. Exakt dieselbe Analyse wie bei Sandra.
Was ist das für ein kaputtes System, das millionenfach verwendet wird. Weil auf einer der 2,6Mio IPadressen meines Weinproviders ein Spammer oder Port Scanner sitzt darf ich keine E-Mails mehr verschicken und meine Emails landen bei meinen Kunden in Quarantäne…
Wie viel Schmerzen sind denn noch nötig bis auch dem Letzten klar wird, das MS die Übersicht verloren hat, keine kompetenten Leute mehr dort arbeiten mögen?
Der Schritt ganz auf MS zu verzichten wäre logisch, oder wer braucht keine zuverlässige E-Mails und keine vollständigen Log Files?
Wie viel Schmerzen braucht es noch?
Es hilft ja auch nichts, wenn ich mit meiner Domain zu Microsoft ziehe. Meine Kunden werden ihre Domain weiter bei Hetzner&co hosten, und damit mit ihren Emails in dervQuarantäne meines Exchange landen.
Ich habe doch besseres zu tun als Kundenanfragen da raus zuholen und White zu listen. Mal vom Neukunden ganz zu schweigen, der denken wird, was denn das für ein arroganter Laden ist, der eine Anfrage, die er erhalten hat(kein NDR) nicht einmal beantwortet…
Aber ich glaube es ist zu spät.
Achso, die Anwesenheitzeit auf der uceprotectlvl3 beträgt 7 Tage.
Danach wird man gelöscht falls keine neuen Vorfälle gab.
Man kann diese Sippenhaft vermeiden in dem man sich bei uceprotect auf eine White list setzen lässt.
Ist natürlich nicht kostenlos.
noch sind es nur Host Namen/URLs auf die MS den Mail-Inhalt filtert…
und jeder Host Name wird nach Hause geschickt zum Checken.
Auf was filtert MS morgen?
Ich habe es so verstanden:
Microsoft scannt jeden Email Inhalt und Anhang. Auch Bilder wie QR-Codes werden analysiert (mag wer mal einen screen dump testmailen in dem die URL steht? Vermutlich setzt MS auch OCR ein).
Diese URL wird von der Mail Security an einen Server bei Microsoft gesendet (eher unwahrscheinlich das MS nur einen Hashwert nimmt, aber der NSA egal).
Dieser Server prüft die "Reputation" anhand von RBLs, und SSL Konfigurationen und gibt ein OK zurück.
Somit kann ein Betroffener sich nur helfen, in dem er seinen Webserver zu Microsoft umzieht oder sich einen eigenen Webserver auf einer eigenen IP bei einem winzigen Provider besorgt,so dass er sicher sein kann, das keine anderen Server in seinem Netzbereich von Spammern und Portscannern missbraucht wird und der Provider Spammer schnell wieder kickt.
Irgendwie ist da irgendwas ganz schön kaputt.
Das Problem mit http://www.purple ist das der hosting Provider böse Server in dessen Netz nicht schnell genug abschaltet.
Was ich nicht erklären kann ist, warum nur http://www.purpl geblockt wird, ohne www. aber nicht, obwohl beide auf die gleiche Adresse zeigen. kann es sein, dass noch nicht einmal http im Text stehen muss sondern "www." ausreicht, damit der Defender anspringt?
Also:
Im fliestext ohne httpx: und dann einmal purple und einmal http://www.purple
Dann mit ganzen URL http: oder https: davor.
ich vermute, das ein www davor ausreichend ist, die URL zu checken.
http://www.purple-tec.at im Fließtext reicht aus, damit der Outlook-Client
a) Win32 oder
b) OWA
daraus einen Hyperlink mit http:// macht.
Im Threat-Explorer wird der Link als Malware eingestuft. Bei
a) als https:// (obwohl so gar nicht in der Mail vorkommend),
bei b) als http://
Gemeint war (ohne http: oder https):
www. purple-tec. at
Der Editor scheint hier auch automatisch einen Link zu setzen (wie Outlook auch).
man könnte auch mal "plain ASCII" als Mail Format nutzen.
oder ein .txt aus Notepad anhängen.
Manche Systeme wickeln jede URL in der E-Mail in den Aufruf eines externen Servers ein, der dann, wenn man wirklich drauf klickt, den URL in Echtzeit prüft. Auch nicht schön, aber…
So will man das ja eher haben. Aber so bekommt NSA nicht mit, welche URL interessant sein könnten und man hat natürlich weit weniger Traffic und die Prüfung erfolgt zeitnah.
(Was nützt eine Prüfung wenn der Server erst in einer Stunde böse geschaltet wird?)
Das unschöne daran ist, das es gerne bei modernen Tld nicht so Recht funktioniert, wie bei .company oder
box weil das ja auch so im Text stehen könnte ohne eine Domain darzustellen.
möglicherweise hilft, die URL base64 zu codieren?
Aber wenn MS auch QR Codes auswertet..
da ist es wohl das Beste man hört auch seine Webserver bei MS.
Man braucht ja zuverlässige Mail, und die gibt's wenn alle bei MS sind.
Wie befürchtet brachte die Analyse der URL nicht viel: Microsoft hat die Analyse der URL abgeschlossen und schreibt:
No threats found. This item has been identified as clean. It might have blocked for a variety of reasons (for example, sender reputation). To prevent similar items from being blocked in the future, you can create allow entries (domain or address, URL, File) in the Tenant Allow/Block List. After a period of evaluation, the filters might be updated using the information from the submission.
Vermutlich ist www(.)purple-tec(.)at auf einer internen Blacklist von Microsoft. Diese kriegt man wohl nur weg, wenn man da einen Incident eröffnet. Ich habe die Domain und auch die IP getestet und die ist überall Clean (auch auf UCEProtect L1, L2 und L3).
@Sandra: Du hast die URL submitted, richtig? Dann scheint mir die Erklärung von MS generisch zu sein, weil sie gar nicht zu einer URL passt:
– eine URL hat keine "SENDER" reputation
– als allow entry in der TABL macht nur die URL Sinn (keine Email-Domain, address oder gar ein file)
Und leider wieder die unscharfe Aussage "might", was zu übersetzen wäre "wird vielleicht/eventuell geupdatet" oder auch nicht :-(
@mmusterm Ja, ich habe die URL submitted. Leider kommt nach einem halben Tag dann diese Standard Antwort, die ich wie folgt interpretiere:
Bei der Analyse in der Sandbox wurden keine Probleme mit der Domain gefunden
Die Domain ist auf einer Black List von Microsoft
Man kann die Domain via Tenant Allow Listing durchlassen (was aber nichts bringt, da ja alle anderen Tenants sie trotzdem noch blocken)
@Sandra: 100% d'accord.
@Sandra: Ich habe jetzt auch mal die URL submitted. Exakt dasselbe Ergebnis wie bei Dir: "no threats found".
Im Umkehrschluss heißt das aber, dass die Submission und der Quarantäne-Prozess auf zwei unterschiedlichen Datenbasen laufen:
Der Submission-Prozess sagt "ungefährlich", der URL detonation reputation sagt "Malware".
Für mich zeigt das, dass der Submission-Prozess sinnlos ist, wenn er nicht zum gleichen Ergebnis wie der MS Defender for Office-Prozess kommt.
Bei mir ist es jetzt auch so. Die URL Submission kommt mit einem OK zurück, eine Mail mit URL wird blockiert und wenn man diese Mail dann submitted, wird das Ergebnis "malicious" bestätigt. Support hat sich zum Quadrillionsten mal das Mail und die Ablaufverfolgung schicken lassen und hat es angeblich eskaliert. Heute kam ein "wir arbeiten noch dran" Mail.
Du hattest ja dem Thread gefunden in dem Stand, das Microsoft Detonation sich der blacklist uceprotect level 3 bediene.
In der Liste sind ganze Subnetze, Autonome Systeme,AS eingetragen, wenn es aus diesen immer wieder Spam oder Port-Scans gibt und der Eigentümer des AS nicht aktiv wird resp. zahlt um auf die Whitelist zukommen. Es ist quasi Sippenhsft.
Wenn der Nachbar ein Spammer ist, und der Provider ihn stammenwerden alle IP Addressen gelistet.
Man müsste Mal einen DNS Zonetransfer machen und gucken welche Domains noch auf dieser IP von ssl-net.net liegen und mit diesen dann emals schreiben um zu gucken welche geblockt werden.
Leider ist das das ein bewegliches Ziel.
Man kommt rel. schwer auf diese RBL geht aber meist nach 7 Tagen wieder runter.
Als Kunde kann man nichts machen. Uceprotec gibt's seit mindestens gefühlt 20 Jahren.
Es arbeitet so vor sich hin. Man sollte es aber niemals zum Blocken nutzen, weil viel zu scharf. Microsoft scheint das nicht begriffen zu haben, wie Uceprotect funktioniert und missbraucht es.
Es scheint nötig zu sein, zu beweisen, das MS uceprotrct in unqualifizierter Weise benutzt, um da eine Änderung zu bewirken.
Da Exchange die Email ohne NDR odercRekekt annimmt, und die Sperre nur 7 Tage erfolgt, fällt das evtl. gar nicht auf. Die Email ist halt verloren gegangen…
Der sinnvollere Weg ist natürlich sich von so so einem Produkt und Hersteller zu trennen.
Aber das ist verdammt schwer, weil MS einem verdammt bequem macht. Und: Was so man statt dessen nehmen?
lotus notes?
was soll das mit "Sender Reputation"?
Die URL steht einfach so im Text.
Niemand darf mir untersagen, diese URL in meinem Text zu nennen.
Ticken die bei noch richtig?
Warum leidet meine Reputation, wenn ich in meiner E-Mail eine URL mit geringer Reputation nenne?
Da hat einer irgendwie etwas ganz furchtbar nicht-verstanden. Ja, natürlich erwähnen Spammer böse URLs in der email. Aber das kann man nicht umdrehen und wäre genauso schlau, wie der Jung-Postmaster, der einfach alles mit .com gesperrt hatte, weil Absender vom Spam meist .com hatten.
Ich weiß aber auch nur noch eine Lösung:
Einen 2. Provider suchen und die Webseite per VPN/reverse Proxy dorthin virtualisierten.
M.E. wird das Problem an der IP festgemacht, die dann ja eine andere ist.
Oder man setzt einen redirektor auf, den man schnell auf eine andere IP umsetzen kann.
Selbst wenn ich diesen MS Schrott ersetze:
Nichts hindert MS daran meine Domain bei meinen Kunden zu blockieren, wenn die weiterhin MS-Schrott verwenden. Warum sollten sie das ändern. Für sie funktioniert das doch. Das ich pleite heh interessiert doch noch nicht.
Nichts, nicht Mal ein Gesetz schützt vor diesem Missbrauch.
Moin,
da die Diskussion scheinbar immernoch heiß ist habe ich mal einen Blick auf das Zertifikat geworfen. Was auffällt ist das sowohl purple-tec.at sowohl mit und ohne www eingetragen ist. In der Liste der alternativen Inhaltsanbieter steht www auf Platz 2. Da wir hier über MS reden mit denen jeder schon Dinge erlebt hat die eigentlich nicht möglich sein dürften will ich mal nicht ausschließen das MS nur den ersten Eintrag ohne www einliest und somit auf illegales Zertifikat entscheidet. Dazu zwei Ideen:
1. Den Eintrag ohne www aus dem Zertifikat werfen und für den Eintrag ohne www ein eigenes Zertifikat generieren, heise z.B. scheint das so zu machen
2. Ein Domain-weites Zertifikat besorgen. Ist zwar nicht wirklich schön und teuer aber wenn´s hilft immernoch billiger als weiter Zeit, Geld und Nerven zu investieren.
Also wenn ich mich recht entsinne, kommen E-Mails die purple-tec ohne www im Inhalt haben durch.
Nur die mit www werden gesperrt.
Es wird sauber per moved-permantly
alles auf http://www.pure-tec.at umgeleitet.
Das Zertifikat unterstützt wenn ich mich nicht täusche unschöner weise tls1.0 und 1.1 nebst ssl3.0.
das ist ein sichheits Risiko.
Es ist großer Mist, das wohl nicht einmal MS weiß was da läuft und das Problem nicht versteht. Es nützt dich nichts, wenn ich die Domain frei schalte. Der nächste Kunde hat es nicht freigeschaltet.
Genauso isses. Die Verzweiflung steigt exponentiell mit fortschreitendem Datum …
Bald sind die 14 Tage um und das Timeout schaltet die Domain wieder frei..
Das Zertifikat bekommt von Ssllabs das rating "A".
Das A+ wird durch Kleinigkriten verhindert:
keine Chrome 49 Support und 6 Unsichere cipher Verfahren.
Aber das soll der Reputation schaden?
vielleicht benutz MS KI.
Da ist ein Grenzwert von 5,0 gesetzt, und aus anderen, geheimen Gründen liegt der Score schon bei 4,95. Und nun das Cert, das kein A+ hat.
Es ist so vollständig grotesk .
Sogar das hab ich behoben. Ist zwar immer noch kein A+, aber die unsicheren Ciphers sind abgedreht.
Danke, Admin_mit_viel_Erfahrung (nix "alt" :-)), hab gerade mit dem Hoster Domaintechnik telefoniert, weil ich bei dem Thema Webserver/Zertifikate eher der Einäugige bin. Er meinte, dass man das nicht umdrehen kann und egal, für welche der beiden URLs man fragt, immer dieses Cert präsentiert bekommt. Auch das Splitten des Zertifikats ist in der aktuellen Config nicht möglich, weil (hoffe, ich gebs richtig wieder): Der content nur 1x da ist und WordPress die Unterscheidung von www. und nicht www. selber regelt, auch um duplicate Content zu vermeiden. Also isso wie's sein sollte.
Er hat auch gegen alle möglichen Blacklists gecheckt: keine Funde. Unser WordPress samt Plugins wird gepflegt und ist aktuell, Virustotal & Co finden keine Malware. Und es hat ja auch kein anderer Mailempfänger Probleme, nur Microsoft.
*seufz*
Kannst Du deinen Hoster bitten, dir eine Liste alle Domains schicken, die mit auf Deiner IP hocken, außer Deiner Domain?
Als Klartext.
Landet diese Email bei Dir in Quarantäne, dann ist die Sache klar.
Evtl. nochmals von Dir irgendwo hin schicken.
Wenn das nicht geht, dann ist da noch eine Domain bei MS gelistet.
Reverse engineering von Blacklists…
Das was das das WordPress erzeugt gefällt dem Validator aber nicht, er meldet ein paar Fehler in css
Aber was geht es MS an?
Ich glaube nicht, dass es am Zertifikat liegt. Letsencrypt macht das bei meinem Web Server auch so (und meine Domain wird nicht geblockt), dass er beide SANs (domain.com und http://www.domain.com) in dieser Reihenfolge hinterlegt. Dies ist völlig normal und bei sehr vielen Seiten so.
Ich sehe es eher so, dass die Domain auf einer internen Black List ist und der Support könnte es lösen, wie bei diesem Fall:
MS Support schreibt:
My Support team confirmed that they have taken our website off the block list and have done what is needed to make sure that the problem is fully fixed. Please verify the behavior and continue to monitor it until Monday to make sure that it is completely resolved.
wie in der schon mal verlinkten Diskussion beschrieben
https://techcommunity.microsoft.com/t5/exchange/url-detonation-reputation-how-do-you-like-it/m-p/3944541/page/2
https://techcommunity.microsoft.com/t5/exchange/url-detonation-reputation-how-do-you-like-it/m-p/3944541/page/2
Das Problem hatten wir bei einem Kunden auch. Hat auch ca. 2 Wochen gedauert bis Microsoft die Domäne wieder freigegeben hat. Microsoft Support hat ständig gebeten die E-Mails als False-Positives zu melden und die ID der Meldung und die Message-ID an Support zu schicken, damit die das intern weiterleiten können.
Kundenbeschäftigung…
nur ein Sau Drecksladen macht so etwas.
(wie gesagt: man ist nur 7 Tage auf der Blacklist…h.h. MS muss den Kunden nur lange genug hinhalten bis das Problem von selbst verschwunden ist.
@Pau1:
Ich bin mir nicht sicher, ob nur die externe(n) Blacklist(en) herangezogen werden oder ob nicht noch eine MS-eigene (nicht einsehbare) Blacklist hinter dem Blocken der URL steckt. Ich tendiere auf Grund meiner Erfahrungen mit dem Support zu letzterem.
Ja, da stimme ich Dir zu.
wahrscheinlich hat MS da noch ganz tolle eigenen Algorithmen.
Z.B. gibt es einen dicken Malus wenn die IP nicht aus dem Microsoft Netz stammt…
Ich habe mal noch einen Scan via urlscan.io laufen lassen und der moniert:
These URLs were requested, but there was no response received. You will also see them in the list above.
Domain
http://www.klenner.at
URL
https//www.klenner.at/wp-content/uploads/2019/07/cyber-security-17.png
Also irgendwie sind da zwei URLs falsch zusammengesetzt. Keine Ahnung, ob das irgendwie als Malicious gedeutet werden könnte.
Okay, das ist sehr seltsam. Ich werde das mal von unserem Webmaster anschauen lassen, das ist weit über meiner Fachkenntnis :-). Danke für den Hinweis.
Ich habe mal purple-tec in validator.w3.org geworfen.
Einiges ist nicht OK. Ich würde mal jemanden drüber schauen lassen der das richtig biegen kann. Ist ja die Visitenkarte und ihr verkauft ja nur keinen Ostfriesentee.
Auch die Website von qr.de wird vom validator bemängelt.
Ich erinnere mich, das es ganz böse war, transparenten Text zu verwenden. Vielleicht ist da so etwas drin?
Danke, lass ich anschauen. Aber wir verwenden sehr aktuelles WordPress mit gängigen Plugins, wenn der Outcome dann nicht (ganz?) w3 kompatibel ist, aber funktioniert, würde ich das fast in Kauf nehmen – sofern das nicht Ursache des Mailbproblems sein sollte.
@sandra
was ist denn nun klenner.at?
so etwas gibt's bei crlf crcr lflf LF cr trenneren.
Auch sehr amüsant zu suchen Tab vs. space und binäre Null im Text.
urlscan.io sagt, das purple-tec auf Amazon zugreift.
Google auch. Aber was will die Homepage bei Amazon?
auf Amazon AWS wird die von uns verwendete Fernwartung "PCVisit" gehostet und wir haben einen Link auf das Kundenmodul auf dieser Seite. Und von Google ist das Captcha
oh
klenner.at liefert denselben Inhalt wie purple-tec.
Das ist nicht gut.
klenner.at hieß die Firma früher.
auf klenner.at muss ein 301 moved permanently .
Aber was bitte geht das Microsoft an? Und warum führt die Nennung im Text zum blocken der E-Mails.
ist kleiner.at denn auch geblockt?
Genau :-)
Nee, wobei das nirgendwo mehr aktiv verwendet wird. Es kommen noch Mails an, aber versendet wird nur mehr mit @purple-tec.at und alle aktuellen Links im Umlauf sind auch auf purple-tec.at
es kommt ein moved to, aber von http auf HTTPS klenner, nicht purple-tec.
für das findet der provider das Zertifikat nicht und schickt das zur IP gehörende ssl-net.net, was natürlich nicht passt.
ssllabs bekommt aber für klenner.at ein aktuelles Zertifikat vom 4.4.24, das dann zu purple-tec weiterleiten würde.
kommt eine Email mit www klenner at durch das Exchange?
Ein Email mit https://www.klenner.at oder http://www.klenner.at wird von MDO (=Microsoft Defender for Office) nicht geblockt.
Dann muß das große Messer ran, und in den Webserver Logfiles gesucht werden, was Microsoft da macht.
klenner.at geht, mit einem aktuellen wget, nach 3 moved to auch zu http://www.purple-tec…, auf dieselbe IP.
Das funktioniert mit einem alten wget 1.11.4 nicht, da die letzte Umleitung ganz korrekt im Zertifikat von klenner steckt (was das alte wget nicht zusehen bekommt).
purple-tec ist immer noch geblockt?
Stand 27.05.2024 – 21:43 CEST ist https://www.purple-tec.at im Body-Text immer noch geblockt bei Outbound aus MS365.
Manche Provider haben einen dezidierten Server, der nichts anderes macht als "moved to" zu senden. (poor man load balancing und auch sonst sehr elegant bei unerwarteten Wartungsarbeiten, automatisch auf eine Ersatzseite/System leiten zu können )
Derzeit sieht es so aus, als würden URLs, die weitergeleitet werden nicht auf der MS Blockliste erscheint. trotz derselben IP und Inhalt
Vielleicht wäre das eine Möglichkeit, künftig zu verhindert von MS geblockt zu werden, wenn immer ein movedto liefert?
thanks.
Also:
Die "direkte" URL http://www.purple-tec.at wird geblockt, weil Phishing.
Die umgeleiteten purple-tec.at und http://www.klenner.at , die denselben (nicht nur gleichen) Inhalt von derselben IP Adresse zeigen sind nicht gesperrt.
Kann der Microsoft Algorithmus durch "301 moved to" oder entsprechende Anweisung im Zertifikat ausgetrickst werden?
Es ist doch nicht möglich das MS so schlecht programmiert
und einen Millionen Schaden bei sein Gläubigen verursacht.
Im o.a. Threads haben die jemanden abstellen müssen um die Email aus der Quarantäne holen zu lassen, 100 pro Tag.
Der Alptraum hat 6,5 Monate gedauert.
Schon gut das Störche unter Naturschutz stehen.
Sonst könnte man jetzt einen braten, oder?
Es ist ja sinnvoll, seine IP täglich gegen RBLs zu testen.
Genauso wäre es für einen Hoster sinnvoll, die Domains seiner Kunden mittels Microsoft Detonation zu testen. So könnte er automatisch böse Kunden früh erkennen und verhindern, dass gute Kunden geblockt werden…
Aber dazu müsste MS eine entsprechende Prüfmoglichkeit vorsehen. Aber das wird sicher streng geheim sein…sonst könnten ja phisher das umgehen.
Die könnten natürlich auch einen gehackten Exchange verwenden um die Domain zu testen.
Das Verfahren ist so vollständig daneben.
Es ist einfach nur krank, hirnkrank.
(ich kann mich ja nicht einmal mit anderen Postmaster über die geblockten Urls austauschen, weil die E-Mails als Phishing eingestuft würden und im Nirwana verschwinden, da keine NDR erzeugt werden…)
"Lean oder Purple Drank sind Slang-Ausdrücke für ein Mischgetränk aus verschreibungspflichtigem Hustensaft, Limonade und zerkrümelten Bonbons, das seinen Ursprung in Houston (Texas) hat und in der Hip-Hop-Kultur popularisiert wurde."(Wikipedia).
Em, nicht dass da die MS-KI Amok gelaufen ist?
Wir haben aktuell das Problem, dass Mails an Teams Channels nicht mehr ankommen.
Microsoft ignoriert einfach unsere Routing Regeln und meckert dann an, dass wir für unseren Hybrid Server kein DKIM eingerichtet haben. Dies ist halt nicht notwendig, da wir alle Mails über Exchange Online verschicken!
Eskalation mit der Produktgruppe ist sehr anstregend, vor allem da man nur mit dem Support redet.
DKIM ist ne gute Sache.
Z.B. verhindert es auch, das E-Mails verfäldcht werden.
Auch würde es erlauben, wieder wie früher, E-Mails von jeder dialup IP versenden zu können.
@willy et al
gibt es irgendwelche neuen Infos?
Oder funktioniert die Domain wieder, ohne das irgendwer irgendwas geändert hätte…wie so oft nach ner Woche oder 2 berichtet?
@Pau1:
Stand 30.05.2024 14:22 wird die URL https://www.purple-tec.at im Body einer Emails aus einem MS-365-Tenant weiterhin als Malware eingestuft ("URL detonation reputation").
War die letzten Tage recht busy. Lösung gibt es keine bis jetzt, der Support kommuniziert aber noch (immerhin). Hat sich nochmal eine geblockte Mail samt dazugehöriger Ablaufverfolgung schicken lassen (was auf dem normalen Weg nicht geklappt hat [einfach nur "Fehler"], er hat sichs dann auf eine Test-Tenant Mailadresse schicken lassen :-)). Das war am Dienstag. Heute kam ein "wir sind noch dran und melden uns" Mail.
Danke mmusterm für's testen :-)
Ich bin zwar kommende Woche auf Urlaub, bleib aber natürlich dran …
@Willy K.:
Gerne. Es wäre hochinteressant zu erfahren, wie sich der Fall auflöst.
Gruß Max.
@Willy K.: Noch eine Nachfrage zum MS-Support. Kommunizierst Du mit dem Support auf Deutsch oder Englisch?
Falls auf Deutsch, würde mich interessieren, ob das Deutsch gut genug ist, dass ihr euch versteht? Hier hatte ich schon extrem rade-brechende Supporter :-(
Ich kommuniziere auf Deutsch, habe den Eindruck, dass er ein French native Speaker ist. Es geht gerade noch so, wir haben auch ein paar mal telefoniert, da kommt auch noch die schlechte VoIP Verbindung dazu.
Neuigkeiten gibts auch, die schreib ich aber ganz unten hin :-)
Das ist schon sehr seltsam.
Wieso kann mmusterm das Problem reproduzieren, der Microsoft Support aber nicht, reitet immer noch auf einem Problem eines einzelnen Tenants rum, wobei sie doch eigentlich nur gucken müssen wie die Domain auf die Liste gekommen ist…
Auch könnten sie doch diese Domain "provisorisch" freigeben, so daß ihr Kunde die ihm vermietete Dienste zumindest nutzen kann.
Nur mit nicht-Microsoft Kunden kommunizieren zu können ist als Supporter für Microsoft Produkte schlecht für das Geschäft…
"Sie können uns derzeit nur unter der Adresse purple@gmx.de sicher erreichen." Und: "Bitte wundern Sie sich nicht, dass wir jetzt purple@gmx.de als Addresse benutzen. Das ist schon richtig und kein Phishing, glauben sie einfach dieser E-Mail".
Ich weiß nicht wie Microsoft glaubt, dass ihre Kunden arbeiten
Und wieder einmal bin ich heilfroh On-Prem Exchange zu verwenden.
Volle Kontrolle ist schon was schönes.
Mit Neffen und Nichten, wie man so schön sagt. Wenn Deine Mails beim EMPFÄNGER blockiert werden, der O365 verwendet, nutzt Dein lokaler (Exchange)Mailserver leider gar nix. Wir haben ja auch überlegt, Notfall-Offzuboarden, aber das hätte keinen Sinn gemacht.
Liebe Community, wenns wahr ist, hat Microsoft das Problem behoben. Laut Info vom Support wurde vorgestern die Domain vom Produktsupport richtigerweise als false positive eingestuft und somit die weitere Blockade verhindert.
@Sandra: Wärst Du bitte nochmal so nett und könntest den Test von voriger Woche wiederholen?
20240610 – 17:10 CEST
Outbound Email mit https://www.purple-tec.at im Body wird aus MS365-Tenant nicht mehr geblockt.
@Max: Kannst Du uns noch einen Trick, ein Stichwort etc. verraten, wie Du das Ticket letztendlich eskalieren konntest?
Eine Bearbeitungszeit von 10 Tagen überlebt nicht jede Firma :-(
Gruß Max.
Ich glaube nicht das Willy oder sonst wer da hat etwas beschleunigen können.
MS mit seinem patolhlohischem Größenwahnsinnigen Management wird das nicht zulassen.
Das ist einfach im ein 10 Tage timeout gefallen, was vom Support nun als aktive Tat verkauft wird.
Denn sie wissen nicht, was sie tun.
@Max: Ich kanns nicht mit Sicherheit sagen, aber Bewegung ist in die Sache gekommen, als ich die beiden Ticket# aus dem Link von Sandra geschickt habe. Ob das jetzt wirklich der Grund ist, geht aus der Konversation nicht hervor. Ich hab ihm das geschick:
"Der Beste Artikel dazu ist dieser:
https://techcommunity.microsoft.com/t5/exchange/url-detonation-reputation-how-do-you-like-it/m-p/3944541/page/2
Im letzten Beitrag der Kommentare schreibt ein Betroffener, dass sein Problem gelöst wurde. Vielleicht könnten Sie mit diesen Ticket# nachschauen, was hier genau gemacht wurde:
2401090040001245
2402020040010329"
Meine Ticketnummer ist: 2405091420000182
Vielleicht hilft es ja, auf diese zu referenzieren …
lg, Willy
@Willy K:
Vielen Dank. Text ist notiert – für alle Fälle ;-)
Gruß Max.
Danke für die Info.
Es bringt echt Spaß mit diesen "Profis" von Microsoft zusammen arbeiten zu dürfen.
Es beruhigt auch jeden Kunden:
Kommen emails die meine Domain enthalten morgen noch zu meinen Kunden durch?
Muss ich 10 Tage auf Rechnung schreiben vergessen, und vom Bankkredit leben?
Sollte ich mir tatsächlich ein analoges Fax Gerät aufstellen wie gleich als erstes vorgeschlagen?
Sollte ich einen Firmen Account bei GMX einrichten um meine Kunden erreichen zu können und diese mich?
Es ist schon ein geiles Gefühl, das man immer wieder anstrebt zu haben, diese totale Hilflosigkeit.
Danke für die Info.
Es bringt echt Spaß mit diesen "Profis" von Microsoft zusammen arbeiten zu dürfen.
Es beruhigt auch jeden Kunden:
Kommen emails die meine Domain enthalten morgen noch zu meinen Kunden durch?
Muss ich 10 Tage auf Rechnung schreiben vergessen, und vom Bankkredit leben?
Sollte ich mir tatsächlich ein analoges Fax Gerät aufstellen wie gleich als erstes vorgeschlagen?
Sollte ich einen Firmen Account bei GMX einrichten um meine Kunden erreichen zu können und diese mich?
Es ist schon ein geiles Gefühl, das man immer wieder anstrebt zu haben, diese totale Hilflosigkeit.