In Threads zum Thema Hosting habe ich ja immer gerne All-Inkl empfohlen; heute hatte ich allerdings ein höchst unerfreuliches Support-Erlebnis und würde bezüglich der strittigen Sachfrage gerne Eure Einschätzung hören.

Eine gute Freundin von mir betreibt ein kleines Unternehmen, dessen IT ich verwalte (sie hat mit Technik nichts am Hut). Fürs Web hat sie – auf meine Empfehlung hin – einen Business-Tarif-Webspace bei All-Inkl. In bestimmten Situationen werden von einem anderen, via Plesk von mir verwalteten virtuellen Server einmal pro Stunde kurze Status-Emails (ASCII-Einzeiler) an den zu ihrem Tarif gehörenden All-inkl-Mailserver gesendet. Das funktionierte seit 3 Jahren reibungslos.

Vor 2 Tagen blieben diese Emails plötzlich aus, obwohl sie hätten kommen müssen. Ein Blick in die Mail-Logdatei des virtuellen Servers ergab, dass sämtliche Mails von diesem Mailserver an den All-Inkl-Mailserver zurückgewiesen werden mit der Fehlermeldung

Aus welchem Grund auch immer vor 2 Tagen plötzlich ein paar dieser Emails, die seit 3 Jahren problemlos empfangen wurden, als suspicious eingestuft wurden – als dies einmal passiert war, versuchte Postfix auf dem virtuellen Server alle 10 Minuten, diese Email erneut zu versenden, was jedes Mal erneut nicht funktionierte, sodass sich dieser Prozess aufschaukelte und am Ende zu Hunderten von vergeblichen Sendeversuchen führte.

Als ich deshalb den All-Inkl-Support telefonisch kontaktierte und bat, den Empfang wieder zu entsperren, verweigerte er dies kategorisch mit der Begründung, von dem virtuellen Server würden „Hunderte von Spammails versendet“. Meine Erläuterung, dass dies keine Spammails seien, sondern von dem virtuellen Server korrekt versandte Mails mit vielfach wiederholten Zustellversuchen, ließ er nicht gelten und meinte, dann sei der sendende Mailserver falsch konfiguriert: wenn er vom empfangenden Mailserver obige Fehlermeldung erhielte, müsse er weitere Sendeversuche der betroffenen Emails sofort einstellen.

Meinen Einwand, das Verhalten des sendenden Mailservers sei korrekt, bei dieser Fehlermeldung müsse er erneut versuchen, die Mails zuzustellen (immerhin steht das explizit in der Fehlermeldung: Try again later.), konterte der Support-Mitarbeiter damit, das habe „man vielleicht vor 20 Jahren mal so gemacht, aber doch heute nicht mehr“. Stattdessen müsse der sendende Mailserver die Mails als unzustellbar behandeln. Nur wenn mehrere Tage keine Emails mehr von dem virtuellen Server gesendet würden, würde der „Sperr-Automatismus“ bei All-Inkl den Empfang wieder entsperren; er könne (für mein Empfinden: wolle) da überhaupt nicht manuell eingreifen.

Mir ist nicht bekannt, dass man heutzutage den expliziten Inhalt von Fehlermeldungen nicht mehr befolgen sollte, aber ich bin auch nicht näher mit der Server-Admin-Szene vertraut, sondern gehe davon aus, dass die Default-Einstellungen einer aktuellen Plesk-Installation den heutigen Gepflogenheiten entsprechen. Daher hätte ich gerne eine Einschätzung von Leuten, die sich damit näher auskennen, ob All-Inkl Recht hat oder ich.

Für mich war das eine sehr unerfreuliche Begegnung mit dem Support; ich wusste mir auf die Schnelle (der Empfang muss dringend wieder funktionieren) nicht anders zu helfen, als in der Kommandozeile den ganzen Mail-Spool zu löschen (nachdem ich die wichtigen Mails aufwändig manuell rausgefischt hatte) – in Plesk habe ich nichts gefunden, was ich in dieser Situation hätte machen können, um weitere Zustellversuche zu unterbinden, und direkt wollte ich in Postfix keine Konfigurationsdateien verändern, um keine Konflikte mit Plesk heraufzubeschwören.

