Also, wenn ich in Google die Begriffe
liveconfig dane tlsa
eingebe, dann erhalte ich diese Seite als ersten Treffer...
Also, wenn ich in Google die Begriffe
liveconfig dane tlsa
eingebe, dann erhalte ich diese Seite als ersten Treffer...
Mit LiveConfig v2.9.2 wird es auch möglich sein, Wildcard-Domains bei den Postfach-spezifischen Blacklists/Whitelists anzugeben - zum Beispiel *.example.org oder sogar *.tld.
Viele Grüße
-Klaus Keppler
Als Workaround (wenn man den Stick nicht zur Hand hat): das Passwort + OTP zusammen eingeben (also den OTP-Code direkt ans Passwort dranhängen).
Wir haben diesen Effekt mit neueren Browsern auch schon beobachtet und das auf die ToDo-Liste gesetzt.
Viele Grüße
-Klaus Keppler
seit wann gibt es denn eine domainname.httpd.conf, hast du einen Link für mich?
Changelog zu Version 2.8.0:
ZitatUnterstützung individueller Apache-Konfigurationsanweisungen pro Domain (/var/www/<Vertrag>/conf/<Domain>.httpd.conf)
Die von LiveConfig erzeugte Mobileconfig verwendet als "PayloadIdentifier" den Namen des Mailservers.
Das führt dann vermutlich zum Ersetzen.
Wir werden das mit dem kommenden Update (v2.9.2) durch die E-Mail-Adresse ersetzen - damit sollte das eindeutig bleiben.
Bis dahin müssten mehrfache Adressen auf dem selben Mailserver ggf. manuell auf dem iPhone angelegt werden.
Viele Grüße
-Klaus Keppler
Ich beende die Diskussion an dieser Stelle.
Die gewünschte Funktion wird es (um des Friedens willen) geben, aber natürlich optional und standardmäßig nicht aktiviert.
Wir raten aus mehrfach genannten Gründen dringend vom automatischen Verschieben verdächtiger Mails in einen Spam-Ordner ab.
Thread hiermit geschlossen.
Ich habe da was gefunden... das neue Limit sollte nun bei 2 Buchstaben liegen.
Ich weiß aber nicht ob Begriffe aus 3 Zeichen bereits im Index sind - das müssen wir mal beobachten (vBB scheint selber einen Suchindex zu erzeugen, unabhängig von der dahinterstehenden Datenbank)
Viele Grüße
-Klaus Keppler
Uh, gute Frage. Wenn man das im vBulletin irgendwo abschalten kann machen wir das gerne (ich schaue mich später gerne noch mal im Backend um).
Wir planen übrigens das alte vBB in einigen Monaten durch ein neues Board zu ersetzen.
Es steht doch ganz klar das es einen ersten Ausblick (wenn alles Glatt geht) mit der kommenden 2.9.2 gibt?!
Exakt.
Um genau zu sein: der Backup-Service selbst (lcbackup) ist tatsächlich schon fertig und wird auch seit v2.9.0 schon installiert (aber noch nicht aktiviert). Wir arbeiten aktuell "nur" noch an der Konfiguration der Backups. Und das ist in der Tat wesentlich komplexer als "nur mal nen Cron-Job einzurichten"... ![]()
Vorab schon mal ein paar Worte zu unserem System:
das Backup wird durch einen separaten Prozess durchgeführt (lcbackupd). Die einzelnen Backupjobs laufen in separaten Threads - die Anzahl der gleichzeitigen Threads ist konfigurierbar (kann man also dann je nach Serverleistung/-Last anpassen).
Ebenso ist frei konfigurierbar, zu welchen Zeiten welche Backups erzeugt werden - so kann man z.B. einmal täglich ein Vollbackup erstellen, und alle vier Stunden die Datenbanken sichern usw.
Damit Kunden den Server nicht "abschießen", ist ebenfalls konfigurierbar, ob Kunden ggf eine gewisse Zeit abwarten müssen bis sie ein neues Backup anstoßen können (um nicht alle zwei Minuten ein Backup zu erstellen ![]()
Last but noch least ist die Anzahl der vorgehaltenen Backups ebenfalls frei konfigurierbar - sowohl der vom System erstellten (automatischen) Backups, als auch der vom Kunden erzeugten.
Wenn alles glatt geht gibt's einen ersten Ausblick bereits mit dem kommenden Update v2.9.2.
Viele Grüße
-Klaus Keppler
Können wir dafür in der Mailverwaltung oder beim Account das Feature deaktivierbar haben?
Und den Default auf "nicht verschieben", so dass der Nutzer/Kunde das explizit für jedes Postfach aktivieren muss?
Ja, so ist das geplant. In den Mailservereinstellungen kann das dann grundsätzlich aktiviert/deaktiviert werden, zudem pro Postfach. Ich sehe das auch so, dass Kunden das ausdrücklich aktivieren sollen, dann ist zumindest klar wer daran schuld ist, wenn Mails "plötzlich" verschoben werden...
Nun, man kann den Kunden alternativ auch erklären, warum ein "Spam-Ordner" eben keine gute Idee ist und man ihn deshalb bewusst nicht anbietet.
Hinterfragt denn wirklich niemand den Sinn und Zweck von dem Ganzen?
Nutzt denn niemand hier Google Mail? Kann ich mir gar nicht vorstellen...
Fakt ist: E-Mails, die im Spam-Ordner landen, werden nur extrem selten angeschaut (wenn überhaupt). Das hat dann folgende Nebenwirkungen:
Bei Google Mail ist es ein zunehmendes Problem, dass Mails voreilig im Spam-Ordner landen und somit beim Empfänger faktisch nicht ankommen.
Meiner Meinung nach sollte man sich darauf fokussieren, möglichst viel Spam direkt abzulehnen.
Bayes-Filter werden dafür übrigens überbewertet. Wenn man ClamAV und SpamAssassin richtig tuned und regelmäßig pflegt, hat man letztendlich viel mehr davon. Mit einer guten Kombination aus DNS-Whitelist, Greylisting, DNS-Blacklists, ClamAV mit zusätzlichen Regeln (z.B. Sanesecurity) und SpamAssassin mit entsprechender Pflege (z.B. Scores für SPF/DKIM anpassen, ggf. selber DMARC einführen, usw.) erhält man fantastische Ergebnisse.
Aber für "unbelehrbare" werden wir dieses Feature dann wohl mit einem der nächsten Updates einführen. Beim Setzen der Checkbox ("verdächtige Mails in Spam-Ordner verschieben") wird dann einfach eine entsprechende Sieve-Regel erzeugt.
Aber noch mal: ich rate dringend davon ab - das gibt nur Ärger ("Hilfe meine E-Mails kommen beim Empfänger nicht an", "Hilfe ich erwarte eine Mail aber die kommt nicht", "Warum kommen über POP3 nur manche Mails bei mir an?", und so weiter...)
Viele Grüße
-Klaus Keppler
Hallo,
unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.27, 7.3.14 und 7.4.2 aktualisiert.
Ebenso wurde die igbinary-Extension auf die Version 3.1.2 aktualisiert.
Viele Grüße
-Klaus Keppler
Alternativ eine IP-Gruppe bearbeiten (z.B. Namen ändern).
Die neuen Pfade für die Domainvalidierung wurden mit v2.9 eingeführt, wobei LiveConfig da während des Upgrades eigentlich alle vHosts hätte aktualisieren sollen.
Auf welcher Distribution arbeiten Sie, und wissen Sie noch welche Version vor dem Upgrade auf 2.9.0 lief?
Danke für den Hinweis - wir haben den Fehler eben reproduzieren können.
Wir werden die Sache nun analysieren und kurzfristig beheben (mit v2.9.2).
Viele Grüße
-Klaus Keppler
Das Problem findet sich in dieser Meldung:
/opt/php-7.3/lib/extensions/no-debug-non-zts-20180731/igbinary.so: undefined symbol: ps_globals
Die "igbinary"-Extension benötigt zwingend die "sessions"-Extension.
Auf welcher Distribution arbeiten Sie, und haben Sie das sessions-Modul eventuell deaktiviert?
(das Laden der igbinary-Extension erfolgt über /opt/php-7.2/etc/conf.d/zz_18_igbinary.ini - und somit erst *nach* der session.ini)
Das passiert ja sicher nicht plötzlich, sondern nach irgendeinem Ereignis.
Ich tippe mal darauf, dass Debian aktualisiert wurde?
In dem Fall unter "Serververwaltung" -> "Mail" die Dovecot-Konfiguration neu schreiben lassen.
Viele Grüße
-Klaus Keppler
Starten Sie bitte LiveConfig mal neu und versuchen die Installation nach ca. 60 Sekunden noch mal (LC aktualisiert kurz nach dem Start das AppInstaller-Repository).
Hallo,
unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.26, 7.3.13 und 7.4.1 aktualisiert.
Zudem wurde im PHP 7.4-Paket ein Fehler mit der XML-Extension behoben.
Viele Grüße
-Klaus Keppler