• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Erfahrungsbericht über 1 Jahr Hosted Exchange bei OVH

Firewire2002

Registered User
Vorwort
Ich bin selbst in der Hosting-Branche als Admin tätig und kenne die Hintergedanken, beim Bau von Produkten in unterschiedlichen Preissegmenten. Das ich mich für OVH und nicht meinen Arbeitgeber entschieden habe, ist 2 Gründen geschuldet
  • Ich will meine privaten Mails abseits des unbeaufsichtigten Zugriffes meines Arbeitgebers. (Bei Shared-Plattformen immer ein Problem)
  • OVH hat eine Backupmöglichkeit via API. Dazu später mehr.

3,50 Euro pro Monat sind für einen Hosted Exchange ein sehr ordentlicher Dumping-Preis. Der großteil der Konkurenz liegt beim 3 bis 5-fachen für vergleichbare Produktspezifikationen. Ich bin diesen Vertrag ohne irgendwelche Kulanz-Erwartungen eingegangen und war zuvor bereits über die schlechte Supportqualität als auch Reaktionsgeschwindigkeiten informiert. Wozu brauch man schließlich Support bei einem Hosted Exchange, wenn man mit Exchange und Outlook selbst bestens umgehen kann? Auch dazu später mehr. ;)

Testzeitraum:
Von Dezember 2014 bis Januar 2016

Der Kernbestandteil - Microsoft Exchange 2013
Wie zu erwarten war, hat OVH dort ein klassisches Exchange Cluster stehen. Auf die Features davon hat OVH keinen direkten Einfluss und die Software macht genau das was man erwartet: Mails, Kalender, Kontakte, Aufgaben und Notizen verwalten.
Alle Besonderheiten die man hier feststellt, sind Microsoft und nicht OVH anzulasten und finden sich entsprechend bei jedem Exchange Cluster. Daher gehe ich hier nicht weiter darauf ein. Aus Sicht zwischen Hosting-Kunde und Hoster: alles okay.

Die Erreichbarkeit
Im Testzeitraum konnte ich kenne andauernden Ausfälle feststellen. Laut Info-Mail von OVH soll es am 09.12.2015 größere Probleme gegeben haben. Die Mail führte auch sehr detailiert auf, welche Maßnahmen sie in wann ergriffen haben und wie erfolgreich diese waren. Für mich als Admin war das recht amüsant zu lesen, weil man parallelen zur eigenen Arbeit zieht. Bei technisch-unversierte Kunden könnte dies aber unbehagen auslösen, weil es ein Bild von Hilflosigkeit deutet, wenn man nicht aus eigenen Kenntnissen heraus die Notwendigkeiten zwischen den ganzen Misslungenen Maßnahmen sieht. Aus fachlicher Sicht ist OVH bei dem Ausfall aber kein Vorwurf zu machen, alle Maßnahmen sind nachvollziehbar.
Im Nachgang wurde den Kunden eine Gutschrift für Neubestellungenen weiterer Hosted Exchange Postfächer angeboten. Kann man nicht meckern. Wer interesse an dieser Mail hat, möge sich einfach melden. Das würde sonst den hier eh schon längeren Beitrag völlig sprengen.

Aber:
Von einem Netcologne-Anschluss (Cable/DOCSIS/Multikabel) waren immer wieder Verbindungsunterbrechungen zum OVH Exchange zu verzeichnen. Dank einem Bug im MS Outlook führt dies zum Einfrieren des Outlooks, weil die Anwendung mit der nicht mehr existenten TCP Session nicht zurecht kommt. Dieses Phänomen trat bei meinen Tests ausschließlich zwischen Netcologne und OVH auf. Es gab keine Probleme aus dem Netz von PlusServer zu OVH und keine Probleme von Netcologne zu Exchange Servern von Microsoft (Office365) und PlusServer.
Beim sniffen ist aufgefallen, dass nach erfolgreichem Verbindungsaufbau und Bestand der Verbindung über mehrere Stunden plötzlich TCP-RST anstatt ACK Pakete zurückkamen. Die Verbindungen bestanden teils nur wenige Minuten, manchmal mehrere Stunden.
Ich habe das Problem zwischen Netcologne und OVH nicht an den OVH Support geleitet. Weil ich genau weiß, dass sie bei solchen spezifischen Problemen ebenso wenig machen können, wie ich. Die Ursachenforschung ist für OVH bei einem Produkt in diesem Preissegement nicht lohnenswert. Insbesondere wenn sich am Ende rausstellen könnte, dass Netcologne und nicht OVH schuld ist.