Auch seltsam: der Support weigerte sich, Emails in dieser Sache an mich zu schicken, sondern schickte sie an meine Freundin, die sie dann an mich weiterleiten musste, da All-Inkl immer nur an denjenigen Emails sende, der den Tarif gebucht hat. Mein Einwand, gerade bei einem Business-Tarif sei doch der Auftraggeber nicht zwingend deckungsgleich mit dem für die Technik Verantwortlichen, entgegnete er, wir wären „die ersten in 20 Jahren, die das wollen würden“ (irgendwas hat es mit diesen 20 Jahren auf sich …).

Mir geht es genau andersrum, ich hielt und halte nichts von All-Inkl aber in diesem Fall kann ich denen nur zustimmen. Wenn Du eh schon in ein Limit gelaufen bist, bringt das nix ständig weiter zu senden. Allerdings wäre eine fachliche Auskunft gewesen, wie lange dieses Limit aufrecht erhalten wird.
Aber tröste Dich, bei anderen Anbietern läuft es auch nicht anders. Ähnliche Fälle hatte ich schon mit Hosteurope und Mitwald. Es drehen einfach alle hohl aus Angst von den ganz Großen wegen SPAM geblockt zu werden.
Ich habe deswegen E-Mail Versand über eigene Server oder Server der Hoster komplett aufgegeben und alle Postfächer auf M365 umgestellt, was übrigens viele Hoster auch tun.

Der Support hat recht. Mails werden in dem Fall nicht explizit neu verschickt, sondern landen im Bounce. Wenn der mehrere male fehlschlägt, wird der Zustellversuch automatisch abgebrochen, und der Absender erhält eine Unzustellbar-Mail.

Ich würde das Problem ja ohnehin anders lösen, über ntfy.sh oder eine Datei ins Netzlaufwerk schreiben. Da Weia aber seinem Ansatz sicherlich treu bleiben will, habe ich ein Skript erstellt, das eine Status-Mail mit curl direkt an den Mail-Server sendet, getestet mit einem eigenen all-inkl-Account (du benötigst die Zugangsdaten der Empfängerin). Es sendet genau einmal und meldet nur den curl-Exitcode zurück. Es gibt keine eigene Retry-Logik. Wiederholungsversuche müssten separat (z. B. per Cronjob) gebaut werden.
Ich würde das Problem ja ohnehin anders lösen, über ntfy.sh oder eine Datei ins Netzlaufwerk schreiben. Da Weia aber seinem Ansatz sicherlich treu bleiben will, habe ich ein Skript erstellt, das eine Status-Mail mit curl direkt an den Mail-Server sendet, getestet mit einem eigenen all-inkl-Account (du benötigst die Zugangsdaten der Empfängerin). Es sendet genau einmal und meldet nur den curl-Exitcode zurück. Es gibt keine eigene Retry-Logik. Wiederholungsversuche müssten separat (z. B. per Cronjob) gebaut werden.
Weil die Mail eingeloggt über das Postfach eingeliefert wird, bewertet All-Inkl keinen fremden Mailserver mehr. Die Reputationsprüfung des MX-Wegs entfällt. Beim Test gingen 23 Mails ohne 451 durch.
Für den Support-Zugang könntest Du ggf. eine Vollmacht bei all-inkl hinterlegen.

Hmm, das passiert, wenn man die Nachricht im externen Editor schreibt, einfügt und im MTN-Guckloch nicht sieht, was schon vorhanden ist 🤷‍♂️

Die haben wohl etwas an der Spam-Filterung geändert, würde das geänderte Verhalten erklären.

Vielleicht hilft whitelisten der Sende-Adresse (bzw. Domain) im KAS, möglicherweise greift das aber erst nach ein paar Tagen. Temporär und falls das nicht zu aufwändige Änderungen bedeutet, hilft vielleicht Weiterleiten über einen anderen Mail-Server in der Zwischenzeit.

Provider dürfen aus rechtlichen Gründen nicht mit unautorisierten Dritten über Probleme reden und Änderungen veranlassen, dazu muss man je nach Provider als Ansprechpartner, Admin-C oder Vertragsinhaber eingetragen sein. In solchen Fällen kann man vorübergehend die Mail-Adresse des Inhabers auf die des "Betreuers" ändern. Oft ist schriftliche, sachliche Kommunikation mit exakter Fehlerbeschreibung besser als ein Telefonat, da der Support in der Antwort keinen Quatsch schreiben kann.

