Beiträge von m_ueberall

  • Roundcube - multiple identities

    Zitat von ulf8000

    ich denke hier hat netcup den Business Case noch nicht durch-gerechnet: 1 öffentliche netcup Version gegen eine 3-4 stellige Anzahl an Roundcube Parallel-Installationen, die RAM, CPU, Storage, Datenbank Ressourcen verbrauchen, und wo garantiert x Prozent mit irgendwelchen Konfig pitfall laufen... oder Kundensupport benötigen...

    Die kalkulierte Ausnutzung der gebuchten Ressourcen (und die davon abhängige, nicht-starre Überbuchung seitens des Anbieters) wird durch Round­cube-In­stal­la­tio­nen be­stimmt nicht so schnell zerstört. Ähnlich wie bei RS-/VPS-Angeboten gibt es auch beim Webhosting Möglichkeiten, hier re­gu­lierend/dros­selnd ein­zu­grei­fen. Und Kundensupport für selbst installierte Anwendungen durch Netcup gibt es nicht. (Wenn damit stattdessen der Austausch in diesem Kun­den­fo­rum ge­meint war: Eine zunehmende Diskussion über entsprechende Konfigurationen ist hier aus Netcup-Sicht sicherlich auch nicht negativ zu beurteilen.)

  • Client Zertifikat Authentisierung

    Nachtrag: Ich sehe gerade, dass einige Direktiven im oben verlinkten Beispiel nicht im ".htaccess"-Kontext funktionieren. Wenn man so­wie­so mit selbst-sig­nier­ten Zer­ti­fi­ka­ten arbeitet, könnte ggf. folgender Ansatz funktionieren, ohne dass auf die Hinterlegung/Referenz von Zertifikatsdateien zurückgegriffen wird (nicht aus­pro­biert); somit reduziert sich die Prüfung "lediglich" auf eine Übereinstimmung von Feldinhalten (vergleiche diese Tabelle), allerdings vergleichbar mit einer "Stan­dard-Zu­griffs­kon­trol­le" (basic auth) ohne Nutzerinteraktion:

    Code: .htaccess
    SSLVerifyClient require 
SSLVerifyDepth 0
SSLOptions +StrictRequire

