rseffner
-
Posts
209 -
Joined
-
Last visited
-
Days Won
9
Posts posted by rseffner
-
-
Hallo,
froxlor kommt ja mit einer Datenbankabfrage für den postfix-Parameter smtpd-sender-login-maps, die das SASL-Login mit der MAIL-FROM Adresse abgleicht - sprich tim@example.com kann auch nur als tim@example.com versenden, wenn man das aktiviert. Nun habe ich hier aber häufig Anwendungsfälle, in denen tim auch als timea@example.com (gleicher domainpart) oder sogar tim@example.de (abweichender, aber dem Froxlor-Kunden zugeordneter domainpart) versenden können soll.
Ich frage mich, ob man (also ich jetzt individuell) dazu nicht die SQL-query abändern könnte und wenn ja wie:
Wir haben:
SELECT DISTINCT username FROM mail_users WHERE email in ((SELECT mail_virtual.email_full FROM mail_virtual WHERE mail_virtual.email = '%s' UNION SELECT mail_virtual.destination FROM mail_virtual WHERE mail_virtual.email = '%s'));
Das "%s" steht laut postfix-Doku für "address". Wenn der SASL tim@example.com also als tim@example.com oder timea@example.com versenden dürfen soll, müsste es doch genügen, das erste Vorkommen von "%s" durch "%d" zu ersetzen - nicht?
SELECT DISTINCT username FROM mail_users WHERE email in ((SELECT mail_virtual.email_full FROM mail_virtual WHERE mail_virtual.email = '%d' UNION SELECT mail_virtual.destination FROM mail_virtual WHERE mail_virtual.email = '%s'));
Ferner scheint das auch nur so mit catch-all-Konten zu klappen (zumindest aus SQL-Sicht), ich bin mir nicht klar ob postfix dann noch localpart und domainpart durchprobiert.
Nun lässt sich das doch sicher auch so bauen, dass ein beliebiges Konto eines Froxlor-Kunden im Namen aller Nutzer und Domains des Kunden versenden dürfte. Das verkompliziert das SELECT dann, weil über die Kunde-ID gegangen werden muss. Gibt es hier SQL-Kenntnisse, die das ermöglichen würden?
-
Problem beseitigt.
-
UPDATE
Es hat nichts mit Domainanlegen zu tun. Ich habe in einem anderen Froxlor globale Settings geändert und erhalten den Fehler nun auch dort ;-(/usr/bin/php8.1 -q /var/www/webs/***/bin/froxlor-cli froxlor:cron 'tasks' --debug # der Fehler kommt erst NACH der letzten Domian in der debug-Ausgabe /usr/bin/php8.1 -q /var/www/webs/***/bin/froxlor-cli froxlor:cron 'tasks' -v /usr/bin/php8.1 -q /var/www/webs/***/bin/froxlor-cli froxlor:cron 'tasks' -vv /usr/bin/php8.1 -q /var/www/webs/***/bin/froxlor-cli froxlor:cron 'tasks' -vvv
Bringt leider auch keine Spur.
-
Erst die Tage das letzte Update (2.0.13) per git eingespielt, dann gestern zwei Domains anlegen wollen und nun per cron task aller 5 Minuten das hier:
PHP Fatal error: Uncaught TypeError: Froxlor\Dns\DnsEntry::__construct(): Argument #4 ($prio) must be of type int, null given, called in /var/www/webs/***/lib/Froxlor/Dns/Dns.php on line 283 and defined in /var/www/webs/***/lib/Froxlor/Dns/DnsEntry.php:47 Stack trace: #0 /var/www/webs/***/lib/Froxlor/Dns/Dns.php(283): Froxlor\Dns\DnsEntry->__construct() #1 /var/www/webs/***/lib/Froxlor/Cron/Dns/Bind.php(118): Froxlor\Dns\Dns::createDomainZone() #2 /var/www/webs/***/lib/Froxlor/Cron/Dns/Bind.php(69): Froxlor\Cron\Dns\Bind->walkDomainList() #3 /var/www/webs/***/lib/Froxlor/Cron/System/TasksCron.php(276): Froxlor\Cron\Dns\Bind->writeConfigs() #4 /var/www/webs/***/lib/Froxlor/Cron/System/TasksCron.php(79): Froxlor\Cron\System\TasksCron::rebuildDnsConfigs() #5 /var/www/webs/***/lib/Froxlor/Cli/MasterCron.php(134): Froxlor\Cron\System\TasksCron::run() #6 /var/www/webs/***/vendor/symfony/console/Command/Command.php(298): Froxlor\Cli\MasterCron->execute() #7 /var/www/webs/***/vendor/symfony/console/Application.php(1040): Symfony\Component\Console\Command\Command->run() #8 /var/www/webs/***/vendor/symfony/console/Application.php(301): Symfony\Component\Console\Application->doRunCommand() #9 /var/www/webs/***/vendor/symfony/console/Application.php(171): Symfony\Component\Console\Application->doRun() #10 /var/www/webs/***/bin/froxlor-cli(64): Symfony\Component\Console\Application->run() #11 {main} thrown in /var/www/webs/***/lib/Froxlor/Dns/DnsEntry.php on line 47Habe die Domains wieder gelöscht, aber das Problem besteht immer noch.
Kann man das irgendwie debuggen - ist doch sicher was in der SQL gelandet, was der DNS-Conde nicht verkraftet?
-
1 minute ago, d00p said:
welche "dutzende Vorkommen" von instanceof sprichst du denn aber an? Ich zähle 7 und nur \Net_DNS2_RR_A kommt aus dem globalen Scope, der rest sind froxlor klassen die entsprechend über ein use-statement eingebunden sind.
Alles in "vendor/" ist keine froxlor sache
Dann ignoriere meine grep-Zählerei bitte. Die hat keine scopes und Verzeichnisse berücksichtigt.
-
4 minutes ago, d00p said:
Aber auch ein "Jop, funktioniert so" würde mich hier helfen
Ich habe noch eine Domain ohne LE gefunden. Dort geht es jetzt (mit eingespieltem Patch).
-
24 minutes ago, d00p said:
Okay, jenachdem ist php wohl sehr zickig was die Klassenangabe bei `instanceof` angeht, hiermit geht es bei mir im test-szenario:
Da es im Code von Froxlor dutzende Vorkommnisse von instanceof mit \ aber auch ähnlich viele ohne gibt, wirft das die Frage auf, ob da noch mehr gefixt werden sollte. Liegts an der eingesetzten PHP-Version oder worauf bezieht sich "jenachdem"?
-
38 minutes ago, d00p said:
Stelle doch zunächst bitte sicher das mindestens eine der IP Adressen auf die die Domain auflöst auch in Froxlor angelegt und der Domain zugewiesen ist
Hatte ich das nicht geschrieben. Das war natürlich sichergestellt.
-
Ich habe in den Einstellungen als Validierungsresolver für LE einmal 8.8.8.8 und einmal nichts probiert.
Beide, also 8.8.8.8 und auch 127.0.0.1 liefern auf die Domain und die Subdumain www einen A-record, der der IP, die der Domain zugeordnet ist, entspricht.
Dennoch erhalte ich beim Versuch ein LE-Zertifikat für die Domain im Panel zu aktivieren die Meldung "Die DNS-Einträge der Domain enhalten keine der gewählten IP Adressen. Let's Encrypt Zertifikats-Erstellung ist nicht möglich."
Besonderheit ist hier vielleicht, dass ich ausnahmsweise mal nicht di DNS-Zone verwalte.
Was übersehe ich? -
Update : Query geht nun auch für catchall-Adressen / es wird ggf. für rspamd das Symbol BYPASS_VIRUS_CHECK gesetzt, dazu muss noch die /etc/rspamd/local.d/multimap.conf erweitert (oder angelegt werden)
BYPASS_VISRUS_CHECK { type = "rcpt"; map = "file:///var/lib/rspamd/virus_lovers.inc"; symbol = "BYPASS_VIRUS_CHECK"; score = 0.0; } -
Ich hatte hier eine Version die Mails doppelt signiert mit SHA und ellyptischen Kurven - da letzteres noch nicht viel Support hat, jetzt die abgespeckte Version
#!/bin/bash chown root._rspamd /etc/postfix/dkim/* SIGNFILE=/tmp/dkim_signing.conf echo "# If false, messages with empty envelope from are not signed" >$SIGNFILE echo "allow_envfrom_empty = true;" >>$SIGNFILE echo "# If true, envelope/header domain mismatch is ignored" >>$SIGNFILE echo "allow_hdrfrom_mismatch = true;" >>$SIGNFILE echo "# If true, multiple from headers are allowed (but only first is used)" >>$SIGNFILE echo "allow_hdrfrom_multiple = false;" >>$SIGNFILE echo "# If true, username does not need to contain matching domain" >>$SIGNFILE echo "allow_username_mismatch = true;" >>$SIGNFILE echo "# If false, messages from local networks are not selected for signing" >>$SIGNFILE echo "sign_local = true;" >>$SIGNFILE echo "# If false, messages from domains not defined here will not be signed" >>$SIGNFILE echo "try_fallback = false;" >>$SIGNFILE echo "symbol = "DKIM_SIGNED";" >>$SIGNFILE echo "use_domain = "envelope";" >>$SIGNFILE echo "domain {" >>$SIGNFILE cat /etc/postfix/dkim/dkim-keys.conf | while read LINE; do DOMAIN=`echo $LINE | awk -F: '{ print $2 }'` echo " $DOMAIN {" >>$SIGNFILE KEY=`echo $LINE | awk -F: '{ print $3 }'` echo " path = \"$KEY\";" >>$SIGNFILE SELECTOR=`echo $KEY | awk -F/ '{ print $5 }' | awk -F. '{ print $1 }'` echo " selector = \"$SELECTOR\";" >>$SIGNFILE echo " }" >>$SIGNFILE done echo "}" >>$SIGNFILE cp $SIGNFILE /etc/rspamd/local.d/dkim_signing.conf systemctl reload rspamd rm $SIGNFILE
-
9 minutes ago, d00p said:
Ist in git schon behoben, es gibt ein Problem wenn nicht alle IP Adressen gewählt sind (required flag der checkbox)
Verrätst Du bitte, welche Datei(en) betroffen sind - ich habe hier ja hauptsächlich apt-Installationen.
-
Ich bin im froxlor 2.0.7 als Admin angemeldet und möchte geänderte "Domaineinstellungen" speichern. Nach Druck auf den nun einzigen Knopf "Speichern" ganz am Ende der Seite scrollt diese mit dem Eingabefokus auf die erste IP-Adresse unter "Webserver-Einstellungen" zurück, die Änderungen werden aber durch den cronjob nicht durchgeführt und sind bei erneutem Aufrufen der "Domaineinstellungen" auch wieder weg (z.B. VHost-Settings oder Schalter zur Vererbung an Subdomains).
Das tritt NICHT bei allen meinen Installationen auf, gemeinsam haben die mit dem Fehler u.a. = im froxlor konfigurierte IPv6-Adressen (und genau dort sitzt nach dem scrollen der Fokus). Normal müsste er ja auf die Liste mit Domains zurückspringen.
Scrolle ich nach dem Speichern-Druck durch die Seite, kann kein keine Fehlermeldung finden.
Wie können wir das debuggen.
-
5 minutes ago, d00p said:
Ich miente keine {ASD} prefixe sondern vom Hash... Fangen die nicht mit $irgendwas$ an?
Nein, auch keine $irgendwas
-
3 minutes ago, d00p said:
Kannst du mir prefixe der Passwörter in deiner DB nennen die nicht mit {...} Anfangen.?
Die haben eben keine Präfixe. Setze ich {CRYPT} gehts dann - erschließt sich mir nun auch dank Deines Tips mit doveadm pw -l.
Wie alt müssen diese Kennwörter wohl sein ... aus SYSCP-Zeiten?
-
Einfach ein {CRYPT} direkt an den Anfang der Passworstrings in der Spalte password_enc bei ausschließlich den Einträgen die nicht mit "{" beginnen hilft.
-
4 minutes ago, d00p said:
BLF-CRYPT steht aber doch drin...sollte problemlos funktionieren, nutze ich auf meiner Kiste seit Wochen mit aktualisierten und neuen Mail Konten
Zu BLF-CRYPT schrieb ich doch nur, dass das gesetzt wird, wenn ich jetzt mit froxlor2 ein Kennwort setze. Diese funktionieren dann übrigens. Ich konnte es auf den ersten Typ eingrenzen, Kennwörter, die kein "{***-CRYPT gesetzt}" haben.
Vielleicht kann man die ja um {irgendwas-CRYPT}$irgendwas am Begin ergänzen und dann gehts wieder? -
37 minutes ago, d00p said:
welches os, welche dovecot version und wie lautet die ausgabe von doveadm pw -l
history : db-updates seit syscp
os : debian 11
dovecot : 2.3.13+dfsg1-2+deb11u1
doveadm pw -l : SHA1 SSHA512 SCRAM-SHA-256 BLF-CRYPT PLAIN HMAC-MD5 OTP SHA512 SHA DES-CRYPT CRYPT SSHA MD5-CRYPT PLAIN-MD4 PLAIN-MD5 SCRAM-SHA-1 SHA512-CRYPT CLEAR CLEARTEXT ARGON2I ARGON2ID SSHA256 MD5 PBKDF2 SHA256 CRAM-MD5 PLAIN-TRUNC SHA256-CRYPT SMD5 DIGEST-MD5 LDAP-MD5 -
Nachdem ich dem Migrationsleitfaden folgend einen Tag nach Upgrade auf froxlor2 nun auch noch im dovecot "default_pass_scheme = CRYPT" kommentiert habe, gibt es jetzt einige Nutzer, die sich nicht mehr anmelden können.
Was auffällt ist, dass es in der Spalte password_enc der Tabelle mail_users nun verschiedenen Kennwortypen gibt
- *****
- {BLF-CRYPT}$2y$10$***** - das entsteht bei Neusetzen eines Passortes mit froxlor2
- {MD5-CRYPT}$1$***** - die scheinen laut dovecot.log auch zu funktionieren
- {SHA512-CRYPT}$6$0***** - die scheinen laut dovecot.log auch zu funktionieren
Kann es sein, dass nun ein(ige) Format(e) nicht mehr funktionieren? Welche?
-
Die defaults für Spammarkierung und Spamabweisung sind momentan statisch definiert in der SQL-Anpassung UND dem Skript froxlor2rspamd. Wem also 7 und 14 nicht passen, der sollte das an beiden Stellen (Skript UND SQL-Struktur) ändern!
-
Vorab, ich bin kein Entwickler, daher kann das Folgende Fehler enthalten und/oder besser gelöst werden. Ferner kann ich es auch nicht mit einem "pull request" vollständig in die froxlor-Entwicklung einarbeiten - vielleicht erbarmt sich ja der Entwickler oder ein "Nutznießer" der folgenden Informationen.
Ich habe das Setup unter debian 11 / bullseye laufen - für andere Distributionen mögen Anpassungen nötig sein.UI / SQL
Zuerst gibt es zusätzliche Optionen für die E-Mail-Adressen (siehe frx-settings.jpg), dazu müssen customer_email.php, lib/formfields/customer/email/formfield.emails_edit.php und lib/Froxlor/Api/Commands/Emails.php angepasst werden (siehe *.diff). Damit die Settings auch irgendwo gespeichert werden, erweitert man die Datenbank von froxlor (siehe mail_virtual.sql, es braucht nur die 5 ALTER TABLE Befehle angewendet auf die Datenbank von froxlor). [die diffs sind gegen froxlor 2.0.6 erstellt!]
DKIM / RSPAMD
Nachdem der Nutzer nun Dinge einstellen kann (die sich noch nicht auswirken) kümmern wir uns mal um DKIM mit rspamd. Dazu könnten die Einstellungen wie in frx-dkim-settings.jpg vorgenommen werden. Ich bin mir nicht mehr sicher, ob der Ordner dkim unter /etc/postfix im Beispiel erst angelegt werden musste, oder ob sich froxlor darum kümmert. Dort werden nun jedenfalls eine dkim-keys.conf und die keys abgelegt. Da wir das aber in einem rspamd-tauglichen Format benötigen, wird zusätzlich das Skript /usr/local/sbin/dkim2rspamd getriggert. Dazu muss natürlich rspamd installiert und konfiguriert sein. Das Skript baut nun eine Konfiguration zur Mailsignierung aus den Daten, die froxlor ins Dateisystem gelegt hat. Benötigt werden bash, awk, head, cat und es wird von einem System mit systemd ausgegangen.
SPAMSETTING / RSPAMD
Nun müssen noch die Spamsettings der Nutzer ja irgendwie ins rspamd. Da ich hier im froxlor keinen Trigger gefunden habe, erledigt das ein cron-job. Z.B. alle 5 Minuten:
*/5 * * * * root /usr/local/sbin/froxlor2rspamd
Im Skript froxlor2rspamd (welches auch unter /usr/local/sbin liegt) müssen noch Datenbankanmeldedaten mit mindestens lesenden Rechten hinterlegt werden. Hier kommen der mysql/mariadb-client, sed, cat und diff zum Einsatz - diff gehört wohl nicht unbedingt zu einer Grundausstattung. Es wird eine settings_frx.conf für rspamd erstellt, die aber erst noch eingebunden werden muss. Dazu kann ans Ende der (ggf. zu erstellenden) /etc/rspamd/local.d/settings.conf folgende Zeile
.include(try=true; priority=1; duplicate=merge) "$LOCAL_CONFDIR/local.d/settings_frx.conf"
TODO
Bleibt die Frage, wie wirkt sich der Virenschutzparameter aus. Die Antwort ist : "kommt drauf an". Aktuell habe ich einen AV mit icap im rspamd und der schert sich gerade gar nicht um die Einstellung - Vorschläge gern willkommen. Vorher lief amavis-milter und mit dem habe ich direkt die SQL-Tabelle ausgelesen. Wie das eingestellt war, finde ich auf Anfrage vielleicht noch in einem Backup.
Diese "Information" ist aus dem Gedächtnis erstellt und wurde nicht an einen System from scratch ausprobiert. Du solltest im Linux wissen was Du tust, dann kommst Du sicher zurecht, wenn nicht ergänze ich gern oder beantworte Fragen. Ich werde aber keine Anleitungen geben wir z.B. rspamd oder postfix grundsätzlich zu konfigurieren sind. Das hier dient nur als Ergänzung für ein schon laufendes System mit diesen Komponenten.Viel Erfolg. Und wenn ich mir was wünschen dürfte - bringt das bitte so oder ähnlich ins froxlor.
formfield.emails_edit.php.diff customer_email.php.diff Emails.php.diff mail_virtual.sql froxlor2rspamd
-
1
-
-
3 minutes ago, d00p said:
puh, das ist ja noch uralt layout...müssen wir wohl doch noch berücksichtigen, hat keine der vorherigen versionen das mal ordentlich neugeschrieben (dachte eigentlich wir hatten da was) - schau ich mir an.
Auf den betroffenen Servern ziehe ich mir das latest als tgz per wget und kopiere (außer z.b. der userdata.inc.php) einfach im docroot über. Vielleicht hatten Diene Automatismen da auch nie eine Chance zur Korrektur.
-
Froxlor schreibt doch auf Wunsch (Einstellungen) eine Datei voller Domains, Separatoren und Keydateinamen sowie die privaten Keys in ein Verzeichnis.
Ich habe dazu einen dirty hack, der das in eine rspmad-Konfiguration übersetzt
#!/bin/bash chown root._rspamd /etc/postfix/dkim/* SIGNFILE=/tmp/dkim_signing.conf echo "# If false, messages with empty envelope from are not signed" >$SIGNFILE echo "allow_envfrom_empty = true;" >>$SIGNFILE echo "# If true, envelope/header domain mismatch is ignored" >>$SIGNFILE echo "allow_hdrfrom_mismatch = true;" >>$SIGNFILE echo "# If true, multiple from headers are allowed (but only first is used)" >>$SIGNFILE echo "allow_hdrfrom_multiple = false;" >>$SIGNFILE echo "# If true, username does not need to contain matching domain" >>$SIGNFILE echo "allow_username_mismatch = true;" >>$SIGNFILE echo "# If false, messages from local networks are not selected for signing" >>$SIGNFILE echo "sign_local = true;" >>$SIGNFILE echo "# If false, messages from domains not defined here will not be signed" >>$SIGNFILE echo "try_fallback = false;" >>$SIGNFILE echo "symbol = "DKIM_SIGNED";" >>$SIGNFILE echo "use_domain = "envelope";" >>$SIGNFILE echo "domain {" >>$SIGNFILE cat /etc/postfix/dkim/dkim-keys.conf | while read LINE; do DOMAIN=`echo $LINE | awk -F: '{ print $2 }'` echo " $DOMAIN {" >>$SIGNFILE ED_ENABLED="no" if [ -f /etc/postfix/dkim/$DOMAIN.pubkey ]; then ED_ENABLED="yes" ED_SELECTOR=`head -n 1 /etc/postfix/dkim/$DOMAIN.pubkey | awk -F. '{print $1}'` echo " selectors [" >>$SIGNFILE echo " {" >>$SIGNFILE echo " path = \"/etc/postfix/dkim/$DOMAIN.privkey\";" >>$SIGNFILE echo " selector = \"$ED_SELECTOR\";" >>$SIGNFILE echo " }," >>$SIGNFILE echo " {" >>$SIGNFILE fi KEY=`echo $LINE | awk -F: '{ print $3 }'` echo " path = \"$KEY\";" >>$SIGNFILE SELECTOR=`echo $KEY | awk -F/ '{ print $5 }' | awk -F. '{ print $1 }'` echo " selector = \"$SELECTOR\";" >>$SIGNFILE if [ $ED_ENABLED = "yes" ]; then echo " }" >>$SIGNFILE echo " ]" >>$SIGNFILE fi echo " }" >>$SIGNFILE done echo "}" >>$SIGNFILE cp $SIGNFILE /etc/rspamd/local.d/dkim_signing.conf systemctl reload rspamd rm $SIGNFILE
Das Skript kannst Du auch durch Froxlor triggern lassen, siehe DKIM-Einstellungen.
-
43 minutes ago, d00p said:
Wie sieht deine lib/userdata.inc.php aus? (pwd natürlich bitte entfernen)
so sah es VOR UND NACH dem Update aus
root@ns2:/var/www/froxlor/lib# cat userdata.inc.php <?php $sql['host']='localhost'; $sql['user']='syscp'; $sql['password']='***'; $sql['db']='syscp'; $sql['root_user']='syscpsql'; $sql['root_password']='*****'; ?>
authentifizierten Nutzern den Mailversand einschränken
in German / Deutsch
Posted
Ja, dass das im UI ne Menge Arbeit bedeuten würde ist mir klar.
Ich möchte erstmal wissen, ob die %d Ersetzung von der Adressberechtigung auf die Domainberechtigung wechselt. Man könnte das ja als Tipp in die Doku aufnehmen.
Die Kür wäre dann, wenn ein DB:Profi mal schaut wie man diese Anfrage auf alle Domains des Kunden, zu dem das Saale-Login passt, erweitert.