Der Spam-Filter
Beworben wird das gute Stück einfach nur mit "Anti-Spam". Das OVH hier eine ganz eigene Definition von "Anti" hat, überraschte mich dann doch gewaltig.
Eingehend hat man die Wahl ob man seine Mails direkt ohne Spam-"Filter" an den Exchange zustellen möchte oder via alternativen MX Record über den von OVH eingekauften Spamfilter "Vade-Retro". OVH weist in der Hilfe explizit darauf hin, dass sie dabei keine Mails löschen - soweit so gut - allerdings nehmen sie auch jeden Schrott an. Über den Einsatz von DNSBLs kann man sich streiten und das man Mails nur abweist, wenn die einliefernde IP auf mehreren Blacklisten steht, ist schon seit jahren gelebte Best-Practice. Aber bei der Config die OVH auf dem Vade-Retro "Filter" fährt, werden weder dynamische Dialin IPs noch IPs gefiltert, welche auf den 15 größten und verbreitesten Blacklists stehen. Die Mails werden stumpf angennommen und als Spam getaggt.
Sorry OVH, aber das ist weder ein Spam-Filter, noch irgendein "Anti"-Spam Feature. Das ist schlicht und ergreifend ein automatischer Spam-Tagger. Mehr aber auch nicht. Was tatsächlich dann mit den Mails passieren soll, muss jeder Postfachnutzer für sich selbst individuell mit Postfachregeln nachbauen. Weil sich damit ja auch so wahnsinnig gut Spam-Scorings bewerten lassen ...
Ich habe mir deswegen ein eigenes Postfix-Setup davor gebaut und den MX Record darauf gesetzt. Mit einfachen Tests auf RFC-Konformität und ein paar DNSBLs habe ich 99% des Spams direkt abgelehnt ohne auch nur ansatzweise tiefer in die Mail hinein schauen zu müssen. Danach ging es direkt zum OVH Exchange ohne Umweg über Vade-Retro.

Bei ausgehenden Mails setzt OVH dann tatsächlich auf die gemeinübliche Definition von "Anti": Eine von meinem Monitoring generierte Mail, welche im gesamten Testzeitraum um die 20-30 Mal aufgetreten sein dürfte, wurde an mein Exchange Postfach bei OVH zugestellt. Wegen vorrübergehenden Tests von Office365 (Bei MS, nicht bei OVH), gab es eine Postfachregel, welche alle eingehenden Mails zu meinem Office365 Postfach weiterleitete. Dabei wurde meine Monitoring Mail ausgehend als Spam bewertet und nach der _ZWEITEN_ ausgehenden Mail mit fälschlicher Spam-Deklaration wurde mein Postfach für den Versand von E-Mails gesperrt. Was darauf folgte, war die Krönung meiner gesamten OVH Erfahrung und führte dazu, dass ich mein Postfach schnellstmöglich von OVH weggezogen habe. Ein Abriss:
  • 04.01.2016 01:10 Uhr - Automatische Info-Mail über Account Sperrung und Erstellung eines geschlossenen Support-Tickets mit gleichem Inhalt - Ich sollte unteranderem folgende Frage beantworten: Haben Sie eine Weiterleitungsregel auf eine andere E-Mail-Adresse?
  • 04.01.2016 20:03 Uhr - Wiedereröffnung des Support-Tickets durch mich, mit Hinweis darauf, dass deren Automatismus sich die Frage ob eine Weiterleitungsregel existiert, selbst beantworten könnte, denn die kann man Exchange-Serverseitig einfach via Powershell auslesen. Ich gab einen weiteren Hinweis darauf, dass der Spamfilter mangelhaft ist und es sich hier nicht um Spam handelt und es eine bewusst gesetzte Weiterleitungsregel war
  • 05.01.2016 19:30 Uhr - Bisher keine Reaktion von OVH - Ich habe angerufen. Der Supporter erzählte mir das er für Tickets nicht zuständig sei, er es aber gerade mal raussucht und an die passenden Kollegen weiter gibt. Warum sich um solche Fälle niemand priorisiert drum kümmert, konnte er mir nicht beantworten. Ich habe die Weiterleitungsregel an diesem Abend aus eigener Initiative entfernt, weil mein Test von Office365 abgeschlossen war.
  • 06.01.2016 11:12 Uhr - Reaktion von OVH im Ticket, sie können mein Postfach nicht entsperren, solang die Weiterleitungsregel existiert. Ich solle sie bitte entfernen. Ernsthaft? Wenn OVH diesen Fakt prüfen würde, dann hätten sie längst gesehen, das die Regel bereits entfernt wurde. Wenn sie es sowieso nicht prüfen, brauch ich sie auch nicht entfernen sondern es nur behaupten. (Ticket wurde geschlossen)
  • <Pause, weil ich die Antwort von OVH nicht bemerkt habe. Es gab keine Mail-Benachrichtigung>
  • 08.01.2016 22:22 Uhr - Wiedereröffnung des Support-Tickets durch mich, mit Hinweis darauf, dass ihr Automatismus in dieser Form weder Teil der Produktbeschreibung, noch der AGB ist und sich von mir nicht konfigurieren lässt. Der vermeintliche Spam ist keiner. Ich beuge mich nicht den Fehlimplementierungen seitens OVH. Ich verzichte bewusst auf den Hinweis, dass die Weiterleitungsregel bereits entfernt wurde. Ich ergänze, dass die Rücktrittklausel in den AGB unvollständig ist, ich sie damit als nichtig betrachte und fordere auf meinem Rücktritt von der Vertragsverlängerung zuzustimmen.