Require ssl-verify-client
Require expr %{SSL_CLIENT_I_DN} == "John_Doe_Ltd"
Require expr %{SSL_CLIENT_S_DN} == "John_Doe"
[…]

  • Client Zertifikat Authentisierung

    Zitat von twi

    Ich möchte eine Webseite mit einem Client Zertifikat schützen. Da ich aber nur ein Webhosting habe, bin ich mir nicht sicher ob das überhaupt klappt. Meine Versuche mit .htaccess waren bislang nicht erfolgreich. Hat jemand Erfahrung damit?

    Erfahrung im Webserver-Kontext nicht (weil ich dafür aus historischen Gründen stunnel auf einem RS verwende), aber grundsätzlich sollte das mit Apache2 funktionieren, vgl. die Direktive SSLVerifyClient. Hier findet sich eine kurze Beschreibung zum Ablauf der Installation. Bedingung ist, dass alle referenzierten Direktiven im .htaccess-Kontext ausgewertet werden.

    Ich meine, gelesen zu haben, dass es Webhosting-Anbieter gibt, welche dies explizit verhindern (warum auch immer). Um Konfigurationsfehler auszuschließen, würde ich vorschlagen, dies parallel in einer lokalen virtuellen Maschine (oder einem Linux-Container) auszutesten, wo es funktionieren muss.

  • Das längste Thema

    Zitat von mfnalex

    Das klappt leider auch nicht :( Die Subdomain ist dann einfach "weg".

    Was ist mit

    Apache Configuration
    RewriteEngine on
RewriteCond %{SERVER_PORT} ^443
RewriteCond %{HTTP_HOST} ^(.*)example\.de$ [NC]
RewriteRule $ https://$1example.com%{REQUEST_URI}

    ? Um dies für Port 80 zu erweitern, kann man den Block entsprechend duplizieren.

    EDIT: "\."-Regex-Suffix in Zeile 3 entfernt, damit auch die Hauptdomäne funktioniert.

  • Das längste Thema

    Zitat von ThomasChr

    Aber mal ehrlich: Ich hab nichts gegen leicht bekleidete Frauen, finde es hier aber fehl am Platz.

    Abseits vom Oberflächlichen handelt es sich bei den genannten 3D-Modellen aber über sehr intelligent ausgewählte Stresstests von Gerät und Material mit ei­ni­ger­maßen praktischem Nutzen (insbesondere für Cosplayer, aber auch "alltagstauglich"). Originalität und „Durchdachtheit“ sind tatsächlich die Stärken des vor­ge­nann­ten Kanals, welcher gerade – aber nicht nur – bezüglich 3D-Druck/-Produktion einige interessante Material-/Produkt-Tests und Ideen beinhaltet. Mich selbst in­te­res­siert bei diesen technischen/praktischen Themen dabei weniger das Aussehen der Präsentatorinnen als deren Versiertheit. Aber die Präferenzen sind bekanntlich ver­schieden (wobei Wu sich durchaus ihrer „Außenwirkung“ bewusst ist).

  • Postfix / Netcup Nameserver

    Zitat von shadowman110

    Wenn ich andere Nameserver nehme weiß ich nicht wo ich die DNS records festlege.

    Zitat von Hansjörg

    DNS Server für deinen Server (Rekursive DNS Server) haben nichts mit den DNS Servern für Domains zu tun, die du von Netcup kaufst (Authoritative DNS Server)

    Was Hansjörg sagte – Die DNS-Server, welche in diesem Fall genutzt werden, lassen sich unter Linux in der Datei /etc/resolv.conf festlegen, in der sich eine oder mehrere Zeilen mit "nameserver"-Einträgen finden sollten. Änderungen an dieser Datei werden umgehend bei der nächsten Anfrage durch eine Anwendung wirksam. Diese werden aber ggf. von anderen Hilfswerkzeugen beim Server-/Dienststart überschrieben, siehe beispielsweise hier. (Sollte ent­spre­chend do­ku­men­tiert sein – Als Workaround kann man nach Änderung der Datei diese auch schreibschützen mittels chattr +i /etc/resolv.conf; entfernt wird dieser Schreibschutz analog mit Option -i.)

    Eine Erläuterung zu den Einträgen liefert man resolv.conf auf der Kommandozeile.

  • Postfix / Netcup Nameserver

    Zitat von shadowman110

    Wenn ich die Nameserver auf google ändere, funktioniert alles problemlos

    Kurztests mit 1.1.1.1, 8.8.8.8, 9.9.9.9 und dnscrypt-proxy liefern allesamt einen A-DNS-Eintrag für alt4.gmail-smtp-in.l.google.com. Ergo würde ich dann doch dazu raten, einfach andere DNS-Server zu verwenden. Zumal: So viel schneller sind die Netcup-DNS-Server nicht als Mitbewerber und es gibt auch Net­cup-Kun­den, wel­che ihrerseits dnscrypt-Server für die Allgemeinheit betreiben (aufgrund der Latenz werden diese ggf. bevorzugt verwendet, sofern man sie nicht explizit sperrt).

  • Email wird nicht zugestellt auf meinen Mailserver. Message more than 48 hours on the queue..

    Zitat von friend_of_root

    Die netcup ist der Mailserver. Der Mailserver hat in dem Logfile diese E-Mail oder IP nie gesehen.

    Das mit der IP-Adresse wäre ggf. dadurch erklärbar, dass es bspw. auch lx18mail.hoststar.hosting und lx20mail.hoststar.hosting gibt. Wenn hier also mehrere IP-Adressen zum Empfang und zur Versendung verwendet werden, hilft zunächst nur die Ermittlung aller potenziellen IP-Adressen von hoststar.hosting. Und danach eine Suche nach allen diesen seit Erstellungsdatum der Ursprungs-E-Mail, welche im Zusammenhang mit Fehlermeldungen in den eigenen Logs auftauchen.

    Mögliche Fehlerursachen in diesem Fall aus dem Stegreif:

    • Absender (bei H.) und Empfänger bei Netcup können sich nicht über TLS-Parameter einigen (kann einzelne Knoten eines "Mailserver-Clusters" betreffen, deren Konfiguration abweicht, selbst schon erlebt – deswegen kommen E-Mails ggf. irgendwann an und zu anderen Zeitpunkten lange/gar nicht)
    • Grey­listing hindert Annahme, weil dummerweise jedes Mal ein anderer Absender/eine andere IP-Adresse von lxNNmail beim Netcup-Mailserver sein/ihr Glück versucht (hier hilft nur ein White­listing aller oben ermittelten IP-Adressen); nicht so abwegig, wenn nach erfolglosen Zustellungsversuchen sofort relativ große "Wie­der­ho­lungs­ver­such­ver­zö­ge­run­gen" von einigen Stunden verwendet werden

  • Email wird nicht zugestellt auf meinen Mailserver. Message more than 48 hours on the queue..

    Zitat von friend_of_root
    Received: from 193-154-223-1xx.adsl.highway.telekom.at ([193.154.223.1xx]:21153 helo=[10.0.0.11])
    by lx19.hoststar.hosting with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    Zitat von friend_of_root

    Ich versuche herauszufinden, ob ich so eine Postfix Beschränkung habe, glaube aber dass dem nicht so ist.

    Könnte es auch an dieser Blacklist liegen? Habe es auf https://mxtoolbox.com/ gecheckt.

    Code
    Reason for listing - Your ISP NETCUP-AS netcup GmbH, DE/AS197540 is UCEPROTECT-Level3 listed because of a spamscore of 90.6. See: http://www.uceprotect.net/rblcheck.php?ipr=2.56.96.251

    Die zweite IP-Adresse (von lx19.hoststar.hosting) stammt vom Dienstleister mit dem roten H., die dritte von Netcup, und die erste offensichtlich von der öster­reichi­schen Tele­kom – wie soll sich daraus ein Zusammenhang ergeben (es sei denn, dieselbe dritte IP wurde im ersten Zitat in Zeile 9 gelöscht)? Ist der erste Satz des zweiten Zitats so zu lesen, dass der Mailserver (lx19mail.hoststar.hosting) unter eigener Kontrolle ist? Dann sollte die Beantwortung der Frage, ob eine Blacklist aus­schlag­ge­bend ist, doch direkt aus der eigenen Konfiguration bzw. aus dem Log des für die dritte IP-Adresse zuständigen Mailservers ersichtlich sein (und auch nur daraus, nicht aus den obengenannten Angaben); ersteres ist weniger wahrscheinlich, weil die E-Mail in diesem Fall ja von lx19[mail].hoststar.hosting einfach ver­wor­fen worden wäre. Wenn die dritte IP-Adresse mit dem dedizierten Empfänger identisch ist, kann es auch schlichtweg sein, dass dort kein Dienst läuft, welcher die E-Mail in Empfang hätte nehmen können.