Beiträge von antondollmaier

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.

Zitat von tfi

Für die nächste Rundmail an die PHP v5 Kunden wollte ich mir noch die LC-Datenbank anschauen
ob man nicht mit 1-2 Queries alle E-Mail-Adressen von Kunden mit aktivem PHP 5.x Webspace erhält.

Schleife:

SELECT * FROM CUSTOMERS LEFT JOIN CONTACTS ON (CUST_OWNER_C=CON_ID AND CON_CUSTOMERID=CUST_OWNER) WHERE CUST_OWNER=1

für jeden Kunden:

SELECT * FROM SUBDOMAINS
LEFT OUTER JOIN DOMAINS ON SD_DOMAINID=D_ID
LEFT OUTER JOIN HOSTINGCONTRACTS ON D_CONTRACTID=HC_ID
LEFT JOIN WEBRUNTIMES ON ( SD_PHPVERSIONID =WR_ID OR ( SD_PHPVERSIONID IS NULL AND HC_SERVERID=WR_SERVERID AND WR_PRIO=0 AND WR_FOUND=1))
LEFT JOIN SERVERS ON ( SRV_ID=HC_SERVERID)
WHERE (SD_WEBCONFIG IN (1,5) OR SD_SSL_WEBCONFIG IN (1,5)) AND HC_LOCKED & 1 = 0 AND HC_RCIDROOT IS NULL AND HC_CUSTOMERID=%s ORDER BY HC_NAME ASC, D_NAME ASC, SD_HOST ASC

Läuft hier in einem Python-Skript, das dann die tatsächlich unsicheren PHP-Versionen noch im Code ausfiltert.

Dafür sorgen, dass Spam-Mails nicht zu Microsoft kommen.

Mögliche Quellen für solche Spam-Mails:

- CMS
- Weiterleitungen
- Kunden-Newsletter

Viel Erfolg. Wir sind seit 1,5 Jahren konsequent dran und haben seit dem keine Probleme mehr. Sind aber auch nicht bei Hetzner o.ä..

Zitat von isphttp.de

Wir haben trotzdem gleich mal alles geupdatet.

Wird wohl Zeit für einen anderen Admin.

postfix/smtps/smtpd[13115]: warning: connect to Milter service unix:/var/run/lcsam.sock: Connection refused

Das hat aber nichts mit OpenDKIM zu tun.

Was steht im Journal? (journalctl -u lcsam)

Zitat von kk

Hintergrund ist: wenn Kunden über den Aufruf von sendmail E-Mails verschicken ohne einen korrekten "Envelope-From" (Paramater "-f") anzugeben, dann gehen diese mit dem Absender <vertrag>@<hostname> raus.

Ein verflixxtes anderes Config-Panel hat dafür früher[tm] einen Alias erstellt, so dass die eingehenden Mails dann an den Kunden weitergeleitet wurden.

Nachdem LC die Mailadresse beim Kunden eh optional hat - und Sendmail auch Teufelszeug ist (also, das Sendmail-Binary! Wer Sendmail statt Postfix/Exim einsetzen will, soll das gerne weiterhin tun) - ist das eigentlich die sauberste Lösung.

Mir tun jetzt nur die Kunden leid, die so falsch konfigurierte WP-Installationen aufweisen und damit keine Mails mehr an HostEurope-Kunden senden können. Da schlägt nämlich dann die Absender-Validierung endgültig fehl.

Was spricht dagegen, einen eigenen Resolver aufzusetzen?

Zitat von kk

Und egal welcher Resolver es wird: er sollte DNSSEC unterstützen.

Das ist bei BIND und Unbound der Fall, aber ja - sollte 2021 explizit sichergestellt werden.

Zitat

(persönlich bevorzuge ich die Resolver des RZ bzw Uplinks sofern diese zuverlässig sind)

Mit dem Nachteil, dass deren Cache dann natürlich zwar größer ist, aber auch nicht beeinflusst werden kann.

Wir haben im Netz eigene Resolver mit Unbound/dnsdist/corosync am laufen, um keine Abhängigkeiten zu haben.

Zitat von weltmeister

Welche Resolver / Einträge für resolv.conf sind zu empfehlen?

Einen DNS-Resolver, der schnell und zuverlässig arbeitet:

- die Resolver, die vom RZ/Provider bereitgestellt und gepflegt werden. Dort anfragen.
- einen der bekannten öffentlichen DNS-Resolver, wie Google/Cloudflare/Quad9, mit den dazugehörigen Nachteilen (gefilterte Einträge, Datenschutz, ...)
- sich selbst mit Bind/Unbound einen eigenen Resolver aufsetzen und diesen über 127.0.0.1/::1 ansprechen

Welche Option "die beste" ist, muss jeder für sich entscheiden.

Zitat von isphttp.de

Da lässt sich nur schwer ein Kunde ausfindig machen

Entweder die Mail kommt via php mail(), dann steht die UID mit im Log:

Feb  9 12:34:22 venus postfix/pickup[32433]: 36BEA68B3DB: uid=1153 from=<web800>

Hier kann man auch einen Sendmail-Wrapper verwenden, um die mail()-Aufrufe gezielt zu loggen.

Oder die Mail wurde per SMTP auf localhost:25 eingeliefert - dann wird es in der Tat etwas komplizierter. Passiert aber denkbar selten - und von außen gibt es die SASL-Authentifizierung, um den Absender zu identifizieren.

"journalctl -u logrotate.service"

Logs prüfen, Problem identifizieren, ggf. via "systemctl start logrotate.service" manuell ausführen.

Wenn das Quota erreicht ist, kann gzip nicht komprimieren - das kann dann schon das gesamte Logrotate mit Exit-Code 1 beenden lassen.

Zitat von stefanos

Bestimmt wird es noch etwas zu Lebzeiten! :confused:

Im alten Handbuch (Seite 95) steht ja auch "In Kürze wird es für LiveConfig eine Erweiterung der SOAPAPI geben, mit der Sie diesen Vorgang aber teilweise automatisieren können" wovon man bisher nichts sah.

Admin -> Reseller-Vertrag bearbeiten -> Tab Domains -> DNS-Vorlage auswählen.

Reseller können dann genau diese Vorlage nutzen, um eigene Domains auf den Nameservern zu erstellen.

Validierung gibt es IMHO nicht, so dass "gmx.de" durchaus auch angelegt werden könnte (Authoritive Nameserver sollten aber sowieso nicht als Recursor genutzt werden).