Beiträge von weltmeister

Gibt es hierfür noch eine Lösung?

Gibt es hierfür noch eine Lösung?

Falls es von interesse ist, ein Test unter Debian 8 war soeben innerhalb v. 5 Minuten mit den o.g. Einstellungen auf Anhieb und ohne weiteres probieren erfolgreich. Wo allerdings ist das Problem bei Debian 9?

Zitat von kk

Läuft OpenDKIM? (ps aux | grep -i dkim)

opendkim  7679  0.0  0.0 403200 11804 ?        Ssl  13:49   0:00 /usr/sbin/opendkim -P /var/spool/postfix/opendkim/opendkim.pid -p local:/var/spool/postfix/opendkim/opendkim.sock
root     16820  0.0  0.0  12784   980 pts/0    S+   15:17   0:00 grep -i dkim

Zitat von kk

Was liefert "grep smtpd_milters /etc/postfix/main.cf"?

non_smtpd_milters = unix:/opendkim/opendkim.sock
smtpd_milters = unix:/var/run/clamav/clamav-milter.ctl, unix:/var/run/lcsam.sock, unix:/var/spool/postfix/opendkim/opendkim.sock

Zitat von antondollmaier

Ist DKIM überhaupt in der Postfix-Konfiguration eingebunden, sprich die Konfiguration wirklich neu geschrieben worden?

Ja, auch das wurde schon geprüft, die Datei wurde komplett neu geschrieben. Es scheint alles OK zu sein, nur der Header in der Mail fehlt eben, aber warum? Habe ich noch etwas vergessen / übersehen?

Zitat von kk

Ist denn ein "DKIM-Signature:"-Header in versendeten E-Mails enthalten?

Nein, dieser fehlt, ist auch im Quelltext nicht ersichlich.

Zitat von kk

Wenn nein, was taucht alles in /var/log/mail.log auf, wenn eine E-Mail versendet wird?

Nichts ungewöhnliches meiner Meinung nach:

Jan 23 14:34:46 s1 postfix/smtps/smtpd[12921]: 265C42D0005: client=p4FD1FDC1.dip0.t-ipconnect.de[79.209.253.193], sasl_method=CRAM-MD5, sasl_username=info@domain.de
Jan 23 14:34:46 s1 postfix/cleanup[9742]: 265C42D0005: message-id=<5f6937f2-f678-2cb4-ddce-e5bc15fa841b@domain.de>
Jan 23 14:34:46 s1 postfix/qmgr[9011]: 265C42D0005: from=<info@domain.de>, size=1257, nrcpt=1 (queue active)
Jan 23 14:34:46 s1 postfix/smtp[13385]: 265C42D0005: to=<xxxxx@freenet.de>, relay=emig.freenet.de[195.4.92.217]:25, delay=0.43, delays=0.12/0.02/0.12/0.18, dsn=2.0.0, status=sent (250 OK id=1edyis-0000dN-EE)
Jan 23 14:34:46 s1 postfix/qmgr[9011]: 265C42D0005: removed

Vorgehensweise bei der Einrichtung exakt wie hier: https://www.loswebos.de/suppor…ls-mittels-DKIM-signieren

Alle Dienste wie LiveConfig, Postfix usw. wurden anschließend neugestartet.

Die Einrichtung erfolgte unter Debian 9 mit aktuellem LiveConfig.

Bei einem Test unter http://dkimvalidator.com wird der fehlende DKIM-Header bemängelt.

Was wurde vergessen oder muss noch aktiviert werden?

Es geht nicht nur um eigene Scripte, sondern auch um CMS-Systeme wie WordPress, deren z.B. verschickte Kontaktformular-Mails oder Newsletter wegen Tippfehlern im Nirvana landen.

Keine Rückmeldung?

Zitat von kk

Ich setze das mal auf die Wunschliste (die GUI für die Domaineinstellungen wird derzeit ohnehin umstrukturiert) - diese Art der Weiterleitung wird dann aber optional per LCDEFAULTS deaktivierbar sein.

Sie sind der beste!

Ja, oft. Wir haben letztendlich den täglichen Endkundenkontakt.

Zitat

Jeder 0815-Hoster, wie 1und1 & Co. bieten diese Weiterleitungsart an, warum ist das hier nicht möglich?

Soetwas bekommen wir teilweise von den Kunden zu hören.

Auch das wird oft von Kunden gewünscht. Vielleicht könnte man dies in LiveConfig ebenso integrieren?