Hello,

wir empfehlen und nutzen All-Inkl eigentlich immer.

Ja, manchmal hat man einen Prinzipienreiter am Telefon. Mein Vorgehen dann, einfach 1-2 Tage später wieder anrufen. Meist wer anderes dran und dann das Problem neu aufwickeln, nach dem Motto, melde mich nochmal weil mir das nicht klar ist, was ( Hier… ) welcher Server warum wann wie wem schickt/ zurückmeldet und wie die das Problem lösen würden. Frei nach Frau Katzenberger: Sei schlau, stellt dich dumm…

Inhaltlich:
Naja, so ganz generell hat er schon nicht unrecht, dass zu viele zyklische eMails SPAM sein könnten.

Ich würde mal – wie schon von hypophora erwähnt ) schauen, ob Du KAS.webmail des empfangenden Mail-Accounts Deinen nicht auf die WhiteList bekommst. Ferner schau mal auf die SPAM-Einstellungen in dem Postfach.

Und ggf. umgehst Du das ganz anders:
Leg doch einfach im KAS-Account Deiner Freundin ( Domain-Beispiel www.xyz.xx ) einen weiteren Mail-Account an: Status@yxz.xx ( und im Postfach SPAM-Filter konfigurieren… ). Den bindest Du als Sender bei Dir ein. Dann schickt All-Inkl an All-Inkl…

Greetings, C.

Zunächst mal vielen Dank für Eure Antworten!

Ich habe allerdings eine grundlegende Forums-Regel missachtet: Schildere nie irgendeine Art von Problem, für das du keine Lösung in Form eines Skripts brauchst, ohne das explizit zu erwähnen, sonst schreibt dir sudoRinger schneller eines, als du schauen kannst!  – Danke dafür, aber jetzt habe ich ein schlechtes Gewissen, weil ich es gar nicht brauchen werde; ich hätte wohl klarer machen müssen, dass das spezifische Problem ja jetzt gelöst ist (durch das Löschen des Mail-Spools und anschließend eine Umstellung des Zusammenspiels der Server, um das in Zukunft zu verhindern), aber ich gerne eine Einschätzung wollte, wie es sich grundsätzlich mit solch einem Email-Problem verhält und was hier korrekt ist.

Ja, das leuchtet mir von der Sache her ein, aber ist dann die gesendete Fehlermeldung nicht die falsche. Ich meine, da steht nunmal Try again. Oder ist das wirklich rein historisch und nicht so gemeint, obwohl es da steht?!?

Die andere Frage, die sich dann stellen würde, wäre, warum Plesk Postfix dann nicht nur nicht so vorkonfiguriert, sondern eine entsprechende Umstellung der Konfiguration auf GUI-Ebene gar nicht erlaubt. Plesk ist immerhin eine der verbreitetsten GUI-Admin-Oberflächen,.
Das haben sie mir ja gesagt: So lange, bis mehrere Tage lang keine einzige Mail von dem virtuellen Server an den All-Inkl-Mailserver gesendet wird. Das war ja mein Catch-22: um wieder Mails senden zu können, darf ich keine Mails senden. Ein kurzfristiges Aufheben der Sperre durch All-Inkl, und der Knoten wäre geplatzt und das Problem gelöst, aber das wollten (angeblich „konnten“) sie eben nicht, sodass ich als Notbehelf den Spool löschen musste.

Für die Zukunft ist der Weg der Mails umgestellt, sodass das Problem nicht mehr auftreten wird; das war kein großes Ding. Das große Ding war, den wiederholten Versand der bereits gebouncten Mails zu verhindern, ohne wichtige Inhalte zu verlieren, das war eine mehrstündige Notoperation am offenen Herzen, weil mir auf die Schnelle keine intelligentere Lösung als das Löschen des Mail-Spools einfiel und All-Inkl nicht kooperieren wollte.
Ah, interessanter Gesichtspunkt. Das stand mir überhaupt nicht vor Augen.
Ich nehme an, M365 soll Microsoft 365 bedeuten, was ich aber auch nur vom Namen her kenne. Was wäre da anders? (Theoretisches Interesse, ich werde ganz sicher auf keine Lösung von Microsoft setzten.)