Die AGB Rücktrittklausel
Unter https://www.ovh.de/support/agb/Besondere_Vertragsbedingungen_Hosted_Exchange.pdf sind die Erweiterungen der AGB speziell für die Hosted Exchange Produkte zu finden. Das Dokument ist mit 5 von 5 Seiten ausgewiesen und der letzte Absatz am Ende von Seite 5 endet mit einem unvollständigen Satz. Als Kunde mit erwartbaren Deutsch-Kenntnissen muss ich davon ausgehen, dass der Text unvollständig ist und mir somit nicht alle Informationen zur Verfügung stehen. Damit ist die Rücktrittsklausel als unvollständig anzusehen und in der Form nicht anwendbar.

Update - 13.01.2016:
Irgendwann zwischen 08.01.2016 und jetzt (13.01.2016) wurde die veröffentlichte Ergänzung der AGB für Hosted Exchange Produkte korrigiert. Die Rücktrittklausel ist nun vollständig. Datum des Dokuments ist nach wie vor der 28. Oktober 2015.

Im OVH Ticketsystem ändert sich das Update-Datum des Tickets hin und wieder. Ich vermute Ticketsystem interne Kommentare, Ticket anderen Personen zugewiesen, oder was man sonst so mit Tickets veranstalten könnte. ;)
Eine Antwort mir gegenüber gab es bislang nicht. Aber sind ja auch erst 5 Tage vergangen. :p

Update - 31.01.2016:
  • 22.01.2016 Abends - Anruf durch mich, um nachzufragen, wie es mit meinem Rücktritt ausschaut - Antwort von OVH: Der Fall liegt beim Abteilungsleiter, der Supporter will ihn nochmal darauf hinweisen, damit der Abteilungsleiter sich bei mir meldet.
  • 25.01.2016 12:23 Uhr - Antwort vom normalen Supporter, das er es an die zuständigen Kollegen weiterleitet und sich nochmal meldet.
  • 31.01.2016 12:40 Uhr - Ticket wurde durch OVH geschlossen. Antwort gab es keine mehr. Bearbeitet ist der Rücktritt selbstverständlich auch nicht.
  • 31.01.2016 15:10 Uhr - Wiederöffnung des Tickets durch mich und Hinweis auf diesen Thread hier.

Die OVH API für PST Exports des Postfachs
Diese API war das Killerkriterium, weshalb ich zu OVH gegangen bin: Automatisierbare Offsite-Backups des Postfaches.
Die API selbst ist gut dokumentiert, aber die Authentifizierung ist in meinen Augen unnötig komplex implementiert. Da man sich mit sowas nicht jeden Tag rumärgern muss, sondern im Normalfall nur einmal, ist das zu vernachlässigen.
Für den PST Export sind mehrere API Requests notwendig. Wer sich mit der Administration von Exchange Servern via Powershell ein wenig auskennt, wird viele Schritte wiedererkennen. Die API macht also im wesentlichen nichts weiter, als die einzelnen PowerShell-Befehle als API Requests nach vorn durch zu reichen:
  • Export Task für Exchange (Exchange Powershell Aktion)
  • Download-URL generieren (OVH kopiert die PST Datei vom Exchange Server in ihre eigene File-Cloud. Dort ist sie mit einer Random-URL für ein kurzes Zeitfenster (24 Stunden wenn ich mich recht entsinne) ohne weitere Authentifizierung abrufbar)
  • (PST Datei herunterladen - nicht für API relevant)
  • Löschen des Export Tasks für Exchange (Exchange Powershell Aktion) - Löscht nur den Job im Exchange, nicht den PST-Export auf der Platte
  • Methode zum prüfen ob noch ein Export Task besteht (da ich das Script regelmäßig ausführe, nutze ich dies, um den Exchange nicht unnötig voll zu müllen)

