Eine eigene Roundcube-Instanz installieren auf dem Webhosting, ich meine anders wird es nicht gehen. Zumindest nicht mit den Bordmitteln des Webhostings. Ansonsten kannst du nur hoffen, dass netcup das irgendwann ermöglicht, es ist allerdings schon so, seit ich die netcup Webhostings kenne. Mich stört es nicht, ich nutze Webmail selten. Und wenn, dann interessiert es mich nicht, was ich da als URL eingeben muss und was dann in der Adresszeile angezeigt wird. Wenn ich das wirklich nutzen muss, dann habe ich andere Prioritäten. Und wenn man webmail01.netcup.net aufruft, dann ist die Verbindung ja auch sicher.
Beiträge von tab
-
-
Mailserver ist schon mit einer festen IP und eingetragenem PTR problematisch genug. Aber bei einer dynamischen IP min DynDNS müsste dein Internet-Provider jedes Mal, wenn er dir eine andere IP zuweist, automatisch den PTR für diese IP auf den von dir gewünschten Wert setzen. Dass das einer macht, kann ich mir nur schwer vorstellen, mag aber sein.
Was durchaus funktionieren dürfte, ist der Empfang von E-Mails. Versand wird ohne PTR gelinde gesagt fast unmöglich sein. Rein technisch versenden kannst du schon, aber dass die E-Mail vom Mailserver des Empfängers auch akzeptiert wird ist eher unwahrscheinlich. Also bei meinem Mailserver wird sowas automatisch abgewiesen und beim zweiten Versuch ist die IP im Jail von fail2ban.
Du wirst auch nie eine gute Reputation für deinen Server bekommen, der Aufbau der Reputation kostet viel Zeit und Aufwand. Die Reputation hängt ja auch an der IP des Mailservers und nicht an der Domain oder dem Hostnamen. Und du weiss nicht mal, was der Vorbesitzer der IP damit so alles getrieben hat und ob er sie auf x Blacklists gebracht hat. Bei großen Mailanbietern werden Subnetze für dynamisch zugewiesene IPs oft von vornherein komplett geblockt, selbst wenn sie einen passenden PTR mitbringen würden. Chat, Jitsi und Co kämpfen halt auch nicht mit 90+% Spam weltweit wie bei E-Mail. Da ist die IP irrelevant.
-
Und ich wundere mich schon, wo die ganzen VPS 100, VPS 50 und VPS 20 früherer Produktgenerationen wohl geblieben sind.
-
Webmailserver01 ist jedenfalls die oben geschriebene IP, die ist auch - soweit ich weiss - für alle Webhostings die selbe.
Ein nslookup auf webmail01.netcup.net ergibt denn auch die folgenden IP-Adressen:
CodeName: webmail01.netcup.net Address: 46.38.249.153 Name: webmail01.netcup.net Address: 2a03:4000:0:25f::10
Insofern alles gut. Ich kann mich auch mit einer meiner netcup Mailadressen problemlos dort anmelden mit den normalen Zugangsdaten (Benutzer und Passwort), die ich in anderen Clients ebenso erfolgreich verwende.
Allerdings ...
Gelegentlich dauert es ein paar Tage nach der Einrichtung für Webmail , bis die Anmeldung am Webmailserver funktioniert. Da du allerdings das Ticket schon vor einer Woche geschrieben hast, sollte das nicht die Ursache sein. Da kam dann immer eineMeldung wie "Verbindung zum Speicherserver fehlgeschlagen". Nach ein oder zwei Tagen warten hat es dann funktioniert.
Ich will ja nicht hoffen, dass das ein netcup-Mitarbeiter manuell freischalten muss, sonst würde mich derzeit mehr als eine Woche Wartezeit nicht verwundern. .
-
ja mit RFC1918, das musst aber dann auch entsprechend (parallel) aufbauen;
ja weil ein ARM-vCore auch was anderes ist als ein x86-vCore; und Du um halbwegs leistungsäquivalent zu sein auch mehr ARM-vCores brauchst als x86-vCores;
das sollte halt nicht hinwegtäuschen;
wenn ma den kleinsten der Minis hernimmt, den Pico:
der hat nur einen x86-vCore;
hat 1 GByte RAM,
und die 30 GByte HDD/SSD - welche wahrscheinlich dem Umstand geschuldet ist, dass ma mit 5 bis 10 GByte meist nichts mehr anfangen kann;
den könntest halt mal schnell wo 'reinflicken' und hast einen kleinen Deckungsbeitrag f. den entsprechenden Host;
bei den anderen beiden der Minis wird es schon schwieriger: mehr als nur ein vCore und einige GByte RAM, und die doch größere HDD/SSD;
würdest des mit den ARMs veranstalten würde es ungemein schwieriger, weilst ja gleich mehr als einen vCore brauchst;
We bereits geschrieben: Ist mir klar, dass ein ARM-Core nicht die selbe Leistung bringt wie ein x86. Ist mir auch klar, dass man für Verwendungszwecke wie von dir beschrieben mit einem x86 besser fährt bzw weniger Cores braucht oder halt mit einem klarkommt und mit einem ARM-Core nicht.
Aber die Mehrzahl von Einsatzfällen für einen pico bei mir ist so, dass auch ein einzelner, armseliger ARM-vCore - um es vorsichtig auszudrücken - definitiv nicht an seine Leistungsgrenzen kommen würde. Wenn es also so sein sollte, dass der derzeitige pico sich für netcup nicht rechnet und entweder teurer werden muss oder wegen der IPv4, die nun mal ein knappes und teurer werdendes Gut ist, aus dem Sortiment genommen werden muss, dann wäre ein pico-ARM oder auch ein pico-IPv6only-ARM für viele Anwendungen durchaus ausreichend und wahrscheinlich immer noch ein nachgefragtes Produkt.
Je nachdem wo es klemmt, könnte man auch einen pico-IPv6only-x86 anbieten (im IPv4s nicht für so kleine Kisten zu verbrauchen) oder einen pico-ARM mit IPv4, aber einem schwächeren, im Einkauf günstigeren und weniger Energie verbrauchenden ARM vCore (um ein wenig mehr Marge zu haben). Was man dann mit dem derzeitigen pico macht, Preiserhöhung, aus dem Sortiment nehmen oder was auch immer, muss man dann eben irgendwann entscheiden. Im Moment mag es noch an der derzeit großen Nachfrage nach ARM-Prozessoren scheitern, das wird sich aber in einer Marktwirtschaft sicher irgendwann entspannen.
Die derzeitige Situation ist jedenfalls eine ungünstige, obwohl bisher wohl immer noch die Nachfrage aus den Vorratslagern der Kunden bedient werden kann. Allzu lange hat wohl bisher niemand, der einen pico gesucht hat, lange auf einen pico warten müssen.
-
od. auch nicht; ein ARM-Core ist was anderes als ein x86-Core
https://www.elektronikpraxis.d…32cd605f35d17648310a6ca7/
(Hauptunterschied: RISC vs. CISC)
Ich sage ja nicht, dass das an der Leistung nichts ändern würde. Aber sicher am Preis, sieht man ja bei den größeren ARM VPS, die sind günstiger, obwohl sie mehr vCores haben. Und wenn ich jetzt sehe, wie sich mein Piko langweilt, dann reicht mir auch die halbe Prozessorleistung (davon) locker für die meisten Zwecke.
Wie ist das eigentlich mit der IPv4? An den lokalen Netzen sollte sich dadurch nichts ändern, die könnten auch IPv4 sein, ebenso das Cloud vLAN(?). Es fehlt doch eigentlich nur die globale IPv4. Ich muss mir mal so eine IPv6 only Kiste anschauen, gibts ja bei einigen Anbietern.
-
Habe nichts davon gehört in letzter Zeit. Vielleicht lohnen die sich nicht. Verbraten eine IPv4 und ein IPv6 /64 und einen Teil eines x86 Cores/Threads, allerdings einen kleineren Teil davon als ein VPS x86 pro vCore. Ich könnte mir vorstellen besonders die IPv4 tut weh. Vielleicht bastelt man ja an einer reinen IPv6 Version, wäre ich an netcups Stelle, würde ich das machen und vielleicht gleich noch auf ARM-Basis. Dann sollte sich das eher rechnen.
-
Nein, sagt jedenfalls die FAQ dort so.
-
Wenn die Mail zu einem netcup Webhosting gehört (inklusiv oder zusätzlich) dann sollte Mail - auch von der Nextcloud - im Idealfall über den zuständigen SMTP-Server verschickt werden. Dass hier von Mail-App nach DKIM gefragt wird, deutet für mich aber nicht darauf hin, dass die Einstellungen so sind. Oder falls doch, dass die Mail-App Daten abfragt, die sie gar nicht benötigt.
-
Das klingt nach einem Fall für den Support, wenn du tatsächlich in den PHP-Einstellungen nichts anderes zur Auswahl hast als PHP 7.2. Notfalls sogar für den Notfallsupport.
-
- Projekte entschlacken.
- Einfacher machen, Ziel klarer definieren.
- Netcup überzeugen Nested KVM auf dedicated CPU‘s zu aktivieren.
- Glücklich sein
Also ich will auch wieder - wie jedes Jahr - die Bestände an Webhostings, Server und Domains auf das Notwendige reduzieren. Gelingen wird es wie immer nicht, aber immerhin habe ich schon an Silvester einen Anfang gemacht und ein Webhosting gekündigt (bei einem Mitbewerber), das um 20% teurer werden sollte wegen Anpassung an die Marktentwicklung. Ich finde das Webhosting zwar nicht schlecht, aber die Bedienung wurde nach jahrelanger Entwicklung kürzlich so verschlimmbessert, dass manches derzeit gar nicht mehr vernünftig nutzbar ist.
Die Website die da läuft kommt auch prima mit meinem Webhosting 4000 klar, das kostet nicht mal ein Drittel von dem, was das andere Webhosting ab Februar kosten sollte. Eine 1:1 Kopie der Website läuft darauf seit heute bereits, aber halt noch unter der falschen Domain. Und das Webhosting 4000 hat sonst eh nichts zu tun. Gefühlt läuft die Kopie eher schneller als die Originalsite. So flott hatte ich das WH 4000 gar nicht in Erinnerung, muss ich morgen direkt mal ein paar Vergleichsmessungen machen.
Soviel also zum Thema Marktanpassung. Außerdem hatte ich nach den Pleiten und Pannen der letzten zwei Jahre eh schon über eine Kündigung nachgedacht. Das tolle neue Kundenpanel und die Preiserhöhung waren nur die letzten Tropfen, die das Fass endgültig zum Überlaufen gebracht haben.
-
Ergibt sich aus den Empfängeradressen der zugestellte/nicht zugestellten Mails irgendeine Systematik? Also z.B. bei gmail, GMX, Web.de und kleineren Hostern kommt alles an, bei hotmail.de, live.de, outlook.de und wie sie alle heissen (MS) nichts?
-
Geht mir gar nicht so sehr um das Veröffentlichen der Daten, mich stört der Scan an sich, der Missbrauch von Ressoucen. Nein, meine so gescannten Server haben genug Ressourcen, aber das können die vorher nicht wissen. Hinterher vielleicht, aber dann hätte der Server ein ernsthaftes Sicherheitsproblem. Die zu blocken ist nie endender Aufwand, die wechseln die IPs öfter mal und sind in unterschiedlichen Subnetzen unterwegs. Also alles was über irgendwelche Blocklisten oder fail2ban rausgeht pure Arbeitsbeschaffungsmaßnahme.
Ich bin da diesmal nur draufgestossen, weil ich derzeit noch meine Resolver Logs schreiben lasse und diese überwache. Da steht dann 20x die selbe IP, für die der PTR vom selben Server abgefragt wurde innerhalb kurzer Zeit.
Beim entsprechenden Server finde ich dann in den Logs, dass sich die IP 20 Mal hintereinander mit dem smtpd verbunden hat und sich dann ohne Aktion wieder verabschiedet. Teils mit irgendwelchen Fehlern in der TLS-Library oder mit fehlerhaften Anfragen.
Ein andermal finde ich irgendeine IP im Log des Backup-Resolvers, der nur gefragt wird, wenn der erste nicht rechtzeitig eine Antwort liefert oder eben SERVFAIL. Da weiss ich dann gleich, mit der IP muss was komisch sein, sonst hätte der die Anfrage nicht bekommen. Da sie von Censys ist, kann man davon ausgehen, dass das Reverse DNS nicht versehentlich fehlschlägt. Also absichtlich präpariert, eventuell um herauszufinden, welche Resolver der Server benutzt. Die entsprechenden IPs der Resolver bekommen sie ja schön der Reihe nach geliefert, weil alle SERVFAIL liefern bei der Abfrage des PTR. Die IPs ist auch auf diversen DNS-Blocklisten gelistet. Bringt aber leider herzlich wenig in dem Fall.
Jetzt könnte man sagen, gut dass es Shodan, Censys & Co gibt. Aber immer, wenn ich sowas finde ist es garantiert einer dieser Scanner, nie irgendein unbekannter Hacker. Jeden Tag mehrmals die selben "Tests". Der Ressourcenverbauch hält sich freilich auch in Grenzen, die Abfrage wird ja vom Resolver nur einmal wirklich rekursiv gemacht, die restlichen 19 Antworten kommen aus dem Cache. Und auch bei der einen rekursiven Abfrage wird ja der entsprechende Thread nicht blockiert, per UDP jedenfalls nicht.
-
Dass nicht alle Mails ankommen kann unterschiedliche Ursachen haben. Haben die betroffenen User auch mal in ihren Spamordner geschaut? Gerade Microsoft stellt Mails von neuen Absenderadressen meist bestenfalls als Spam zu. Aber das sollten Benutzer von MS-Adressen ja eigentlich wissen. Die entsprechenden Mails als "kein Spam" zu markieren oder in den Posteingang zu verschieben sollte das für die nächste Zeit beheben. Wenn du per SMTP versendest, musst du das auch nicht zwingend über eine Absenderadresse aus deinem Webhosting machen.
- Anzahl der versendeten Mails. Wenn dein Forum sehr viele Mails verschickt, kannst du damit das Limit des netcup Webhostings überschreiten. Für ein sehr großes Forum mit vielen Usern und Benachrichtigungen reicht es eventuell nicht. Ich bin mir nicht sicher, wo genau das Limit derzeit liegt. 100 pro Stunde? Dazu gibt es noch ein tägliches Limit.
- Traditionell war die Zustellbarkeit von Mails aus dem netcup Webhosting nicht besonders gut. Es soll sich aber gebessert haben in letzter Zeit. Wie gut "besser" freilich ist, weiss ich nicht. 100% ist sowieso eher unrealistisch. Das erreicht wohl kaum ein Provider im Shared Webhosting. Es wird immer mal wieder passieren, dass z.B. (und vor allem) Microsoft deine Mails ablehnt. Welche KI nach welchen Kriterien entscheidet, welche IP Subnetze man gerade als Absender ablehnt (MS interne Blockliste), weiss nur Microsoft. Und auch das nur vielleicht.
- Technische Gründe. Passt deine DKIM-Signatur, SPF und DMARC jetzt? Würde ich mal überprüfen mit einem geeigneten Tool. Normalerweise sollte DKIM und SPF bei netcup passen, DMARC wird wohl nicht automatisch gesetzt, könnte nicht schaden das zu tun. Mit den dreien korrekt eingestellt wird es nur noch sehr wenige Mailhoster geben, die deine Mails wegen technischer Gründe ablehnen. Ich habe bei einem anderen Webhoster eine Mailadresse, die nur in Ausnahmefällen mal Zustellbarkeitsprobleme hatte (eigentlich nur einmal, bei wem wohl?). Und da war nur SPF gesetzt, kein DKIM und kein DMARC. Die haben DKIM erst vor kurzem nachgerüstet, als dies Web.de und GMX vor einigen Monaten (völlig unerwartet , jedenfalls für den Webhoster) zwingend voraussetzten.
-
Ja, der Parameter bewirkt ja keine dauerhafte Erhöhung, nur für den einen Aufruf. Wenn du das (-d memory_limit=1024M) also in deinen Aufruf des Nextcloud-Cronjobs (cron.php) einbaust, dann wird der Cronjob mit höherem memory_limit laufen. Die PHP-Info im Control Panel gilt nur für den Webprozess, aber nicht für die Kommandozeile, das sind zwei Paar Stiefel.
Im Webprozess hast du tatsächlich das hohe Limit von 1024 MB voreingestellt, außer du setzt es selbst niedriger. Bis vor einigen Jahren war das auch in der Kommandozeile per Default so, aber es wurde irgendwann geändert auf 128 MB. Braucht man mehr, muss man jetzt halt den Parameter mitgeben. Auch beim Aufruf von occ wird man zur Erhöhung des Limits aufgefordert. Ich glaube der will 512M haben, also wird das wohl auch für den Cronjob reichen.
-
Bestseller Nr. 1: So glaubt mir doch bitte, ich war das nicht alleine
Nein, da hat es schon noch BUD02 dazu gebraucht.
-
Wie haltet ihr es damit auf euren Servern? Censys, Shodan & Co blocken oder sie einfach ignorieren und gewähren lassen?
-
Passiert, wenn überhaupt, doch eh nur zu unserem Besten.
-
Wenn es der Cronjob ist, dann würde ich mal nachprüfen welches memory_limit in der Konsole (also für das PHP-CLI) eingestellt ist. Mir war so, als sei das seit einiger (längerer) Zeit per Default auf 128M eingestellt. Im Zweifelsfall mal beim Cronjob das gewünschte memory_limit mit angeben.
Edit, gerade in einem 4000er getestet
-
Wenn man darauf vertrauen mag ...