Beiträge von antondollmaier

Zitat von weltmeister

Hier werden IPs über Jahre(!!) gespeichert

Signed. Hier sollte Anonymisierung möglich sein, insbesondere im Einklang mit der Datenschutzerklärung. Kontakt-Cleanup wäre in dem Zusammenhang auch sinnvoll zu nennen.

Zitat

Es interessiert sicher niemanden mehr, wann diese z.B. 2013 irgend eine Änderung auf dem Server vorgenommen haben. GGf. macht es sinn, alle Einträge, die z.B. älter als ein Jahr sind zu löschen.

Hier muss ich widersprechen: wir haben Kunden, die sich zuletzt 2018 eingeloggt haben, sich aber dennoch über "plötzlich falsche Passwörter" wundern.

An den paar MB an Logs solls ja letztendlich nicht scheitern.

Danke für's Teilen!

Um nicht wie im XKCD-Comic zu enden: was war's denn?

Signed. Standard-Wert nach Typ, oder gar ganz global via LCDEFAULTS, wäre super.

Zitat

Um das noch einmal klar zu stellen: ein reines Renewal ändert NICHTS an der Liste der Zwischenzertifikate. Weder mit LiveConfig, noch mit irgendeinem anderen ACME-Client.

naja, hier doch.

Validierungs-Fehler in CURL/OpenSSL treten ja auf, weil LiveConfig die CA-Chain in die *-ca.crt gelegt hat. Das wäre so kein Problem, gäbe es nicht die abgelaufenen oder ähnliche veraltete Zertifikate. Löse ich nun einen Renew dieser alten Zertifikate aus, ist das abgelaufene CA-Zertifikat auch weg und somit funktioniert die Validierung wieder.

Danke für das Update und die umfangreichen Infos!

Zitat von hchristo

Die Direkte Änderung durch Entfernen von einer IP oder DNSSEC läuft nur darauf hinaus dass Liveconfig dauerhaft als Status dann Anzeigt "Status:Konfiguration ok, warte auf Service-Neustart"

LetsEncrypt Zertifikate werden auch nicht Aktualisiert, Status 3er Domains: pending

Eine wirkliche Abhilfe bring nur nen Kompletter System Neustart des Servers

Das liegt eher an LiveConfig als an BIND - bitte die Logs von LiveConfig selbst durchgehen, vermutlich stirbt einer der Child-Prozesse.

Logs sammeln und per Ticket raus senden

Kann ich so bestätigen: in LiveConfig gibt's dahingehend keine Probleme, die letzten Renews haben allesamt das neue Root dabei.

Probleme gibt es nur, wenn das alte CA-Zertifikat gecached wird. Kann bei dehydrated/certbot passieren.

CatchAll-Mailadressen sind ein Problem und eigentlich unnötig:

- entweder ein Haupt-Postfach verwenden und die benötigten(!) Mailadressen als Alias dazu definieren
- oder auf den "Recipient Delimiter" und die Extension zugreifen:

info+shop1@example.com
info+support@example.com
info+vr@example.com
info+amazon@example.com

Diese müssen nicht explizit angemeldet werden.

Bisher ist mir DHL untergekommen, deren Mailsystem das "+" nicht akzeptiert. Alle anderen verwenden das problemlos ("info+bahn@example.com").

Absender-Mailadressen lassen sich bequem über die Blacklists sperren - Empfänger-Mailadressen bisher nicht.

Größtes Lob eines Deutschen? "Kann nicht meckern"

Scherz bei Seite: stimme dir auch zu. LiveConfig erfüllt unsere Anforderungen ebenfalls perfekt.

Und was aktuell noch nicht glänzt, wird ja durchaus poliert.

Zitat von lchel

Kann man Liveconfig beibringen. das über die Api eines Resellers zu machen, der auch Nameserver anbietet, z.B. United Domains?

Wäre das für andere auch ein nützliches Feature?