Bevor ich anfing, meinen Hosted Exchange Account "produktiv" (privat) zu nutzen, habe ich dieses Backup Script gebaut und gegen ein leeres Postfach getestet. Aboslut leer, keine einzige Mail oder Änderung darin.
Der Export wuchs mit jedem Script-Lauf um rund 250KB und ich habe OVH darauf hingewiesen:
  • 29.12.2014 - Ticketerstellung mit ausführlicher Beschreibung, was ich mit meinem Backup-Script mache (deutlich detailierter, als hier) und welche Folgen dies hat
  • 31.12.2014 - Support informiert, dass ich zum Debuggen den Backup-Intervall für das leere Postfach auf 2 Stunden gesenkt habe und ihnen die Liste an PST-Dateien und ihrer anwachsenden Größe mitgeschickt.
  • 06.01.2015 - OVH Support hat es an Exchange Admins weitergeleitet, 2 Stunden später: Nachfrage ob sich auch die Größe des Postfaches im OWA verändert, es folgt an dem Tag weiteres Debugging-Info-Sammeln ohne größere Bedeutung
  • 07.01.2015 - Ich weise OVH darauf hin, dass die Exports seit letzter Nacht nicht mehr anwachsen und nun mit jedem export eine gleichbleibende Größe behalten (die mit mehren Megabyte für ein leeres Postfach aber immernoch viel zu viel war) - OVH Antwortet am gleichen Tag, dass die Kollegen noch dran seien.
  • 08.01.2015 - Keine Ticketinteraktion - Backups wachsen wieder an
  • 13.01.2015 - Keine Ticketinteraktion - Backups sind von 55MB auf 1MB geschrumpft
  • 14.01.2015 - Nachfrage von mir, wie der aktuelle Stand sei - OVH antwortet, sie seien noch dran
  • 19.01.2015 - OVH meldet sich, Anpassung der API steht auf der ToDo, mein 2-Stunden Intervall sei aber viel zu kurz, sie würden maximal täglich supporten, weil die Last für den Exchange zu groß würde. - Ich habe den Intervall für das immernoch leere Postfach auf täglich gesetzt und bemängelt, dass immernoch nicht erklärt wurde, warum der Export überhaupt anwächst. Ich habe ebenfalls ausgeführt, dass ich eigene Tests an separaten Exchange Servern mit der Export Funktion durchgeführt habe und dies offenbar kein Bug im Exchange ist, sondern vermutlich durch OVH verschuldet wird.
  • 29.01.2015 - OVH gesteht eigenen Fehler ein, kann aber keinen Zeitrahmen zur Behebung nennen.
  • <Das Ticket ruhte eine ganze Weile und ich hatte zwischenzeitlich angefangen gehabt den Account produktiv zu nutzen.>
  • 17.07.2015 - Ich wollte in dem alten Ticket nachfragen, aber das Ticket war geschlossen und lies sich von mir nicht wieder öffnen. Ich eröffnete ein neues Ticket und verwies auf das alte. Zusätzlich wies ich darauf hin, dass der Export Mails beinhaltete die im Postfach längst gelöscht waren und über die Retention Period der Recoverable Items weit hinaus gingen. Was eine logische Erklärung wäre, dass der Export anwächst, wenn sie immer nur anfügen, anstatt sauber neu zu exportieren.
  • 28.07.2015 - Das neue Ticket wurde Kommentarlos geschlossen
  • 31.07.2015 - Erneutes Ticket mit Bezug auf die 2 vorherigen
  • August 2015 - Alle bisherigen Tickets sind vollständig verschwunden. Von meiner Seite gibt es nur noch Screenshots aller Tickets. Im OVH Manager sind sie nicht mehr einsehbar.
  • 04.01.2016 - erneute Nachfrage, wie es mit dem Problem aussieht
  • 08.01.2016 - Ticket von mir geschlossen - Ich habs satt und will weg von OVH.

Upgrade auf Exchange 2016
Auf der Website wurde im Dezember 2015 beworben, dass Exchange 2016 bald kommt. Da im Dezember für mich auch die Verlängerung des Vertrages anstand, eröffnete ich ein Ticket mit Frage, wann Exchange 2016 zu erwarten ist und ob es eine Migration seitens OVH geben wird.
  • 14.12.2015 - Erstellung des Tickets
  • 18.12.2015 - Antwort von OVH, dass Exchange 2016 bereits bestellbar ist. Es aber keine Automatische Migration auf Exchange 2016 für Bestandsverträge gibt. Man solle also Neubestellen und selbst migrieren.
  • 21.12.2015 - Ich traue dem Braten nicht und verlängere meinen alten Vertrag
  • 07.01.2016 - Entdecke ich im OVH Manager, dass es eine automatische Migration der Bestandsverträge gibt