Was heißt landen im Bounce technisch genau? In Postfix auf meinem virtuellen Server landeten die noch zu versendenden Mails in einem Verzeichnis namens defer, meinst Du das?
Ja, aber dazu kam es noch gar nicht. Ich kenne das so, dass das erst nach einigen Tagen passiert. Bis dahin wären aber stündlich neue Emails aufgelaufen, die aufgrund der Sperre erneut zurückgewiesen worden wären, wodurch der Server wiederum die Sperre weiter aufrechterhalten hätte. Selbst wenn ich das Versenden neuer Emails gestoppt hätte, hätte es Tage gedauert, bis alle Emails als unzustellbar an den Absender zurückgegangen wären und dann nochmals Tage, bis der „Automatismus“ bei All-Inkl die Sperre wieder aufgehoben hätte. So lange konnte ich einfach nicht warten.

Nochmals herzlichen Dank. Du beschämst mich jetzt, weil ich in diesem Fall so flexibel bin, meinem bisherigen Ansatz untreu zu werden, und Du dir daher vergebens Mühe gemacht hast. Aber das Skript bleibt für die Nachwelt mit ähnlichen Problemen ja jetzt wenigstens erhalten.

Servus,

so genau kenne ich die internen Abläufe bei denen ja nicht, kann mir aber prinzipiell vorstellen, dass der first level jetzt nicht unbedingt die Macht hat dich whitezulisten oder ähnliches.

Und dass die scheinbar an ihren Spamfiltern arbeiten finde ich sogar eher löblich.

Aber was ich nicht verstehe, warum keine api? Wenn deine Systeme untereinander reden sollen wäre das doch allein schon aus Gründen der Analyse deutlich besser als E-Mail. Oder was genau sollen deine Mails machen wenn die periodisch eingeliefert werden? Für mich klingt das Prinzip schon nach overhead.

Und was auch noch nicht erwähnt wurde (so glaube ich) hast du deine reputation auch mal gecheckt? Evtl. hast du ja auch einen nat-vps und einer deiner Nachbarn steht auf irgendeiner Liste?

Prinzipiell gebe ich dir aber recht, Support sollte immer freundlich sein und versuchen das Problem zu lösen, aber auf der anderen Seite erwarten wir alle, dass wir weniger spam usw bekommen, da muss es eben auch ab und zu veränderungen geben.

Vermutlich, ja. Der Support-Mitarbeiter hat trotz aller Erklärungen meinerseits aber darauf bestanden, der Auslöser seien „Spam-Mails von meinem Server“ gewesen
Jetzt kann ich das nicht mehr testen, aber ich wäre davon ausgegangen, dass mir der Support-Mitarbeiter das gesagt hätte, falls das eine Lösung gewesen wäre.
Wie gesagt, das Problem ist ja jetzt gelöst, aber aus generellem Interesse: wie hätte das bei den bereits versandten und zurückgewiesenen Mails noch funktionieren können? Auf dem virtuellen Server sind sie mit der Zeiladresse gespeichert, und bei All-Inkl kann ich nichts weiterleiten, weil erst gar nichts ankommt.
Das leuchtet mir natürlich ein; das Problem war, dass laut All-Inkl die Autorisierung eines Dritten nicht möglich wäre (das hätten wir natürlich gemacht), alle Kommunikation müsse über die- und nur diejenige Person laufen, die als Kunde bei All-Inkl registriert ist und die Rechnungen erhält. Und das ergibt bei technischen Problemen bei einem Business-Tarif für mich einfach keinen Sinn; erst recht nicht, dass in 20 Jahren noch nie jemand danach gefragt hätte.

In diesem speziellen Fall war dafür halt einfach nicht die Zeit.
Grundsätzlich ja. Aber nachdem das 3 Jahre problemlos ging, habe ich es halt einfach so laufen lassen. Ich hätte und habe mich für die Zukunft ja auch nicht für gegen eine andere Lösung gesperrt, nur musste erstmal das ganz akute Problem schnell und ohne Datenverlust behoben werden.