Betrifft die Mails, die durch DNS-Blacklists abgewiesen werden: hier sollte dem Kunden die möglichkeit (auswahl) angeboten werden, ob diese Mails abgwiesen werden oder in einen Spamordner verschoben werden.
Es kam schon oft vor, dass für einen Kunden wichtige Mails nicht angekommen sind, die Kunden flippen dann regelrecht aus. Deaktiviert man die DNS-Blacklists, werden alle mit Spam überhäuft. Es muss also eine sinnvolle Lösung her. (Bei Plesk gibt es genau diese Funktion bereits)

Zitat von mkiefer

Konnte es lösen. Hatte nicht beim webspace bei PHP FastCGI gespeichert

Man sollte mit Debian 9 eigentlich sowieso nur noch FastCGI in diesem Menüpunkt auswählen können, wenn kein suPHP mehr vorhanden ist. Genau das Problem hatte ein Reseller auch, der hat stundenlang nach dem Fehler gesucht, dabei war es nur so eine Kleinigkeit.

Kann ich nicht bestätigen. Prüfe einmal den Eintrag "expose_php" unter dem Punkt "PHP-Einstellungen".

Bin auch dafür. (In Plesk gibt es diese Funktionen schon lange!)

... und genau diese Einstellungen kann doch jeder Kunde in seiner htaccess-Datei mauell setzen / überschreiben, d.h. er überschreibt die global-gesetzten Einstellungen durch seine eigenen. (Bei uns funktioniert das zumindest so ohne Probleme)

Allerdings wäre eine solche Funktion angebracht, bei Plesk kann man diese Header komfortabel über die Weboberfläche eintragen / ändern. Eine Sache, die es früher bei Confixx in ähnlicher Form schon gab.

Zitat von antondollmaier

nicht "localhost" setzen, sondern "127.0.0.1". Dann geht die Kommunikation über TCP.

Danke, das wurde testweise geändert. Leider kein Erfolg.

Die Datei 50-client.cnf sieht so aus:

#
# This group is read by the client library
# Use it for options that affect all clients, but not the server
#


[client]
# Default is Latin1, if you need UTF-8 set this (also in server section)
default-character-set = utf8mb4
# Example of client certificate usage
# ssl-cert=/etc/mysql/client-cert.pem
# ssl-key=/etc/mysql/client-key.pem
#
# Allow only TLS encrypted connections
# ssl-verify-server-cert=on
socket = /var/run/mysqld/mysqld.sock


# This group is *never* read by mysql client library, though this
# /etc/mysql/mariadb.cnf.d/client.cnf file is not read by Oracle MySQL
# client anyway.
# If you use the same .cnf file for MySQL and MariaDB,
# use it for MariaDB-only client options
[client-mariadb]

Die Fehlermeldung lautet nach wie vor:

Zitat

#2002 - Connection refused — Der Server antwortet nicht (evtl. ist der Socket des lokalen MySQL-Servers nicht korrekt konfiguriert).

Hat jemand eine Idee?

Wenn die phpmyadmin-Installation auf dem gleichen Server ist (localhost) ist keine Verbindung möglich.

Herr Keppler hat dazu folgende Info geschickt:

Zitat

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864662
Debian 9 ist installiert) in /etc/mysql/mariadb.conf.d/50-client.cnf fehlt folgende Zeile:

socket = /var/run/mysqld/mysqld.sock

Ohne diesen Eintrag können einige Anwendungen bei "localhost"-Verbindungen nicht den MySQL-Socket finden.

Leider schafft dies keine Abhilfe. Von allen "externen" Servern ist der Zugriff jedoch möglich. Hat jemand eine andere Idee?

Auszug aus der config.inc.php:

$i++; //Login funktioniert nicht
$cfg['Servers'][$i]['verbose'] = 'server1.meinedomain.de';
$cfg['Servers'][$i]['host'] = 'localhost';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['extension'] = 'mysqli';
$cfg['Servers'][$i]['auth_type'] = 'cookie';
$cfg['Servers'][$i]['hide_db'] = '(information_schema|mysql|performance_schema)';


$i++; //Login funktioniert
$cfg['Servers'][$i]['verbose'] = 'server2.meinedomain.de';
$cfg['Servers'][$i]['host'] = 'server2.meinedomain.de';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['extension'] = 'mysqli';
$cfg['Servers'][$i]['auth_type'] = 'cookie';
$cfg['Servers'][$i]['hide_db'] = '(information_schema|mysql|performance_schema)';


// LiveConfig Single Sign-On
$i++;
$cfg['Servers'][$i]['auth_type'] = 'signon';
$cfg['Servers'][$i]['host'] = '';
$cfg['Servers'][$i]['SignonSession'] = 'SignonSession';
$cfg['Servers'][$i]['SignonURL'] = 'lc-sso.php';

Viele Endbenutzer wünschen sich das, eine simple Backup- und Restorefunktion.