Das es eine automatische Migration geben wird, muss schon am 18.12.2015 bekannt gewesen sein, wenn man es bis zum 07.01.2016 bereits fertig implementiert hat. Wann genau das Feature dem Kunden zur Verfügung gestellt wurde, kann ich nicht sagen, irgendwann in diesem Zeitraum. Offizielle Nachricht gab es nicht darüber.
Für Planung und Implementierung so eines Features in Unternehmen der Größenordnung OVH gehen schon ein paar Tage drauf. Das geschieht nicht mal eben so in paar Stunden. ;)
Das dabei nun das rauskommt, hat im wesentlichen 2 mögliche Ursachen:
  • Unternehmensinterne Kommuniktion ist mangelhaft - Supporter antwortet nach aktuellem Wissensstand, der aber nicht mehr der aktuellen Unternehmensplanung entspricht
  • Umsatzsteigerung, weil der Kunde ja für Zeitraum X 2 Accounts gleichzeitig benötigt. Anrechnung der Vertragsmonate war natürlich nicht möglich. Da die Preise zwischen monatlicher und jährlicher Abrechnung sehr drastisch von einander abweichen, werden vermutlich die meisten die jährliche Variante wählen.

Die Alternative
Da das OVH Exchange Produkt alles andere als frustfrei war, habe ich mich entschlossen Office365 Exchange Online zu testen. Mit MwSt ist das Produkt ca. 0,70 Euro teurer als bei OVH. Vorsicht bei den Preisangaben: Das Angebot von Microsoft richtet sich vorrangig an Gewerbetreibende. Die Preise auf der Website enthalten keine MwSt.
Ich habe meinen Account dort deutlich als Privat kenntlich gemacht (Unternehmensname "Privat") und hatte einige Fragen per Ticket an den Microsoft Support gestellt, im wesentlichen ging es um unterschiedliche Test-Szenarios und ganz konkrete Funktionen, weil aus der Produktbeschreibung nicht genau hervor ging, in welchen Produkten nun einzelne Features tatsächlich enthalten sind. Marketingüblich werden nur Feature-Gruppen beschrieben. Nach weniger als 12 Stunden rief mich ich eine freundliche Support-Dame von Microsoft an und beantwortete mir alle meine Fragen fachgerecht und ausführlich. Einige ganz spezielle Automatisierungsgeschichten, welche so nicht Teil des Produktes sind, sollte ich bitte im Community-Forum von Microsoft stellen.
Auch im Community-Forum erhielt ich in weniger als 24 Stunden eine hilfreiche Antwort direkt von Microsoft.
Die administrativen Möglichkeiten sind bei MS Exchange Online deutlich umfassender, als was OVH anbietet. Stabil und der Support ist grandios. Mein automatisiertes Backup habe ich hinten angestellt. Nach der Erfahrung wie oben, ist es mir lieber, eine Terminserie im Kalender für das Backup zu haben.

Fazit
Von einem Hoster dieser Größe wie OVH erwartet man schon etwas mehr. Schaut man sich die Beschwerden im OVH eigenen Kundenforum an, wird deutlich, dass ich kein Einzelfall bin. Das hat Persistenz über Jahre und das gesamte Produktportfolio hinweg. Wie man an den obigen Beispielen sieht, bedeutet Support eben nicht nur dummen Kunden zu helfen, sondern auch Fehler des Hosters zu beseitigen. Wenn das derartige Reaktionen und Verzögerungen mit sich bringt, ist das für den ernsthaften Einsatz einfach unbrauchbar.
Wer allerdings getrost längere Zeit auf sein Postfach verzichten kann, keinen Wert auf Datenkonsistenz legt und mehr Geduld hat, als die Vertragslaufzeit vorsieht, kann gefahrlos zugreifen.
 

Attachments

  • Besondere_Vertragsbedingungen_Hosted_Exchange.pdf
    240.3 KB · Views: 683
  • Besondere_Vertragsbedingungen_Hosted_Exchange_korrigiert.pdf
    240.4 KB · Views: 422
Last edited by a moderator:
Ok, bin kein Exchange Admin, aber war trotzdem interessant zu lesen. Von diesem Provider werde ich mich fernhalten.

Ganz gute Erfahrungen habe ich mich mit dem kostenlosen outlook.com für Kalender und TODO gemacht. Für Mail verwende ich allerdings ein anderes Postfach, da k9-Mail nur IMAP kann.
 
outlook.com habe ich mir auch angeschaut. Für den klassischen Privatmann eine super Alternative zu GMX und Co, weil sie eben auch ActiveSync anbieten. Allerdings fehlt dort ein wichtiges Feature: Die eigenen Domains.
 