War aus den historischen Anfängen der Einfachheit halber so gewachsen und hatte bislang nie Probleme gemacht, also klassischer Fall von Never change a running system …
Kein NAT-VPS, aber die Server-Reputation ist in der Tat miserabel, wie ich von All-Inkl erfahren habe. Wie checkt man sowas selbst?
Ja, das ist auch kein Problem. Nur bei den Umstellungswehen hätte ich mir etwas mehr Kooperation gewünscht.

Ob historisch oder einfach nur unspezifisch, in der Meldung werden ja nicht die Einstellungen des Systems widergespiegelt. Die Telekom hatte mal eine Retry auf 3 Monate eingestellt.Plesk geht meinen Meinung nach immer noch davon aus Mails selbst zu versenden und nicht ein nachgeschaltetes Hoster-Relay zu haben. Ob die das noch ändern ist angesichts der Tatsache der Schwierigkeiten einen eigenen Mailserver zu betreiben, fraglich.Kann ich aber bestätigen. Intern wurde mir mal gesagt, die entsprechenden Stellen sind selbst für die Supporter gesperrt.Ja, genauer Microsoft Exchange online. Ganz sicher nicht mein Wunschkandidat! Die können einfach machen was sie wollen. Lehnt Microsoft was ab, rudern alle um ihre Mails wieder durch zu bekommen. Versendet Microsoft außerhalb des Standards, passen alle anderen den Empfang halt an. Und dem Kunden sagt man einfach, geht bei Microsoft nicht und die Diskussion ist beendet.

Ja so kenne ich das auch. Mein Mailserver versucht auch die Mail erneut zuzustellen, wenn der annehmende Mailserver diese abweist. Frueher hat man Mails ohnehin immer beim ersten Zustellversuch abgewiesen um Spam zu reduzieren, erst wenn sich der einliefernde Mailserver kurz darauf ein zweites Mal gemeldet hatte wurde die Mail angenommen.
Ich habe aber bei mir den Mailserver so konfiguriert, dass die Abstaende in denen er eine erneute Einlieferung versucht mit jedem Versuch immer laenger werden. Also beim ersten Versuch nach 2 Minuten, anschliessend dann nach 10 Minuten, 30 Minuten, 1 Stunde, 6 Stunden am Ende alle 12 Stunden nach 3 Tagen dann die Rueckmeldung an den Sendenden, dass sich die Mail nicht zustellen laesst.
Damit halten sich die erneuten Zustellversuche des Mailservers in Grenzen.
Besser waere es allerdings wenn man bei All-Inkl die eigene IP des sendenden Servers beim Mailserver gleich whitelisten koennte zumal die Mail so wie ich es verstanden habe ja lokal bei All-Inkl bleibt und in dem zu Tarif gehoerenden Mailaccount landet.

nimm mal den:
https://mail-tester.com/
klar der kann jetzt nicht alles und jeden prüfen aber damit kommst du eigentlich schon ganz weit. Kann natürlich sein das All-Inkl selber auch Blacklistet, vlt haben die aber auch eine Abfrage das weiß ich aber nicht

Oder https://mxtoolbox.com

Greetings, C.

Naja, aber das ist bei mir ja der Fall. Die Mail geht über den Postfix-Mailserver des virtuellen Servers raus. All-Inkl ist einfach der Mail-Empfänger.
Ah, OK.
Das ist natürlich „anders“ …

Ja, das ist ja sehr sinnvoll. Ich konnte unter dem Zeitdruck jetzt bislang nicht überprüfen, ob das auf meinem virtuellen Server auch so ist, gehe aber eigentlich davon aus. Nur eine explizite Einstellung in Plesk gibt es dafür leider nicht, da müsste ich mich erst durch die Postfix-Konfigurationsdateien wühlen.
Yep, so ist es.

