Das ist sicherlich nicht verkehrt. Dennoch wäre es interessant zu wissen, wieso dies auftritt.
Was passiert wenn man ssl-parameters.dat austauscht? Also auf einem der Server, wo ein 1024bit Key erzeugt wird, ersetzen, durch eine Datei von einem Server, wo ein 2048bit Key erzeugt wird.
Ich habe das Update auf 0.448 durchgeführt und danach direkt das Hotfix Skript ausgeführt. Mehr nicht.
Coderoot@XXX:~# openssl dhparam -in /usr/local/pd-admin2/dovecot-2.2/etc/dovecot/dh.pem -text | head -1 DH Parameters: (1024 bit)bei mir 1024
Hmm komisch, dass da unterschiedliche Dinge bei heraus kommen. Es wird die openssl Binary aus der SE verwendet? Laut https://doc.dovecot.org/config…on/#ssl-security-settings ist das ein Weg um eine v2.2 Parameter Datei zu konvertieren. Kommt es dann vielleicht durch die ssl-paramter.dat?
Versuche es mal mit HOST:PORT
ach ja... 
bei mir ergibt der Test ein A+ und keine Fehler. Einzige was bemängelt wird ist fehlendes OCSP stapling.
Der Inhalt von /usr/local/pd-admin2/dovecot-2.2/etc/dovecot/dh.pem sieht nach einem 1024 Key aus …
Sehen ist nicht prüfen 
$ openssl dhparam -in /usr/local/pd-admin2/dovecot-2.2/etc/dovecot/dh.pem -text | head -1
DH Parameters: (2048 bit)Bei mir ergibt das einen 2048bit Key.
Das SSL-Zertifikat wird jedoch nicht akzeptiert. Bei https://www.immuniweb.com/ssl/ erscheint folgende Meldung:
Übersehe ich da was? Bei mir wird nur der Webserver und nicht der Mailserver getestet.
Die 4. Zeile ist das Problem.
Die Zeile müsste dann doch seit je her ein Problem sein 
Egal, ob MAILFROM und MAILTO gesetzt sind, es wird immer mit anonymous@example.org die Mail verschickt.
Code
Wenn hat nur MAILFROM Einfluss auf den Absender, nicht MAILTO.
Die Variablen müssen also einen Wert haben.
mea culpa. Das war mir klar, hätte es nur klarer kommunizieren sollen. 
Bleibt die Frage woher das anonymous kommt...
Ich vermute mal, dass der "Return-Path" das Problem ist.
Die Frage ist eben woher das kommt. Ich habe bei mir im crontab
MAILFROM=
MAILTO=gesetzt. Entsprechend sehen Mails so aus
Return-Path: <root@xxxxxxxxx>
Delivered-To: xxxxxxxxx
Received: (qmail 784131 invoked by uid 0); 16 Jul 2024 10:15:08 -0000
Date: 16 Jul 2024 10:10:02 -0000
Message-ID: <20240716101002.783367.qmail@xxxxxxxxx>
From: "\(Cron Daemon\)" <root@xxxxxxxxx>
To: xxxxxxxxx
Subject: Cron <root@xxxxxxxxx> nice -n 19 /var/qmail/bin/update_tmprsadh 2>&1 MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Auto-Submitted: auto-generated
Precedence: bulk
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <XDG_SESSION_ID=c151279>
X-Cron-Env: <XDG_RUNTIME_DIR=/run/user/0>
X-Cron-Env: <DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/0/bus>
X-Cron-Env: <LANG=de_DE.UTF-8>
X-Cron-Env: <MAILTO=xxxxxxxxx>
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>Wenn ich das MAILTO und MAILFROM raus nehme sieht die Zustellung ähnlich wie bei Ihnen aus:
Return-Path: <root@hostname>
Received: from hostname (hostname. [xxxxxx])
by mx.google.com with ESMTPS id ffacd0b85a97d-3680daf708csi4917421f8f.487.2024.07.17.02.21.17
for <xxxxxx@gmail.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 17 Jul 2024 02:21:17 -0700 (PDT)
Received-SPF: pass (google.com: domain of root@hostname designates 2a02:e00:ffec:11f::a as permitted sender) client-ip=2a02:e00:ffec:11f::a;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of root@hostname designates 2a02:e00:ffec:11f::a as permitted sender) smtp.mailfrom=root@hostname;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=xxxxxx
X-PDA-ORIGIN: hostname
Received: (qmail 944995 invoked by alias); 17 Jul 2024 09:21:16 -0000
Delivered-To: root@hostname
X-Originally-To: root@hostname
Received: (qmail 944991 invoked by uid 0); 17 Jul 2024 09:21:16 -0000
Date: 17 Jul 2024 09:20:01 -0000
Message-ID: <20240717092001.944787.qmail@hostname>
From: "\(Cron Daemon\)" <root@hostname>
To: root@hostname
Subject: Cron <root@hostname> nice -n 19 /var/qmail/bin/update_tmprsadh
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Auto-Submitted: auto-generated
Precedence: bulk
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <XDG_SESSION_ID=c155547>
X-Cron-Env: <XDG_RUNTIME_DIR=/run/user/0>
X-Cron-Env: <DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/0/bus>
X-Cron-Env: <LANG=de_DE.UTF-8>
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>Aber eben auch nur ähnlich. Bei mir wird kein anonymous@ verwendet, sondern ebenfalls root@
Ich habe mal bei 4 Server nachgeschaut, bei allen gibt die Zeile Return-Path: <anonymous@s6.example.org>
Alle vier Server mit dem gleichen Betriebssystem? Irgendwas müssen die vier Server ja gemeinsam haben, was bei meinem Server nicht so ist. Ich kenne das so, dass der Return-Path vom Client (oder Skript) gesetzt wird. In dem Fall wäre der Client ja Cron. Was passiert denn wenn man einmal "MAILFROM" im crontab setzt?
Hatte aber vergessen bei dem Eintrag 16 5 * * * nice -n 19 /var/qmail/bin/update_tmprsadh das nach fold zu pipen 16 5 * * * nice -n 19 /var/qmail/bin/update_tmprsadh 2>&1 |fold -w 80
Jetzt weiß man zumindest welcher Cronjob bzw. welches Skript ausgeführt wird. Das Skript selbst generiert keine Mail. Setzt also keinen Absender.
Ich kann das Problem bei mir nicht reproduzieren. Ich selbst setze Oracle Linux 8 mit der SE 8 ein. Bei mir werden Mails mit root@hostname versandt.
qmail: 1720927248.742383 new msg 34603176
qmail: 1720927248.742421 info msg 34603176: bytes 28662 from <anonymous@s6.example.org> qp 665884 uid 0
qmail: 1720927248.743296 starting delivery 146: msg 34603176 to local root@s6.example.org
Die Initiale Mail setzt ja bereits anonymous@ als Absender. Wäre also die Frage woher da kommt. Scheint mir nicht generell so zu sein. Vielleicht Mal ein
MAILFROM=im crontab setzen?
Der initiale Fehler ist ja
qmail: 1720927249.021560 delivery 147: failure: 212.227.15.17_failed_after_I_sent_the_message./Remote_host_said:_501_Syntax_error_-_line_too_long/
Diesen sollte man weiter analysieren und beheben. Welcher Cronjob erzeugt diese Mail? Wie sieht die Mail aus?
Warum wird die Ursprungsmail mit dem Absender anonymous@s6.example.org verschickt und die weiteren Mails mit dem Absender <> und dann sogar mit <#@[]>?
Ich denke die erzeugte Mail kann hier mehr Details liefern.
Die weiteren Mails sind wahrscheinlich Bounces. Der erste Absender "<>" ist typisch für eine lokale Bounce Mail.
Nein,
wie gesagt tritt der Fehler schon auf, wenn nur phpinfo() ausgeführt werden soll.
Es kann sein, dass bei 1024MB immer noch nicht ausreichend Speicheradressen zur Verfügung stehen, damit der Prozess überhaupt starten kann. Und wenn ein Prozess gar nicht erst starten kann ist es irrelevant, ob nun ein einfaches phpinfo() oder Wordpress ausgeführt werden soll.
Das habe ich schon von 256 auf 512 auf 1024 MB geändert.
Wurde auch mit noch höheren Werten getestet?
Nur um sicher zu gehen, da es aus dem Text nicht hervor geht: Das Speicherlimit wurde im Angebot des/der betroffenen Nutzer geändert? Eine Änderung in der php.ini hat hier keine Wirkung.
Es ist natürlich so schwer zu sagen wieso es passiert... Ich würde mir einmal die Tabellen anschauen. Eventuell ist eine Tabelle auch super lang und es fehlt ein Index. Dann kann eine query schon Mal sehr lange benötigen.
Sieht man ggf. unter /opt/pdadmin/tmp/top, ob das Skript lange läuft?
Eventuell ist es auch ein Rate Limit. Andere Anbieter setzen auch Rate Limits ein. Es muss nicht am fehlenden ARC liegen.
Interessant ist, dass Google dies empfiehlt, während es in der RFC noch als experimentell markiert ist. Soweit ich das sehe, unterstützt qmail dies nicht.
"MySQL Server has gone away" bedeutet, dass es bei der query ein timeout gab. Die Frage wäre nun, wieso die query so lange benötigt. Wie viele Nutzer+Domains hat der Server?
AFAIK wird DKIM nur für die eingetragene Hauptdomain konfiguriert. Wenn man später über eine Subdomain Mails empfanden, senden und mit der Subdomain als Domain signieren möchte, muss domain.de als TLD und sub.domain.de als Domain bei einem Endkunden eingetragen werden.
Einziger "Fallstrick" ist hier Lets Encrypt. Für Hauptdomains werden immer Zertifikate für http://www.domain.de und domain.de erzeugt. Bei Nutzung einer Subdomain als Hauptdomain muss es im DNS somit einen A-Record für http://www.sub.domain.de und sub.domain.de geben.
Es ist schwer zu verstehen, was genau hier das Problem/Ziel ist. Der Titel "... vs ... vs ..." ist auch irgendwie irritierend. Ich denke, dass es hier Verständnisprobleme gibt.
ich habe pd-admin auf einer Subdomain laufen: sub.example.org
Es handelt sich dabei dann um einen Full Qualified Domain Name [FQDN]. Dies ist empfohlen für die Nutzung von pd-admin.
Was mich primär irritiert ist der "leere" Return-Path der Reject Nachricht: Return-Path: <"<>"@sub.example.org>.
Wie kann ich hier einen sinnvollen Return-Path setzen?
Bei der Mail handelt es sich um einen Mail-Rückläufer (Bounce Mail). Dieser wird von qmail selbst erzeugt. Der Return-Path, auch Envelope-Sender genannt, ist die Angabe des Absenders während des SMTP-Handshakes. Bei einem Mail-Rückläufer ist der Envelope-Sender immer "leer" bzw. "<>" [Bounce Message]. Dies soll Loops verhindern. Hier ist somit alles korrekt.
Die ursprüngliche Mail wurde aufgrund der DMARC Richtlinie abgelehnt und kam zurück. Jedoch gibt es keine Mailbox zu dem Absender postmaster@ und es kam zu dem Fehler "Sorry, no mailbox here by that name.". Die ursprüngliche Mail wurde von dem Nutzer mit der UID 1020 erzeugt. War
Subject: Rejected: Some Subject
der original Betreff? Ist dies eine Test-Mail gewesen? Oder Spam?
Und wie handhabt ihr das mit DMARC bei Nutzung der Subdomain?
Gar nicht. Wozu auch? DMARC nutzt DKIM und SPF. Bei SPF wird die Domain des Envelope-Sender geprüft, bei DKIM wird die Mail signiert. Dies hilft bei der Erkennung von Manipulation der Mail und Authentifizierung des Absenders. DMARC erweitert dies um Richtlinien und Berichte. Ein guter Artikel dazu findet sich auf easydmarc.com.
Das Einzige was ich bisher festgestellt habe, was relevant ist, ist ein SPF für den Hostnamen von pd-admin. Bei Weiterleitungen wird durch SRS der Envelope-Sender angepasst. Dann steht dort @sub.example.org. Der Empfänger prüft bei SPF dann diese sub.example.org. Bei Weiterleitungen an zum Beispiel Gmail macht ein fehlender SPF dann Probleme. Lösen lässt sich dies durch Setzen von sub IN TXT v=spf1 a -all in der Zone von example.org.
Kann ich die Subdomain (sub.example.org), die ich für die pd-admin Installation nutze ("Hostname für pd-admin") selbst regulär in pd-admin anlegen und verwalten?
Falls JA würde ich einen separaten DKIM Eintrag für sub.example.org erzeugen und nutzen (sofern die Mail Daemon Mails signiert auch werden!?).
Falls NEIN kann ich ja nur die Subdomain bei DMARC ignorieren, also alles erlauben.
Was genau soll denn erreicht werden? Ich weiß gar nicht, ob man sub.example.org anlegen kann. Vermutlich schon. Ich gehe aber davon aus, dass dies eher zu (neuen) Problemen führen würde. Bounce Mails werden nicht signiert. Die DKIM Signierung erfolgt durch qmail-remote, welches für die Zustellung von Mails an externe Hosts ist.
Dann wäre es wohl besser in dem Skript die Zeile raus zu nehmen, damit der Symlink nicht überschrieben wird. Hilft natürlich erst einmal nur bis zum nächsten Update, aber besser als jede Woche Probleme durch das Überschreiben zu haben.
Mich wundert dass das noch niemand sonst aufgefallen ist.
Ich hab auf einem Rocky 8 Server nachgeschaut. Dort tritt das Problem auch nicht auf. Scheint mir erst einmal ein Rocky 9 Problem zu sein.
Mit der curl Version aus der Serverumgebung sollte dies nicht auftreten. Da die Version auch immer aktuell ist, würde ich als workaround vorschlagen /usr/local/pd-admin2/bin mit vorne in die PATH Variable aufzunehmen. Dann funktioniert curl korrekt.