Danke für den Bericht! Ist wirklich interessant geschrieben.

Office365 Exchange Online steht bei uns diesen Monat auch an...
 
Ich habe den Verlauf im ersten Beitrag aktualisiert.
Die veröffentlichte Rücktrittklausel wurde korrigiert. Passend dazu habe ich auch mal beide Varianten der AGB Ergänzung mit angehangen.
 
Hi,

interessanter Bericht. Ich habe zwei Billigserver bei OVH für Backup und Monitoring (günstigeren Backupspace inkl. Rechenleistung für andere Dinge bekommt man wohl kaum).

Ich habe eine Anmerkung zum oben genannten Outlook.com und eine daraus resultierende Frage zu Office365:
Outlook.com hält sich reproduzierbar nicht an Konventionen beim Annehmen von E-Mails. Es werden E-Mails von Servern, die aus nicht nachvollziehbaren Gründen auf Blacklists zu stehen scheinen kommentarlos angenommen und dann gelöscht. Für den sendenden Server ist die Mail erfolgreich zugestellt, beim Empfänger kommt sie nie an, weder im Posteingang, noch im Spamordner.

Kannst du dieses Verhalten auch bei Office365 feststellen, oder sind die da, was filtern angeht etwas erträglicher?
 
Wenn du einen Server hast, der nicht an outlook.com senden darf (bzw. die Mail dort gelöscht wird), kannst du mir gern eine Mail an *********@**********.net von dort senden. ;)
Ich habe aktuell leider zu wenig Server die diesem Phänomen gerechet werden. Alle meine Tests brachten bisher entweder eine saubere Abweisung oder eine Zustellung der Mail hervor.

Edit 2022-12-10: E-Mail Adresse für den Threadverlauf nicht mehr relevant und entfernt.
 
Last edited:
Hab da nur noch 5 euro Backupserver rumstehen... die tun wiederum einwandfrei solang man keinen HW defekt hat ;)
 
Ich habe eine Anmerkung zum oben genannten Outlook.com und eine daraus resultierende Frage zu Office365:
Outlook.com hält sich reproduzierbar nicht an Konventionen beim Annehmen von E-Mails. Es werden E-Mails von Servern, die aus nicht nachvollziehbaren Gründen auf Blacklists zu stehen scheinen kommentarlos angenommen und dann gelöscht. Für den sendenden Server ist die Mail erfolgreich zugestellt, beim Empfänger kommt sie nie an, weder im Posteingang, noch im Spamordner.

Das ist ein altbekanntes Problem mit allen Mailserver die Microsoft je hatte und vermutlich je haben wird. Irgendwo zwischen Annahme durch die externen SMTP-Server und der Zustellung zum Konto geht die Email schlicht "verloren" was technisch verboten und juristisch zumindest äusserst fragwürdig ist.
Versucht man als Firma mit Microsoft Kontakt auf zu nehmen erhält man nur die Rückantwort dass sie keine Angaben zu Ursache oder Technik machen könnten. Spätestens seit Microsoft mir mehrmals leere (pingt aber mehr nicht) IP's welche ich zwischen Mailserver in die Liste der delist-requests gestreut hat mit "active spamming" verweigert hatten und erst nach Rückfrage dann schnell freischalteten, ist mir klar geworden dass deren Mitarbeiter halt auch in dem Bereich wohl eher inkompetent als böswillig sind.

Proofpoint (Icloud) ist übrigens nur einen Deut besser in dass die Emails wenigstens mit entsprechendem Status-Code verweigert werden. Die verlangen von allen IP's eines IP Netzes gültige rDNS sogar wenn die IP gar nicht in Verwendung ist - sonst wird das ganze Subnet schlicht nicht freigegeben.
 
Danke für Deinen Bericht! OVH fällt also auch für mich erstmal raus aus der Anbieter Suche, zumindest für Hosted Exchange :)

Basti
 
@d4f
wemaflo konnte es mit seinen Systemen bislang nicht reproduzieren. Wenn du noch einen betroffenen Server hast, würde es mich freuen, wenn du 2 Testmails schickst. :)

Freemail Variante: **********@outlook.com
Exchange Online: **********@************.net

Edit 2022-12-10: Mail Adressen für den Thread-Verlauf nicht mehr relevant und entfernt. ;)
 