Persönliche Meinung: nachdem quasi jeder Provider seine eigene API hat, wäre der Integrationsaufwand schlichtweg immens. Im Gegensatz zu Let's Encrypt, wo es mit dem ACME-Standard tatsächlich einen Standard gibt und so ZeroSSL etc auch einfach integriert werden könnten.

Was spricht dagegen, bei Multi-Server-Installationen zwei VMs mit LiveConfig auszustatten und so eigene Nameserver zu betreiben?

Oder, bei Single-Server-Setups, BIND als Primary zu installieren und die Secondaries des Domain-Providers zu nutzen?

Zitat von hchristo

wofür brauch ich dann system.d?

Weil das so nun der Legacy/"Kompatibilitätsmodus" ist und nicht natives Systemd.

Auch "service" ist nur ein Alias/Wrapper zu systemctl.

Sorry, dass ich hier reingrätsche, aber: es gibt 2021 keine aktuelle Distri mehr, die nicht auf Systemd setzt.

Du willst also:

- die Service-Datei übertragen: /lib/systemd/system/lcbackup.service
- "systemctl daemon-reload" ausführen
- und den Dienst via "systemctl enable --now lcbackup.service" den Dienst aktivieren und starten.

Anschließend noch via "systemctl status lcbackup.service" prüfen und sicherstellen, dass der tatsächlich läuft:

