Posts by jni

    von [netcup] Felix P. mehrfach erwähnt, dass ein Guthabensystem für das CCP in Entwicklung ist

    Habe erst letzte Woche den Support darauf angesprochen:

    Code
    1. Es tut uns leid, die Möglichkeit, Konten mit Guthaben bei netcup zu führen ist bis dato noch nicht umgesetzt.

    Es geht hier meiner Einschätzung nach um die Verrechnung von Guthaben aus gekündigten, aber vorausbezahlten Produkten, und Zahlungen aus dem Partner Programm, kann mir nicht vorstellen, dass damit das gemeint war:

    Ich möchte kein Guthabensystem. Da muss ich dann ja ständig draufbuchen.

    Zumindest früher war es so, dass sie bei so großen Versionssprüngen empfohlen hatten, erst innerhalb der Major (bei Dir also 15) auf die letzte Verison upzudaten und dann Schritt für Schritt von Major zu Major (also zu 16 letzte Release, dann zu 17 letzte Release usw.), weil es ansonsten zu Problemen kommen kann. Ich könnte mir gut vorstellen, dass die 19 sich nicht mehr darum kümmert, was im 15er Datenmodell noch anzupassen ist, damit es in 16 lief. Deshalb habe ich auch immer die Updates, wenn sie einen Major-Sprung enthielten, auf der Konsole und nicht mit dem Web-Updater gemacht.


    Also ich habe jetzt meine 16er nextcloud vom 1&1 Webhosting zu netcup Webhosting übersiedelt und es läuft hier auch nicht schlechter also zuvor. Update zu 17 werde ich im Laufe des Tages machen, dann wieder einen Tag laufen lassen und Probleme beheben und dann Update auf 18. Die 19 ist mir noch etwas zu heiß.


    Habe aber im Rahmen von Tests auch eine 19 frisch installiert und hatte nicht das von Dir beschriebene Problem, dafür aber andere. Mit einem GET auf eine .txt Datei die vermutlich statische Datei meist nur geladen. Man könnte zwar über einen Rewrite doch auch ein Skript dahinter ausführen lassen, aber für eine frisch installierte nextcloud unwahrschenlich. Was mich etwas wundert: meine ist auch in /cloud/ installiert, aber ich habe auch überall nur GET /cloud/... in meinen Logs stehen. Hatte aber auch den Webinstaller statt dem ZIP genutzt sie zu installieren. Kann mir deshalb keinen Reim darauf machen, woher die Zugriffe auf /status.php und /data/htaccesstest.txt kommen.

    Und noch ein Debug-Ergebnis: schickt man mit eingeschalteter Weiterleitung an nicht definierte Adressen eine Mail z.B. user+foo@ und es sind weder user@ noch user+foo@ definiert, wird die Mail an meine catchall zugestellt. Also hier stimmt die lookup order lt. virtual wieder.

    Guter Hinweis. Aber so wie ich das lese, sagt die Doku dann doch etwas anderes, dass primär auch eine finale Adresse mit + möglich wäre und nur, falls dieser Lookup zu keinem Ergebnis führt man auch noch user@domain prüft. Dem ist bei netcup eben nicht so. Wenn ich allein user+foo@ egal als Mailbox, Weiterleitung oder beides definiere, aber user@ nicht definiert habe, landet die Mail nachweislich im Nirvana. Ist mir bei meinen Tests am WE aufgefallen und habe ich gerade nochmals mit neuen Adressen verifiziert. Zumindest das @domain (denke ich mal damit ist das catchall gemeint) sollte falls keine Ziel gefunden wird die Mail erhalten. Insofern könnte es doch ein Bug sein, die Mail muss ja irgendwo landen oder zumindest bounced werden und es könnte daran liegen, dass netcup es eben doch anders implementiert als in der postfix Doku beschrieben. Werde ich weiter verfolgen.

    Der Support hat mir sehr ausführlich geschrieben, dass man hier einem häufig gewünschten Feature der netcup Kunden nachgekommen ist, das sogar im Hostingpanel extra hinzugefügt wurde, da es dort nicht offiziell unterstützt war - Stichwort recipient delimiter in postfix bzw. allgemein auch address tagging. So haben User die Mögichkeit ohne neue Mailadressen anzulegen doch eindeutige Adressen in z.B. Web-Formularen zu verwenden.

    1. Auch wenn viele Kunden das wollten, es in der Oberfläche beim Anlegen von Mailadressen deutlich zu machen (v.a. weil das Delimiter-Symbol nicht + sein muss, sondern der Provider z.B. in postfix frei wählen kann) bzw. zumindest es in der Doku zu erwähnen hätte ich bei einer so expliziten Änderung des Hostingpanels erwartet. Aber was nicht ist kann ja noch werden.
    2. Ich habe jetzt noch keine Antwort auf meine Rückfrage, ob die Verwendung des + in einer Alias Adresse tatsächlich nicht als recipient delimiter interpretiert wird sonder erst in die Hauptadresse umgeschrieben wird und somit auch eine valide Lösung ist.
    3. Die vom Support vorgeschlagene Lösung war das Verhalten über das recipient delimiter Feature und einer Mailbox mit Sieve-Filtern zu lösen, also die Mailbox für den Teil vor dem + einrichten (anna) und dann in der Mailbox die eigentlich an anna+martin geschickten Mails auch noch an martin weiterzuschicken (redirect). Der Haken für mich: anna und martin bräuchten eigentlich nur eine Weiterleitung auf ihre Stamm-Mailbox statt einer weiteren hier, aber ohne Mailbox auch keine Sieve-Filter. Dann eben anna am besten gleich alles über Sieve-Filter abhandeln...

    Ich habe mir webmail.domain.tld in meinem Webhosting als Subdomain eingetragen und im dazugehörigen Stammverzeichnis dann angelegt:

    Code: .htaccess
    1. <IfModule mod_rewrite.c>
    2.   RewriteEngine on
    3.   RewriteRule ^(.*) https://webmail01.netcup.net/$1 [R=301,L]
    4. </IfModule>

    Mir ist in den 90ern alles mögliche über den Weg gelaufen, das jemand anders installiert und ich dann administriert habe (Slackware, Debian, SuSE, Gentoo). Seit ein paar Jahren RHEL und um sich nicht ständig umgewöhnen zu müssen seit drei Jahren deshalb privat CentOS. Bin gerade dabei den letzte Debian Vserver auszumustern.

    Danke Felix, habe mittlerweile eine sehr kompetente Antwort erhalten. Frage mich nur, warum so eine dem Standard nicht entsprechende und in netcup lt. Support explizit veränderte andere Interpretation von Mailadressen mit + im localpart nicht in der Doku oder sogar in Hostingpanel direkt in der Oberfläche erwähnt ist und dann auch noch der Support ein Woche benötigt, mir das zu erklären. Wenn man schon so einen Eingriff macht, dann sollte man auch deutlich darauf hinweisen. Scheint ja, dass es nur relativ weit oben in der Eskalations-Ebene bzw. erst nach genauer Prüfung bekannt war, was da schief lief. Wäre es dokumentiert, bräuchte man keinen Support oder der bereits der 1st Level Support wüsste davon.

    Um DNS als Problem auszuschließen setzte ich mir immer einen lokalen hosts Eintrag um zu prüfen ob das Setup des Servers passt, zumindest bis ich mir sicher bin, dass alle DNS Einträge überall neu sind. Und ja, das mit den Caches im Browser sollte man noch wissen und beachten, hast Du aber ja schon. Wenn Du dann immer noch die Seite siehst, dann zeigt die vhost Definition für domain.shop tatsächlich auf diese gepackt Seite.

    Wie man unter "Mail Weiterleitungen funktionieren nicht" lesen kann, scheint auch + als Teil des localparts in Plex davon betroffen. Und ebenso, dass Plex sogar drei Kategorien von unterschiedlich gehandhabten Zeichen in localparts hat.

    • Die primäre Mailadresse (kein % im localpart möglich und ein + und folgender Teil wird sofern es den Teil vor dem + auch allein gibt nicht als eigenständige Adresse sondern als Filter der eigenständigen Adresse interpretiert),
    • die Weiterleitungsadressen (keine Adresse mit % möglich)
    • die E-Mail-Aliase für eine Adresse (kein % im localpart möglich, aber Aliase mit + werden wirklich an diese primäre Mailadresse zugestellt)

    Works as intended

    Ach je, wenn man von einem System umzieht und hatte dort anna+martin, das man als kompletten localpart interpretiert bekommen hat (da gab es anna allein auch und trotzdem hat anna+martin dahin nicht zugestellt), dann ist das gar nicht "intended" ;( Das Problem war also nicht, dass die Weiterleitungsadresse an anna+martin gind und der Workaround, dass man nun die Adressen von Anna und Martin einzeln als Weiterleitungsziele angegeben hat, sondern dass die Adresse selbst von extern benutzt wurde und nicht mehr an ihr komplettes Ziel kam, sondern nur bei anna ankam.


    Der Workaround dafür war, dass als Email-Adresse nun annamartin (gab es auf dem alten System nicht) eingerichtet wurde und unter dieser der Alias anna+martin. Interessant ist, dass es in diesem Fall dann nicht als "Filter" für anna interpretiert wird sondern es beim Ziel Hauptadresse landet. In den Headern sieht es dann so aus:

    Code
    1. X-Original-To: anna+martin@domain.tld
    2. Delivered-To: annamartin@domain.tld

    Wollte gerade noch was hinzufügen, evlt. hilft es anderen: hatte auch noch ein Problem mit


    Temporary directory /var/www/vhosts/hosting***.***.netcup.net/***.***.de/tmp is not present or writable


    Der Installer hatte irgendwie kein /tmp Unterverzeichnis angelegt, obwohl das sein Default wäre. Ich habe es dann durch das Umkonfigurieren (Hinzufügen) in config/config.php

    'tempdirectory' => '/tmp',


    selbst geregelt.

    Sorry, aber keiner redet hier von Forwarding und ich verwechsle auch nichts. Wenn Du Dich wirklich an einzelnen Wort so schön aufhängen kannst, dann schreib doch dem Autor des zitierten Artikels. Der hat es "Forwarding-Problem" genannt, sorry für die vergessenen Quotes.


    Schon mal .forward benutzt? Oder /etc/aliases? Da werden keine ursprünglichen Mails als Anhang angehängt, trotzdem heißt es .forward. Was Du meinst ist allein der Sprachjargon der MUA Welt. Und selbst die hängen Forwards nicht immer als Anhang an, sondern es gibt auch Inline Forwarding oder in meinem sogar ein Redirect, was dem Relaying entspricht:


    pasted-from-clipboard.png


    Wir reden hier alle ausschließlich von Relaying, auch im Beispiel. Ich verändere nichts am Inhalt der eigentlichen Nachricht. Wenn Du jetzt immer noch das Haar in der Suppe suchst, dann packt eben die Poststelle den Brief nicht aus, sondern nimmt ihn so wie er ist und packt ihn in einen neuen zusätzlichen Umschlag und schickt in weiter. Das wirst Du jetzt wieder als Attachment sehen, aber ein Attachment ist bei Email eine Inhalts-Aufteilung (Content-Type: multipart/...). Die Umschläge sind ganz außerhalb des Content.


    Wenn auch das nicht zählt und Du unbedingt darauf bestehst, dass man Relaying an der unveränderten Email erkennt: auch Relaying verändert eine Email - schon mal die Header nach dem Relaying angesehen?

    Ich ziehe gerade meine nextcloud (3 GB files, 16 MB mysql dump) in ein Webhosting 2000 SE de a1 um, dauert aber noch. Bin gespannt, ob das eine schlechte Entscheidung wie Homwer meint. Da ich in der alten Installation bzgl. Dateirechten noch hardened habe und dort aber die Laufzeitumgebung eine andere war, musste ich erst mal schauen, wie es grundsätzlich nun bei netcup ist und wie ich es konvertieren muss. Lange Rede, kurzer Sinn, habe mir ein zweites Webhosting 1000 besorgt und dort mal über das Web Installer Skript eine frische nextcloud installiert. Ich habe dabei

    • mysql statt sqllite konfiguriert: dazu musste ich eine Datenbank erstellen/vorbereiten
    • das data Verzeichnis außerhalb des Stammverzeichnisses gelegt: dazu musst man in den PHP settings das open_basedir angepasst werden

    Alles erfolgreich geschafft, sie läuft. Kann also nicht unbedingt das Fehlverhalten nachvollziehen. Hast Du error_log und nextcloud.log geprüft. Bei mir waren dort hilfreiche Infos.

    mainziman Wenn ich Dich richtig verstehe geht es Dir also v.a. darum zu argumentieren, dass man grundsätzlich keine Weiterleitung nach extern verwenden sollte und dass man für Erklärungen keine Analogien aus anderen Technologien verwenden sollte, wenn sie nicht die gleiche ist. Beide Einschätzungen kann ich nicht teilen.


    Zum Punkt anschauliche Erklärung von Dingen: Es ging ja in Deiner ersten Erklärung, in der Du von max@max/moritz@moritz/moritz@gmail geschrieben hast um SPF. Alle anderen danach haben sich weiterhin nur auf SPF bezogen und man wunderte sich, warum es trotz -all geht. Dann schreibe ich einen Beitrag und versuche anschaulich SRS und warum im From immer noch der original Absender steht zu erklären, nachdem den Thread hier wohl seit Wochen keiner mehr interessiert und weil ich zufällig bei der Suche nach Probleme mit Weiterleitungen darüber gestolpert bin. Sollen die anderen urteilen, ob sie jetzt die offenen Fragen anhand meiner Analogie verstanden haben, oder ich sie hätten lieber stattdessen auf die technische Spezifikation verweisen sollen, weil man Deiner Meinung nach smail und email am besten nur vollkommen getrennt voneinander betrachten sollte.


    ich würde hier meinen, dass etwas versucht wird, was eigentlich nicht vorgesehen ist;

    Du meinst, weil man es nicht für externe Adressen nutzen sollte? Diese Meinung teile ich nicht. Wenn Weiterleitung nur intern sein soll, dann sollte netcup wie es auch andere Vorredner geschrieben haben darauf hinweisen. Ich verstehe zwar all Deine Argumente, warum Du denkst, dass man Weiterleitungen nicht nehmen sollte, weil sie eben in der heutigen Welt schwierig im Handling sind. Aber Du liegst falsch mit der Annahme, dass sie eben nicht dafür vorgesehen sind. Vielleicht liest Du Dich mal ein. Da wirst Du auf Seite 5 lesen "bleibt die Weiterleitung ein unverzichtbares Feature von E-Mail". Auf Seite 4 steht das eigentliche Problem bzgl. DKIM und S/MIME - nicht das Weiterleiten an sich, sondern dass die MTAs auf dem Weg seit 25 Jahren die Mails beim Weiterleiten eben nicht nur weiterleiten, sondern auch im Inhalt verändern. Da DKIM und S/MIME aber den original Inhalt signiert haben und jede noch so minimale Änderung diese Signatur bricht, kommt es zu dem Problem.


    Du wirst sehen, dass man für sämtliche im Laufe der Jahre eingeführte Techniken, um Email vertrauensvoller zu machen, immer bemüht war, auch Lösungen für das Forwarding-Problem zu finden, weil Weiterleiten eben ein essentielles Feature ist.

    Bug für Weiterleitungen im Webhosting 2000 SE de a1 gefunden: hat man eine Mailadresse abc@example.com und eine weitere Mailadresse, die genauso beginnt und deren erstes Zeichen danach ein + ist, also z.B. abc+efg@example.com, dann wird zwar im Mail Header vermerkt


    X-Original-To: abc+efg@example.com

    Delivered-To: abc+efg@example.com


    aber tatsächlich wird die Mail an die Weiterleitung von abc@examplecom geschickt. Ich habe weiter Spielarten ausprobiert...


    1. Wählt man als Email-Adresse abcefg@example.com und definiert einen Alias abc+efg@example.com, dann funktioniert es korrekt.

    2. Es spielt keine Rolle, ob abc+efg@example.com eine Weiterleitung oder eine Mailbox ist, in beiden Fällen landet die Mail bei abc@example.com

    3. Der . (abc.efg) oder ein - (abc-efg) oder ein _ (abc_efg) als erstes Zeichen nach dem gemeinsame Teil des local parts führen zu einem korrekt zuordnendem Verhalten.


    Ich behelfe mir jetzt mal vorerst mit abcefg und abc-efg als Alias, aber das ist ein handfester Bug, der gehört eigentlich behoben.

    Ich habe nachweislich Probleme mit einer Weiterleitung in meinem Webhosting 2000, Mails werden nicht an eine von zwei Zieladressen weitergeleitet, entdeckt am Sonntag. Montag Morgen habe ich den Support kontaktiert inkl. Message-Ids und in drei Tagen noch gar keine Rückmeldung erhalten. Da das System auch keine Kopie der eigenen Support-Anfrage zustellt, frage ich mich jetzt schon, ob die Anfrage überhaupt eingegangen ist. Andere weniger technisch anspruchsvolle Support-Anfrage wurde innerhalb kürzester Zeit beantwortet. Sollte ich nochmals schreiben?

    tab Danke für den Hinweis/die Idee, daran habe ich gar nicht gedacht, dass der Parser der Weiterleitungsadresse ein Problem haben könnte. Ist es aber nicht. Meine Weiterleitung heißt anna+martin@meinenetcupdomain.tld und die leitet an zwei Adressen weiter: anna.meinenetcupdomain@mailanbieter.tld und martin.meinenetcupdomain@mailanbieter.tld. Meine andere Weiterleitung ist verteilerliste@meinenetcupdomain.tld und die leitet an viele plus auch anna+martin@meinenetcupdomain.tld weiter. Weder Mails direkt an anna+martin@meinenetcupdomain.tld noch an verteilerliste@meinenetcupdomain.tld kommen bei martin.meinenetcupdomain@mailanbieter.tld an, nur bei anna.meinenetcupdomain@mailanbieter.tld. Eine andere verteilerliste2@meinenetcupdomain.tld sendet an ich@firma.tld und martin.meinenetcupdomain@mailanbieter.tld und hier kommen die Mails an beide Adressen an. Somit hat sich die Vermutung, dass nur der hinter Teil hinter dem + als localpart interpretiert wird nicht bewahrheitet.


    mainziman Ich verstehe ja, dass Du sagen willst, Weiterleitungen sind grundsätzlich ein schwieriges Thema, aber deshalb zu analysieren, wo ein grundsätzlicher smail/email Vergleich hinkt, ist doch nur das Haar in der Suppe zu suchen. Mein Erklärung sagt ja nicht, dass smail und email alles gleich machen, ich habe explizit eine Analogie aus der smail Welt gewählt, um die Funktionsweise von SRS und Weiterleitungen anschaulich zu erklären. Warum ich in diesem Thread überhaupt gelandet bin hat ja ganz andere Gründe, weil ich eben ein sich wohl wiederholendes Problem bzgl. Weiterleitungen bei netcup sehe, das nicht mit den grundsätzlichen Problemen von Weiterleitungen zu tun hat.


    Da ich selbst einen Weiterleitungs-Dienst für ein Forschungsnetzwerk betreibe, weiß ich sehr wohl, wovon Du schreibst. Und auch die neben meinem internen gegen Bezahlung gekauften Mailingslisten-Dienste für Externe sind nicht in der Lage, ohne Probleme an alle weiterzuleiten. Ich war schon im Netz unterwegs, da war das hier eine Newsgruppe und das Wettrüsten zwischen Missbrauch und sinnvoller, geschützter Nutzung bei Emails noch in den Kinderschuhen. Da konnte man mailman noch ohne Probleme auf jedem x-beliebigen Rechner am Internet betreiben, weil es keine Prüfung der Absender-Adresse gab. Es war wie in Deinem DP-Bsp. möglich einfach Djibouti als Absender zu verwenden.


    Und bzgl. Briefmarke: um im Internet Post verteilen zu lassen muss ich auch Wegezoll bezahlen. In Zeiten von UUCP war die Briefmarke erst dann gelöst, wenn man sich mit dem Internet kostenpflichtig verbunden hat. Und in Zeiten von Mailboxen gab es umgekehrt mehrere Anbieter für digitale Post und man musste die Briefmarke/Wegzoll richtig wählen, dass eine Nachricht zum richtigen Adressat kam. Aber jetzt zwischen den OSI Schichten zu springen wirst Du vermutlich auch nicht passend finden. Übrigens, in Zeiten meiner Jugend (auch wenn ich jetzt nicht super alt bin) mit FidoNet oder Maus oder Z-Netz war es übrigens umgekehrt und die DP der einzige nicht digitale Postverteiler in meinem Ort.


    Vergleiche/Analogien um etwas anschaulich erklären zu können lassen sich viele finden, aber ein Apfel (smail) ist ein Apfel und eine Birne (email) ist eben kein Apfel und man wird sagen können, "aber in dem und dem Punkt hinkt der Vergleich".

    Da Du wärend meines Tippens schon neue Infos geliefert hast: ich kenne i-MSCP nicht und bin leider raus. Auf dieser hohen Ebene der Abstraktion werde ich nicht helfen können. Ich habe mich für jeden Teilbereich des Umzugs mit den Vor- und Nachbedingungen auseinandergesetzt, teilweise habe ich sogar ein zweites günstiges Webhosting 1000 noch gekauft, um Dinge ausprobieren zu können, wie netcup sich entsprechend verhält.