Last edited:
Das ist ein altbekanntes Problem mit allen Mailserver die Microsoft je hatte und vermutlich je haben wird. Irgendwo zwischen Annahme durch die externen SMTP-Server und der Zustellung zum Konto geht die Email schlicht "verloren" was technisch verboten und juristisch zumindest äusserst fragwürdig ist.
Ja, das Problem hatte ich auch seit Jahren.
Ich hätte ja nichts dagegen, wenn die Mails als Spam eingestuft werden oder abgelehnt (also doch, hätte ich, aber nicht in dem Maße), aber man kann nicht Mails anstandslos annehmen und dann löschen. Ist ja wie wenn die Postannahmestelle ein Einschreiben unterschreibt und dann die Nachricht vernichtet.
Es scheint eher so zu sein, dass per Default dort IPs geblockt werden und dann manuell freigeschaltet werden müssen.

Ich habe gestern noch mal rum probiert, die letzten "Beschwerden" scheinen Wirkung gezeigt zu haben, meine Mailserver werden nur noch als Spam eingestuft, die Mails kommen aber im Postfach an.

@Firewire2002: Ich probiere gleich mal aus, ob bei meinen OVH-Servern der Filter zuschlägt. Die IPs habe ich noch nie zum Mailversand genutzt und auch noch nicht entblockt.

Edit:
Ich kann das Verhalten von damals nicht mehr nachstellen. Wenn ich mich vom OVH-Server verbinde bekomme ich bei mail from: folgende Antwort:
550 SC-001 (BAY004-MC1F41) Unfortunately, messages from 37.59.60.14 weren't sent. Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.
Connection closed by foreign host.
Bis auf die Tatsache, dass man offensichtlich von OVH-Servern keine Mails an outlook.com senden kann, kann ich damit leben.

Ich habe auch eine Mail über Telnet an den Hosted Exchange geschickt, die kam an. Auch gut.
 
Last edited by a moderator:
Ich will meine privaten Mails abseits des unbeaufsichtigten Zugriffes meines Arbeitgebers. (Bei Shared-Plattformen immer ein Problem)

Kann ich nachvollziehen. Die veränderten datenschutzrechtlichen Bestimmungen in Frankreich waren/sind für dich aber kein Kriterium?
 
Nein.
Die Begründung würde den Thread aber zuweit vom Thema abdriften lassen. Daher verzichte ich an dieser Stelle darauf.
 
Hallo,

ich bin auch gerade auf der Suche nach einem Hosted Exchange 2016-Anbieter - und das OVH-Angebot ist schon ziemlich attraktiv. Allerdings wäre ein Fehlen von DNSBLs tatsächlich mehr als merkwürdig.

Leider bin ich kein Exchange-Admin (deswegen will ich das ja hosted), daher fällt es mir schwer zu verstehen, was eigentlich hinter dem ganzen Problem steht: Erlaubt Exchange gar kein rejecten auf DNSBL-Basis? Ist das also ein Problem von Exchange - und wird auch bei anderen Hostern mit anderen AntiCPAM-Lösungen nicht besser - oder ist das bei OVH einfach dumm implementiert?

Und andersrum gefragt: Wie "gut" ist denn so VadeRetro - also: holt es dieses Defizit "nachträglich" - nach der Annahme der mail - durch excellentes Filtern wieder 'raus? SPAM-Folder dürfte natürlich ganz schön voll werden - aber werden die denn wenigstens korrekt erkannt?

Und: von DNSBL mal ab: verstehe ich Deinen Bericht so richtig, dass OVH die mails zwar klassifiziert, aber nicht in einen dedizierten SPAM-Ordner verschiebt? Das bedeutet man müsste passende Regeln für alle User anlegen? Das wäre ja schon irgendwie Murks.

Also irgendwie passt das alles nicht: Die verkaufen das doch jetzt schon eine Weile, kann doch nicht sein, dass sie Anti-SPAM-Lösung soooo schlecht und blöd ausrollbar ist...?

Firewire: wie gut arbeitet der Filter denn nun?

Wie gesagt erscheint mir OVH attraktiv, wegen:
- Exchange 2016
- Preis
- nur ein Lieferant (wir nutzen von denen noch andere Leistungen)
- Hosting wenn schon nicht in DE, so doch zumindest in EU - das ist auch das Argument gegen Office365 / Microsoft.
- Public Folder mit genug Quota

Hat noch jemand anders VadeRetro bei OVH im Einsatz und kann etwas von seinen Erfahrungen teilen?

Danke und viele Grüße,
Southy

Ach ja, P.S.: Die Idee mit einem vorgeschalteten Postfix liegt natürlich nahe, möchte ich aber gerne vermeiden.
 
Erlaubt Exchange gar kein rejecten auf DNSBL-Basis? Ist das also ein Problem von Exchange