root@web:~# systemctl status lcbackup.service
● lcbackup.service - LiveConfig Backup Daemon
   Loaded: loaded (/lib/systemd/system/lcbackup.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2021-06-24 21:03:41 UTC; 15h ago
 Main PID: 3841 (lcbackup)
    Tasks: 1 (limit: 2354)
   Memory: 5.0M
   CGroup: /system.slice/lcbackup.service
           └─3841 /usr/lib/liveconfig/lcbackup -d

Zitat von kk

Lange Rede, kurzer Sinn - wir planen folgende Änderung: wenn ein Wiederverkäufer ein Angebot erstellt, dann muss er da bereits festlegen, mit welchem (ihm zugewiesenem) Resellervertrag daraus dann Verträge erstellt werden.
Mit anderen Worten: bei Wiederverkäufern (und nur da!) werden Angebote mit jeweils einem Resellervertrag verknüpft. In der Praxis dürfte das relativ wenige Anwender betreffen.

Bedeutet IMHO also lediglich, dass ggf. mehrere, aber grundsätzlich identische, Angebote existieren müssten - soweit Kunden überhaupt Angebote nutzen.

Zitat

Die Alternative wäre gewesen, nur einen Resellervertrag pro Kunde zu erlauben - diese Einschränkung wäre wesentlich härter.

Genau, definitiv keine sinnvolle Lösung.

Danke!

dovecot.local.conf erstellen:

namespace inbox {
  mailbox Drafts {
    special_use = \Drafts
    auto = subscribe
  }
  mailbox Junk {
    special_use = \Junk
    auto = subscribe
    autoexpunge = 30d
  }
  mailbox Sent {
    special_use = \Sent
    auto = subscribe
  }
  mailbox Trash {
    special_use = \Trash
    auto = subscribe
    autoexpunge = 7d
  }
}

In LiveConfig bei Dovecot die Server-Konfiguration erneuern - fertig.

Zumindest, bis das Special-Use-Flag direkt in die Konfiguration kommt.

Die verlinkte Konfiguration ist nur für LiveConfig selbst relevant.

Statt RPAF ist der Einsatz von RemoteIP sinnvoller (vgl https://github.com/gnif/mod_rpaf

https://httpd.apache.org/docs/current/mod/mod_remoteip.html

Zitat von isphttp.de

Dankeschön, ich habe den Artikel jetzt überflogen "https://blog.aditsystems.de/2020/01/probleme-durch-spamversand/", steht es dort, wie man die Hotmail in die Backliste bei LC Global für alle Kunden einträgt?

Das ist unser Kunden-Blog - nein, da steht nichts zu den internen Tech-Daten

=> https://www.liveconfig.com/de/…omization/lcdefaults.html

Zitat von isphttp.de

Lösungsmöglichkeiten sehen ich aber keine, wie will man das unterbinden?

Natürlich: Weiterleitungen zu Microsoft unterbinden, indem "hotmail.com" usw auf die LiveConfig-Blacklist gesetzt werden.

Anschließend alle Weiterleitungs-Adressen, die Probleme bereiten, löschen (Weiterleitung entfernen, Postfach erstellen, Kunde informieren).

Habe ich doch schon verlinkt.

Zitat von isphttp.de

PS: Das E-Mails Von Server A mit Spam dann zu Hotmail weitergeleitet werden, ist denke ich nicht das Problem...

doch, genau das ist das Problem.

Sobald der Empfänger/Hotmail-Nutzer auf "Junk" drückt, fällt via SNDS / Junk Mail Reporting eine Meldung raus - an dich als Serverbetreiber, der für Microsoft die Quelle des Spams darstellt.

Und damit verschlechtert sich auch für deinen Server der Score bei Microsoft.

Zitat von TCRserver

Ich kann das Vorgehen von antondollmaier bestätigen.
Weiterleitungen zu hotmail und Co. verbieten, jeder einzelnen SPAM Meldung von MS nachgehen, die Ursache klären und beseitigen.
Anmeldung beim SNDS und beim Junk Mail Reporting Programm sollten natürlich auch sein.
Und ganz zur Not, auch mal einen Kunden freundlich aber bestimmt auf einen Fehler hinweisen und eine Lösung anbieten.

Korrekt.

Haben das sogar im Blog gepostet und verweisen alle Kunden bei Problemen auf diesen Artikel: https://blog.aditsystems.de/20…obleme-durch-spamversand/

Zitat

Kostet alles zusammen viel Manpower aber es hilft.

Einiges lässt sich automatisiert erleichtern. Wir erhalten z.B. Benachrichtigungen in Mattermost, wenn eine Mail gebounced wird. So kann man frühzeitig reagieren, bevor es zum Blacklisting kommt.

Zitat von weltmeister

Wie will man das zu 100% verhindern? Allein z.B. WordPress müllt die Postfächer der Kunden teilweise richtig zu. Viele Kunden sichern Kontaktforumlare z.B. nicht gegen Spam ab und sind dann auch noch so "blöd" und melden diese Mails als Spam bei hotmail, statt die Formulare zu deaktivieren oder mit einem Captcha gegen Spam abzusichern. Bei Kommentaren das gleiche.

"Ihre Webseite versendet Spam-E-Mails an Hotmail, wir haben diese daher gesperrt. Bitte sorgen Sie durch geeignete Schutzmaßnahmen dafür, dass keine Spam-E-Mails mehr verschickt werden, oder nutzen einen externen SMTP-Server, so dass diese Spam-Mails nicht mehr über unsere Mailserver verschickt werden."

Zitat

Das selbe gilt auch für Weiterleitungen: es gibt Kunden, die lassen sich alles mögliche ungefiltert(!) an deren Mailadressen weiterleiten, z.B. hotmail. Somit wird natürlich auch der Spam massenweise ungefiltert weitergeleitet. Auch hier gibt es dann leider "Deppen", welche die bereits weitergeleiteten Mails als Spam bei hotmail melden, statt die entsprechenden Filter in LiveConfig zu aktivieren.

LCDEFAULTS: mail.forwards.blacklist

Zitat

Bei einer Handvoll Kunden kann man ggf. noch "aufpassen", bei tausenden wird es schon schwierig. Nicht das wir ein Problem mit hotmail und Co hätten, aber hin und wieder trifft es auch mal einen unserer Server.

Wie gesagt, wir sind seit 1,5 Jahren an genau dem Thema dran.