Beiträge von kk

    Da man mit manchen Mail-Providern öfter Probleme hat, wenn sämtliche Mails einer Adresse dorthin umgeleitet werden [...]


    Was für Probleme denn genau?
    Wir haben hier ja auch eine Menge Mails an AOL und Google, die aber alle reibungslos durchkommen. Bei AOL muss man halt die Feedback-Loop (FBL) einrichten, bei Google sollte man nicht per IPv6 einliefern (außer die Absenderdomain hat SPF/DKIM). Aber auch prominentere Kunden mit fünfstelligen Mailaussendungen pro Tag machen hier keine Probleme.


    Prinzipiell halte ich es für sinnvoller, die Ursache zu beseitigen statt aufgrund der Symptome einfach die Weiterleitung zu verbieten. Wie schon früher in diesem Thread erwähnt schränkt man die Kunden dadurch ein, was vielleicht nicht überall auf Zustimmung stößt.


    Uns kam noch die Idee, optional Weiterleitungen komplett für einen Vertrag zu verbieten (wenn z.B. Policies im Unternehmen das nicht erlauben).


    Die Limitierung von ausgehenden Mails insgesamt ist eine andere Sache - da LC seit einer Weile ja die I/O-Statistiken für Mails bereits erfasst, wird genau das der nächste Schritt sein (HE war da wohl ein bisschen schneller ;)). Zudem finden sich im Internet Anleitungen, wie man die Zustellung an bestimmte Ziele anhand der Zieldomain oder auch des Ziel-SMTP-Servers limitieren kann (ließe sich auch so einrichten, dass LiveConfig das nicht weiter betrifft).

    So lange noch die Postfächer auf dem LiveConfig-Server angelegt sind und E-Mail für die betroffene Domain aktiviert ist, werden die Mails auch lokal zugestellt.


    In diesem Fall also: alle noch vorhandenen Postfächer löschen, und anschließend im Kundenaccount unter "Hosting" -> "Domains" die betroffene Domain bearbeiten und dort das Häkchen bei "E-Mails mit dieser Subdomain aktivieren" entfernen.

    Nee, wird vermutlich nicht so einfach klappen. Das Passwort-Feld in der SOAP-API darf max. 40 Zeichen lang sein (hängt damit zusammen, dass das LC-intern verschlüsselt und dann Base64-codiert in einem 64-Byte-Feld gespeichert wird).
    Eine Möglichkeit wäre es, einfach irgendein Dummy-Passwort für den Import zu verwenden und anschließend in der /etc/dovecot/passwd die Passwörter direkt durch die alten CRAM-MD5-Hashes zu ersetzen (z.B. mit sed). LiveConfig schreibt die Passwörter nämlich nicht ein zweites Mal raus (im Gegenteil - wenn das Passwort erfolgreich gesetzt wurde, lösche LiveConfig es sicherheitshalber aus seiner eigenen Datenbank).


    Hilft das weiter? Ansonsten müssten wir vermutlich diese 40-Zeichen-Grenze aufbohren.

    Welches Format haben denn die Passwörter aktuell? Beginnen die auch mit "$1$..."?
    Die SOAP-API (HostingMailboxAdd()) reicht das angegebene Passwort unverändert an die Lua-Funktion "addMailbox" (Datei dovecot.lua) durch; erst dort wird in ca. Zeile 763 geprüft, welches Format das Passwort hat. Hier ließe sich dann auch die Verarbeitung von einfachen MD5-Hashes integrieren - schicken Sie uns ggf. einfach mal ein Beispiel-Passwort (am besten die Zeichen a-z0-9 durch "#" ersetzen, damit das niemand entschlüsselt ;)


    Viele Grüße


    -Klaus Keppler

    Ursache gefunden, Fehler beseitigt (mit v1.9.0-r3645). War leider recht kompliziert (daher hatte das auch gedauert). Letztendlich sind Verträge dann nicht betroffen, wenn man abweichend vom Angebot eine bestimmte Shell einstellt.
    Wir testen die Änderungen noch durch und schreiben automatisierte Tests dazu, damit das künftig sauber funktioniert. Der Fehler schlich sich nämlich bei der rekursiven Prüfung auf übergeordnete Reseller-Einschränkungen mit ein.

    Scheinen wohl alle im Sommerurlaub zu sein :cool:


    Nein, ab 28° Bürotemperatur gibt's Hitzefrei. Wir melden uns im Oktober wieder. :p


    Spaß beiseite: wir haben den Fehler inzwischen gefunden. Das Init-Script für lclogparse wird korrekt installiert (d.h. mit einem Reboot wird der Dienst auch immer gestartet), aber nach der ersten Installation selbst kann es sein, dass unter manchen Bedingungen der Service nicht automatisch gestartet wird. Ist mit v1.9.0-r3644 behoben (sollte ab morgen online sein - wir sind in den letzten Zügen...)

    ... oder einfach mal ein Postfach mit 1MB Quota anlegen und eine Mail mit 700 kB Attachment hinschicken. ;)
    Quota-Warnungen gibt's bei Überschreiten von 80% und bei Erreichen von 100% Quota.

    Quota-Notify bei vollem Postfach ist bereits standardmäßig aktiv.


    Nur der Vollständigkeit halber: lässt sich (als Admin) unter Serververwaltung -> Mail -> Dovecot aktivieren/deaktivieren ("[X] Quota-Warnung aktivieren").


    Zitat

    Notify für Web-Quota lässt sich nur (sinnvoll) über einen Cronjob o.ä. realisieren.


    Steht schon länger hier auf der Wunschliste, ich hab's eben mal "offiziell" gemacht. :)
    https://www.liveconfig.com/dev/issues/193

    Wir hatten diese Diskussion schon.


    Auf neue Versionen wird hingewiesen:


    Das Changelog sowie die Download-Seiten werden natürlich immer entsprechend aktualisiert. Ein Changelog im APT-File ist derzeit aus technischen Gründen nicht möglich. Der Versand von Postkarten ist aus logistischen Gründen nicht möglich.


    Schönes Wochenende. :)

    Das kommt drauf an was für eine Subdomain Sie anlegen.
    Wenn Sie einen SRV-Record bei der Domain "example.org" für Port 1234 TCP benötigen, dann muss die dazugehörige Subdomain i.d.R. "_1234._tcp.example.org" heißen.
    Beachten Sie bitte, dass erst mit der aktuellen 1.9-Preview Subdomains mit Unterstrichen im Namen angelegt werden können.

    Im Hostingvertrag (oder Angebot) müssen Sie Subdomains erlauben und darunter die Einstellung "eigene DNS-Einträge:" auf "erlaubt" setzen.
    Anschließend können Sie über Hosting -> Domains die gewünschte Subdomain anlegen oder bearbeiten und finden dort einen Karteireiter "Eigene DNS-Einträge", wo Sie u.a. auch SRV-Records anlegen können.

    Streng genommen geht es ja um "OCSP Stapling" (nicht um OSCP). Beim OCSP-Stapling wird (ganz vereinfacht gesagt) eine von der CA signierte Bestätigung, dass das Zertifikat nicht zurückgezogen wurde, mit dem Zertifikat zusammen an den Client (Browser) gesendet. Wie so eine Nachricht "roh" aussieht kann man z.B. beim SSL-Check auf demo.liveconfig.com anschauen.


    OCSP-Stapling erfordert, dass der Server (Apache/NGINX/etc) regelmäßig bei der jeweiligen CA eine solche signierte Bestätigung abholt, um die dann an anfragende Clients mit auszuliefern.


    Bei Apache ist das ab Version 2.3.3 implementiert, bei NGINX ab 1.3.7. Um die Frage von Andreas zu beantworten: nein, da lässt sich leider nichts tricksen (außer: Apache selbst kompilieren oder einen Jessie-Backport installieren).


    Prinzipiell ist OCSP-Stapling auch mit anderen Diensten denkbar, da aber der meiste OCSP-Traffic durch Browser erzeugt wird, dürfte das bei allen anderen Protokollen relativ unwichtig sein. Zumal ja ohnehin fraglich ist, wie viele FTP-Clients/MUAs/MTAs/etc. tatsächlich per OCSP die Gültigkeit eines Zertifikats prüfen.


    Eine serverseitige Implementierung von OCSP-Stapling in LiveConfig ist nicht unmöglich (das Protokoll ist nicht sooo komplex), kostet aber (geschätzt) mindestens 1-2 Mannmonate. Wir haben das bereits auf der Wunschliste, aber mit sehr niedriger Priorität.


    Hauptvorteil von OCSP-Stapling (neben der Entlastung der CAs von OCSP-Requests und somit schnellerem SSL-Erst-Handshake) ist eben die Tatsache, dass die CA so nicht mehr mitbekommt, für welches Zertifikat die Gültigkeit geprüft wird (und somit implizit welche Website ein Browser gerade besuchen will).
    [offtopic]So lange man aber das "Safe Browsing" im Firefox/Chrome/etc. nicht abschaltet, wird ohnehin jede angesurfte URL an Google & Co. übermittelt...[/offtopic]


    Viele Grüße


    -Klaus Keppler

    Besser noch ein paar Features (die schon auch nett sind), damit die Bug-Anzahl bloß nicht abnimmt ;)


    Von manchen Bugs können wir uns einfach sooo schwer trennen. :p
    Spaß beiseite: ein paar "Altlasten" sind auch schon beseitigt, mehr dazu nächste Woche.


    Viele Grüße


    -Klaus Keppler

    Ab sofort werden auch FTPES und POP3/IMAP (STARTTLS) geprüft. Außerdem zeigt der Check nun weitere Infos an, u.a. OCSP-Support auf Port 443, verwendetes SSL-Protokoll sowie den Key-Typ & Größe. Im nächsten Schritt werden die gesammelten Infos aufbereitet und Tipps für eine bessere Konfiguration gegeben. Mit den ganzen Infos kann ja leider nicht jeder auf den ersten Blick etwas anfangen. ;)

    Ab sofort steht eine aktualisierte Preview der Version 1.9.0 (r3635) zum Download bereit. Es gab eine ganze Menge größerer Änderungen und Erweiterungen (siehe Änderungsverlauf auf der Preview-Seite).


    Zu den Themen DANE/TLSA und OCSP wird gerade noch die Doku erstellt; sobald diese fertig ist wird die an dieser Stelle noch verlinkt.
    Der Server demo.liveconfig.com läuft bereits mit v1.9.0, zudem haben wir DANE/TLSA erfolgreich u.a. auf der Domain @liveconfig.com (sowie natürlich @keppler-it.de) eingerichtet.


    Viele Grüße


    -Klaus Keppler

    Ab sofort bieten wir einen neuen Service auf der LiveConfig-Website: der SSL-Check.


    Mit dem SSL-Check kann man bequem und blitzschnell die SSL-Konfiguration auf allen wichtigen Standard-Ports prüfen (derzeit: 25 (SMTP), 465 (SMTPS), 587 (Submission), 443 (HTTPS), 993 (POP3S), 995 (IMAPS) und 8443 (LiveConfig). POP3/IMAP mit STARTTLS kommen in Kürze noch dazu.


    Der SSL-Check ersetzt ausdrücklich nicht ausführliche Protokolltests wie z.B. den Qualys SSL-Test. Vielmehr soll der SSL-Tests einen schnellen Überblick über alle konfigurierten Zertifikate bieten (Qualys testet derzeit nur Port 443). Zudem zeigt der SSL-Check an, ob DNSSEC für die angegebene Domain aktiviert ist, sowie die für TLSA-Records (DANE) relevanten Zertifikat-/Key-Hashes (mehr dazu in Kürze in einem separaten Beitrag).


    SSL-Check: https://www.liveconfig.com/de/sslcheck
    Dokumentation: https://www.liveconfig.com/wiki/de/sslcheck


    Der SSL-Test wird in der nächsten Zeit noch weiter ausgebaut - insbesondere die häufigsten Fehler (selbstsignierte Zertifikate, unsichere DH-Parameter, etc.) sollen erkannt und entsprechend hervorgehoben werden.
    Für Feedback, Anregungen und eventuelle Fehlermeldungen bitte einfach in diesem Thread antworten, oder eine Mail an support@liveconfig.com schicken.


    Viele Grüße


    -Klaus Keppler

    Welche Linux-Distribution bzw. welche Webserver-Software genau läuft denn auf dem neuen Server?
    (Apache 2.2, 2.4...?)


    Wenn Änderungen überhaupt keine Wirkung zeigen, dann kann das auch insgesamt auf ein Problem in der Apache-Konfiguration hindeuten (die Verzeichnisschutz-Sachen werden in die vhost-Konfiguration unter /etc/apache2/sites-available/<Vertrag>.conf geschrieben - die werden per Reload in den Apache übernommen; wenn aber ein Fehler irgendwo anders in der Apache-Konfiguration besteht, wird der Reload abgebrochen). In diesem Fall kann nur der Hoster selbst weiterhelfen (die können sich aber ggf auch gerne an uns wenden).

    Die optionalen PHP-Pakete für Debian wurden eben auf die Versionen 5.4.42, 5.5.26 und 5.6.10 aktualisiert (siehe Wiki).


    NEU: ab sofort stehen diese Pakete auch für Debian 8 (Jessie) zur Verfügung. Anders als bei Squeeze/Wheezy werden wir auch für die eigentlich über die Distribution verfügbare Serie (in diesem Fall 5.6.x) eigene PHP-Pakete bereitstellen (bei Jessie ist standardmäßig PHP 5.6.9 dabei).


    NEU: ab sofort steht zudem PHP 7.0.0-alpha1 zur Verfügung. Vom produktiven Einsatz rät das PHP-Team noch ab, aber erste Tests sind somit schon mal möglich. PHP 7 soll bis zu doppelt so schnell sein wie 5.6. Weitere Infos dazu gibt's auf der PHP-Website.