MS Exchange besteht aus 2 Funktionsebenen: Mailbox + Client Access und den Edge-Servern
Die einzige Funktion der Edge Server ist das annehmen von E-Mail, Filtern+Klassifizieren und relayen zu den Mailbox Servern. Auf den Edge-Servern könnten auch DNSBLs befragt werden. Da die Edge Server aber in ihrem Funktionsumfang recht banal sind, kann man die auch Problemlos durch irgendwas anderes ersetzen. Egal ob nun ein Linux Server mit Postfix oder irgendeine Antispam Appliance.

Ob OVH Edge Server einsetzt, kann ich dir nicht beantworten. Habe aktuell keine Mail-Header mehr zur Hand. Sofern es da überhaupt ersichtlich wäre, ob es ein Edge-Server wäre, oder was anderes.

Reine Vermutung: Ich würde denken, dass OVH keine Edge Server einsetzt und diese durch den eingekauften Spamfilter VadeRetro "ersetzt" hat. Das muss nichts negatives sein, wenn denn dieser VadeRetro das machen würde was man von einem SpamFILTER erwarten würde. Wie weiter oben geschrieben, ist das eher ein SpamTAGGER. :p

oder ist das bei OVH einfach dumm implementiert?
$True

Wie "gut" ist denn so VadeRetro
Die Erkennungsrate war nicht gerade überwältigend, da kam auch viel ungetaggter Spam durch.

verstehe ich Deinen Bericht so richtig, dass OVH die mails zwar klassifiziert, aber nicht in einen dedizierten SPAM-Ordner verschiebt?
Korrekt, und wie oben schon geschrieben, steht die Spam-Klassifizierung in den Mail-Headern, welche sich nur bedingt mit Postfachregeln auswerten lassen. Da nützt einem das Spam-Scoring recht wenig, wenn man am ende in der Sortierung nur noch auf $True und $False prüfen kann.

Das bedeutet man müsste passende Regeln für alle User anlegen?
Korrekt.

Die verkaufen das doch jetzt schon eine Weile, kann doch nicht sein, dass sie Anti-SPAM-Lösung soooo schlecht und blöd ausrollbar ist...?
Wenn man sich die Konkurenz anschaut, sieht man, dass es deutlich besser geht. Das ist/war ein hausgemachtes Problem von OVH.

Firewire: wie gut arbeitet der Filter denn nun?
Wie oben zu lesen ist, habe ich mich anfang des Jahres von diesem Unternehmen getrennt und bin mit meinem Hosted Exchange Account direkt zu Microsoft gegangen: https://products.office.com/en-us/exchange/compare-microsoft-exchange-online-plans
Vergleichbares Angebot zu einem vernachlässigbaren Mehrpreis (aufpassen, die Preise auf der Website sind ohne Mehrwertsteuer, weil auf Unternehmen ausgerichtet, kann man aber auch Privat bestellen).
Deutlich umfangreicheres Admin-Interface, vernünftiger Spamfilter und professioneller Unternehmenssupport. Siehe Beschreibung oben. Das seh ich nun auch nach 8 Monaten Nutzung nicht anders. Wobei ich zugegebener Maßen den Support nach dem oben beschriebenen Fall nicht mehr benötigt habe. Der Exchange läuft und macht genau das was man erwartet.

Hosting wenn schon nicht in DE, so doch zumindest in EU - das ist auch das Argument gegen Office365 / Microsoft.
Office365 liegt für Deutsche Nutzer in Irland/Niederlanden. Deine Bedinung mit "zumindest EU" wäre erfüllt. Zumal sich Frankreich mit seinen Datenschutzgesetzen in der letzten Zeit alles andere als gerühmt hat. Da würde ich mir um Daten in Frankreich, die bei einem französischem Unternehmen liegen, deutlich mehr sorgen machen. Microsoft hat ja zuletzt auch bewiesen, dass es der US Regierung parole bieten kann und nicht einknickt. Hinzu kommt der Azure Cloud Kram Ende des Jahres ja auch nach Deutschland mit Telekom als Datentreuhänder. Es wäre zu erwarten, dass die Hosted Exchange Angebote dann ebenfalls irgendwann hier zu lande mit angeboten werden.

Alle beschrieben Erfahrungen und Schlussfolgerungen basieren nach wie vor auf dem Stand von Januar 2016. Ob sich seit dem bei OVH etwas verändert hat, kann ich nicht bewerten. Die Erfahrung oben hat mir allerdings gereicht, um diesem Unternehmen so schnell keinen Hosted/Managed Service mehr anzuvertrauen. Da ein Umbau der Unternehmensphilosophie immer Zeit in Anspruch nimmt (sofern OVH überhaupt dran denkt, daran mal etwas zu verbessern) schau ich mir das vielleicht in 1-2 Jahren noch mal an. So fern sie das Produkt dann überhaupt noch im Portfolio haben.
 
Back
Top