Der Empfänger sendet bei Nichtgefallen einen Bounce zurück. Der Absender versucht es dann eine gewisse Zeit erneut. Nicht ungewöhnlich ist ein weiterer Zustellversuch, täglich, drei Tage lang. Danach wird die Mail als nicht zustellbar deklariert.
Dieses Verhalten ist absolut zeitgemäß.
Wie was wo bei Postfix landet weiss ich nicht.
Vielleicht hat der Supporter dich missverstanden und meinte, die Mails würden permanent erneut verschickt.
Also: Unzustellbar-Nachricht ja, kurzzeitig Retry ist aber erlaubt.
Vielleicht mochte er dich auch einfach nicht und wollte die Sperre deswegen nicht auflösen

Zu all-inkl: ich bin letztes Jahr nach besagten 20 Jahren zu netcup gewechselt und wünsche mir den all-inkl-Support zurück.

Und warum wechselst Du dann nicht zurück ??

Greetings, C.

Ja, eben.
Ein bisschen hatte ich den Eindruck …
Ach, Du bist das, der an allem Schuld ist …

Ein ganz grosser Plusspunkt bei netcup ist, man kann dort auf deren vServern (nicht Lite) und vor allem auf den virtualisierten root Servern sein eigenes Linux System installieren. Das habe ich so in der Art sonst noch nicht gefunden, normalerweise kann man immer nur eine Auswahl aus vordefinierten Images mit unterschiedlichen Distributionen starten, kann aber keine eigenen Distributionen in der virtuellen Maschine installieren.

@Weia
Kurze Frage zu deinen virtuellen Servern, mit welchem Account wird denn da verschickt? Ist dort SPF, DKIM, or DMARC sauber eingerichtet? Sind die Email Adressen in der Whitelist bei ALL-INKL eingetragen?

Zu der öfter erwähnten Whitelist: Ein 451 mit „suspicious sending pattern“ kommt m.W. bevor der Inhalt überhaupt angenommen wird. Eine Whitelist im KAS wirkt auf den Spamfilter, der eine bereits angenommene Mail bewertet, und wäre damit ein Schritt zu spät.

Nix davon, und der Absender der meisten (nicht aller) Mails ist root. Das war alles quick and dirty konfiguriert und es hätte mich nicht gewundert, wenn es deshalb Probleme gegeben hätte. Aber das war ja bislang nicht der Fall und ist es laut All-Inkl auch jetzt nicht, sondern es ist ausschließlich die Häufigkeit der Mails – die sich ja aber ihrerseits nur der Zurückweisung mit obiger Fehlermeldung verdankt, also irgendwie ein Henne- und Ei-Problem.

Eventuell hat All-Inkl. aber nicht einfach nur das Spam-Filter-Verhalten geändert sondern forciert (nun endlich) auch korrekt konfiguriertes SPF und DKIM (und optional auch noch DMARC)?

Weiter oben hatte das ja auch schon jemand erwähnt, es ist aber eventuell untergegangen?

Weia: Also falls Du SPF und DKIM konfigurieren kannst auf dem sendenden Server, würde ich das auf alle Fälle tun, denn das erhöht die Reputation dieses Servers gewaltig.

Und ein shared VPS ist es ja nicht wenn ich Dich richtig verstanden habe, da können also keine anderen Hosts auf der selben IP das wieder versauen?

Nein, der Support ausdrücklich gesagt, dass die Sperrung nicht daran liegt.
Hat sich jetzt alles erledigt, ich habe das Wochenende genutzt, um alles superkorrekt umzukonfigurieren. Der Server sendet jetzt von seiner eigenen Domain aus, mit SPF, DKIM und DMARC, statt von einer Domain aus, die ihm gar nicht gehört, und auch nicht von root aus. Das hat nur einen Rattenschwanz von Änderungen an anderer Stelle nach sich gezogen, weil diverse Automatismen, die vom Empfang dieser Emails ausgelöst werden, aus historischen Gründen hardcodiert auf die alte Absenderadresse waren und ich jahrelang die völlig ätzende Kärrnerarbeit vor mir hergeschoben habe, das alles anzupassen.
Richtig, das kann nicht passieren.

Okay, wenn man das benötigt, kann ich es komplett nachvollziehen !

In Plesk (vielleicht je nach Version unterschiedlich?) gibt es unter "Tools & Einstellungen > E-Mail" den Punkt "E-Mail-Warteschlange". Da kann man ggf. Mail einzeln löschen.

Ah, gut zu wissen – danke für den Hinweis!