Bisher nicht, Ticket dazu ist aber schon eröffnet.
Wegen DKIM/DMARC eigentlich ein "must-have", nicht nur "nice to have".
Dass hier spannende Zusatz-Probleme folgen (Stichwort Reseller-Mails/Absender!), ist leider auch klar.
Beiträge von antondollmaier
-
-
Ist in der liveconfig.conf der "http_canonical_host" auf die öffentliche URL gesetzt?
-
Hallo,
aktuell kann eine Domain nicht direkt verschoben werden - die Domain müsste im alten Vertrag gelöscht und im neuen Vertrag neu erstellt werden.
-
Danke - das Paket fehlte mir auch noch.
-
Last but not least wird die 2.15 voraussichtlich die letzte Minor-Release-Serie vor Version 3 sein.
Hui!
Ich stell schon mal das Bier kalt
-
Code
RECURSIVE=1 /usr/lib/liveconfig/lcservice.sh fix-permissions -
Wurde das Zertifikat ggf beim Reseller/Admin angelegt?
-
Schwierig. Ein öffentlicher SMTP-Server muss gemäß RFC3207 auch unverschlüsselte Verbindungen erlauben. Prinzipiell ist es aber möglich, Postfix so zu konfigurieren dass bei bestimmten Empfängerdomains nur verschüsselte eingehende Verbindungen erlaubt sind (reject_plaintext_session)
Das klingt doch nach DANE / MTA-STS ...
-
warnquota kann in /etc/default/quota aktiviert werden.
Empfänger ist jedoch der User selbst (sprich, Vertragsname). Eine Weiterleitung gibt es nicht, da LiveConfig keine Mailadresse für einen Nutzer erzwingt.
Der Linux-Dienst hilft einem so also nichts.
Wir haben einen eigenen Dienst geschrieben, der die LiveConfig-Datenbank abfragt und dann die Mails "sauber" via SMTP verschickt - wenn eine Mailadresse existiert.
-
Hallo,
Allerdings fände ich es großartig, wenn in den nächsten Updates eine Funktion kommt, mit der Domains auch HTTP-Protokoll unabhängig erstellen kann. Zum Beispiel, dass ich Domains hinzufügen kann, die im Virtualhost auf einen von mir festgelegten Port hören und nicht nur Port 80 oder 443.
Warum?Konkret: die HTTP-Validierung von SSL-Zertifikaten erfordert bei Let's Encrypt, dass HTTP/HTTPS (80/443) auf den CN/SAN des Zertifikates erreichbar sind. Bei anderen Ports kann somit keine Validierung erfolgen.
-
Das Problem ist dem Team um Herrn Keppler nur in der Form anzulasten, dass nicht auf die Nachfolgeversion 5.x umgestellt wurde/wird.
Schätze mal, da steht eher ne Migration auf Discourse an, als dass man das vBulletin noch weiter reitet.
-
Tendentiell Bug. Am Besten via "dig @ns1.... http://www.example.com" und in der Zone-Datei verifizieren, was tatsächlich geschrieben wurde.
Wir hatten da auch schon komisches Verhalten festgestellt, gerade mit externen DNS-Einträgen, CNAMES und der WWW-Subdomain.
-
Könnte an TLS 1.3 liegen, wie der erste Treffer bei Github zeigt:
https://github.com/proftpd/proftpd/issues/1151
Und ja, dürfte sich damit durch das Upgrade auf Bullseye (mit 1.3.7a) lösen.
-
Mein Fehler, das hab ich nicht gesehen.
-
-
Aktuell kann ich ja keine Updates sauber einspielen ohne dass die Problematik wieder auftritt, weil die vsftpd.lua natürlich durch neue Pakete überschrieben wird.
Die angepasste Funktion kann via custom.lua "sauber" überschrieben werden und so "update-fest" genutzt werden.
Machen wir für einige Webspace-Funktionen auch so.
-
liveconfig-meta hat eine "depends"-Abhängigkeit mit "awstats oder webalizer".
Somit kann liveconfig-meta nicht beibehalten werden, ohne auch awstats beizubehalten.
=> awstats in der Serververwaltung deaktivieren. Mehr geht nicht.
-
so könnte man schonmal Standard werte wie: TXT und _DMARC Infos Automatisch hinzufügen
SPF-Record ist bereits via Servereinstellungen möglich.
Zu DMARC: CloudFlare hat da einen richtig coolen Wizard gebaut: https://blog.cloudflare.com/tackling-email-spoofing/
-
Code
# /etc/systemd/system/clamav-daemon.service.d/clamav_restart.conf [Service] Restart=always
Danach ein "systemctl daemon-reload; systemctl restart clamav-daemon" und clamav wird automatisch neu gestartet. -
Logs (SSH sowie LiveConfig) prüfen, sowie die /etc/shadow vor und nach der PW-Änderung vergleichen, ggf. auszugsweise hier posten.
