Beiträge von Sumeragi

Es scheint ja prinzipiell zu funktionieren, nur eben bei einzelnen Domains nicht. Schwer zu sagen was das Problem sein könnte. Steht ggf. etwas dazu im error_log?

Zitat von Stefan3411

Die IP gehört zu meinem Mailserver. Also kommt die Mail schonmal dort an. Nur der Server nimmt sie nicht an.

Dann sollte man ja wissen, warum die Mail nicht angenommen wird...

Zitat von Stefan3411

85.93.88.96_failed_after_I_sent_the_message./Remote_host_said:_554_5.7.1_This_message_does_not_meet_our_delivery_requirements

Die Fehlermeldung ist sehr generisch. Die IP gehört zu velia.net Internetdienste GmbH. Eventuell kann man dort nachfragen.

Ansonsten würde ich prüfen, ob für den Hostnamen ein SPF gesetzt ist. Einige Anbieter lehnen Mails von Hostnamen ohne SPF ab.

Es gibt eine Audit Tabelle, die man dazu abfragen kann. Vielleicht kommt dadurch auf den Fehler.

mysql> use vadmin;
Database changed
mysql> select * from audit where `function` = 'plans.change' \G
[...]
"todo" : "plans.change",
"services" : "0",
"cron_per_hour" : "10",
"domains" : "1",
"mysql" : "10"
}


function: plans.change
ts: 2024-12-18 11:40:41
91 rows in set (0,01 sec)

Zitat von Stefan3411

Die Mails laufen nicht über pdadmin. Ich habe gesehen ich kann den MX für einzelne Domains ausschalten. Kann ich das auch irgendwo global ausschalten?

Man kann nur unter "Einstellungen" => "Serverkonfiguration" => "Mail" die Option "Voreinstellung für "Mailserver einrichten" ein- oder ausschalten. Wenn dies ausgeschaltet ist, wird beim Anlegen einer Domain kein MX eingerichtet.

Zitat von Stefan3411

Da habe ich überall MX ausgeschaltet. Leider bleibt das ohne einen Effekt

Gibt es weiterhin die gleichen Einträge im maillog?

Zitat von Stefan3411

Das sieht ja schonmal nicht schlecht aus, qmail ist gestartet oder? Aber warum 6x?

Jedes Mal wenn eine Verbindung zu qmail aufgebaut wird, wird ein qmail Prozess gestartet. Das kann durch eine eingehende Mail sein. Oder auch ein Port Scanner. Die Einträge sind daher völlig normal.

Je nachdem wie viel auf dem Server los ist, kann tail alleine zu viel ausgeben. Ich würde

tail -f /var/log/maillog | grep qmail

nehmen und somit die Ausgabe filtern. Denn zum Beispiel die dovecot Einträge braucht man ja nicht. Wobei die Angabe des Logs von Betriebssystem zu Betriebssystem unterschiedlich sein kann.

Ausschau halten sollte man dann nach solchen Zeilen

Dec 17 16:16:49 server qmail[2454778]: 1734448609.607027 new msg 13491921
Dec 17 16:16:49 server qmail[2454778]: 1734448609.607077 info msg 13491921: bytes 539 from <postmaster@server> qp 3159965 uid 1001

Ich würde zum Ausführungszeitpunkt einmal im error_log und im Mail Log schauen. Wenn eine Mail generiert und versandt wird, sollte die auf jeden Fall im Mail Log auftauchen.

Zitat von tbc233

Kurzum, ich bin auch der meinung dass es ohne externe Lösung nicht mehr geht. Bin da selbst seit vielen Jahren recht zufrieden mit den Spamexperts.

Die Lösung wäre aber je Domain einzurichten. Was machen Administratoren mit 100+ Domains je Server? Da wäre der Aufwand vermutlich sehr hoch.

Hinzu kommt, dass es eben ein externer Dienst mit Datenverarbeitung ist. Wo stehen die Server? Wie ist der Datenschutz geregelt? Das kann für den einen oder anderen Kunden ein wichtiges Kriterium sein.

Spamassassin ist meist nur so gut wie die DNSBL, die konfiguriert sind. Das Problem an den Listen ist, dass die eine IP auflisten, wenn bereits mehrfach Spam versandt wurde. Wenn man Pech hat, ist man dann immer einer der ersten Betroffenen.

Auch etwas Off Topic: In 2022 wurde /opt/pdadmin/etc/rbl.conf eingeführt. Dort kann man eine DNSBL angeben. Zum Beispiel zen.spamhaus.org. Dann wird die IP während des greylisting geprüft und bei einem Treffer während des SMTP Dialogs abgelehnt. Die Mail wird somit gar nicht erst angenommen. Dies könnte man ergänzend zu spamassassin einsetzen.

Zurück zum Thema: Spamassassin 4.0 bringt einiges an Änderungen mit sich. Eventuell kann nicht "Mal eben" umgestellt werden.

PDA: 4.125

SE: 8-0.455

OS: Oracle Linux 8

Ich habe folgenden Filter erstellt:

require ["enotify"];
# rule:[enotify]
if true
{
notify :importance "2" :message "New Message received." "mailto:xyz@somedomain.com";
}

Wenn nun einem Mail eintrifft, wird an xyz@somedomain.com folgende Mail versandt:

[...]
X-Sieve: Pigeonhole Sieve 0.5.21.1 (4905e73)
Message-ID: <dovecot-sieve-1733953974-73072-0@server>
Date: Wed, 11 Dec 2024 22:52:54 +0100
Subject: New Message received.
From: Postmaster <postmaster@server>
To: xyz@somedomain.com
Auto-Submitted: auto-notified; owner-email="sender@server"
Precedence: bulk
X-Priority: 3 (Normal)
Importance: Normal
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Notification of new message.

Im Subject taucht nun die definierte Nachricht auf. Bei ":message" würde ich jedoch annehmen, dass dies im Mail Body auftauchen sollte. Zumal in Roundcubemail dies auch als "Nachrichtentext" angegeben ist. Dort hat man eine Textbox und kann Zeilenumbrüche eingeben. Zeilenumbrüche im Subject wären nicht RFC konform.

Die Dokumentation ist auch eher knapp: https://doc.dovecot.org/2.3/co…sieve/extensions/enotify/

Hat jemand damit Erfahrung? Ich habe auch mal bei dovecot das Debugging eingeschaltet. Dies gab aber keine Hinweise zur Ausführung von enotify. Wird ":message" missverstanden oder liegt hier ein Fehler vor.

Die Frage ist ja, wo es knallt. In pd-admin, in der Datenbank, an einer anderen Stelle? Die Schwierigkeit ist nun Mal Fehler korrekt abzufangen und dann auch eine passende Fehlermeldung auszugeben. Und Fehlerbehandlung kann durchaus sehr aufwändig sein. Für alles was nicht definiert wird, gibt es dann eine generische Meldung 🤷

Aber wie soll etwas besser werden, wenn keinerlei Informationen geteilt werden?

Es geht ja auch keiner mit seinem Auto zur Werkstatt und sagt "Da ist was nicht in Ordnung, mach Mal.". Denn das würde dann teuer werden. Man versucht das Problem möglichst genau zu beschreiben, damit der Mechaniker das Problem gezielt angehen kann. Dann wird es auch nicht so teuer 😉

Man könnte jetzt überall unglaubliche oder falsche Werte eintragen und so einen Fehler triggern. Aber ist das dann auch der gleiche Fehler wie beim Threadstarter? Oder ist das ein anderer Fehler?

Dem Problem käme man sicher schneller auf die Spur, wenn man jetzt wüsste welche Angaben zuvor gemacht wurden und welche Angaben jetzt aktiv sind. Was soll man denn nun testen, um das Problem zu reproduzieren? Wurde ein zu niedriger Wert angegeben? Wurde eine Fehleingabe gemacht? Eine konkrete Fehlermeldung kann es ja nur zu einem konkreten Fehler geben.

Ist mir nicht bekannt. Gibt es bei den Versuchen Einträge unter /usr/local/pd-admin2/logs/error_log?

Und auch wenn der Server frisch installiert ist, wären Angaben zu den Versionen, der verwendeten Reihe und das Betriebssystem immer wünschenswert und hilfreich

Der Proof of Concept aus dem GitHub issue ist ja

# cat /proc/[child pid]/status |egrep '^(Groups|Uid|Gid)'
Uid:    1000    1000    1000    1000
Gid:    1000    1000    1000    1000
Groups:    0

Sprich man meldet sich per FTP an und hat dann durch "Groups: 0" root Berechtigungen.

Bei meinem Test sieht das dann so aus:

$ cat /proc/1754666/status | egrep "Gid|Groups"
Gid:    1023    1023    1023    1023
Groups: 1023

Der Nutzer hat hier nicht die Gruppenberechtigungen von root. Somit scheint die proFTPd Version in der Serverumgebung nicht betroffen zu sein.

Bei mir ist in der run Datei keine Angabe zur Path Variable:

$ cat /service/apache24/run
#!/bin/bash


if [ ! -e "/etc/real-hostname" ]; then
hostname $(/opt/pdadmin/bin/hostname.pl)
else
hostname $(cat /etc/real-hostname)
fi


killall -9 httpd 2>&1 >/dev/null
rm /usr/local/pd-admin2/httpd-2.4/logs/httpd.pid
ulimit -n 64000
cmd=(
exec /usr/local/pd-admin2/httpd-2.4/bin/httpd
-D NO_DETACH
-DSSL
)
"${cmd[@]}"

Ich würde die Variable dort auch nicht explizit setzen. Wenn man irgendwann Mal die PATH Variable ändert muss man immer daran denken diese auch beim Apache zu ändern.

Bei beiden Befehlen ist keine php.ini angegeben. Imagemagick muss jedoch explizit als Extension in der php.ini angegeben werden. Ohne wird dann auch kein imagemagick.so geladen. 🤷

Woher kommt die Annahme, es gäbe kein HEIC Support?

$ php -i | grep -iE "heic|php version"
PHP Version => 8.2.25
PHP Version => 8.2.25
ImageMagick supported formats => 3FR, 3G2, 3GP, A, AAI, AI, APNG, ART, ARW, AVI, AVIF, AVS, B, BGR, BGRA, BGRO, BMP, BMP2, BMP3, BRF, C, CAL, CALS, CANVAS, CAPTION, CIN, CIP, CLIP, CMYK, CMYKA, CR2, CR3, CRW, CUR, CUT, DATA, DCM, DCR, DCX, DDS, DFONT, DNG, DPX, DXT1, DXT5, EPDF, EPI, EPS, EPS2, EPS3, EPSF, EPSI, EPT, EPT2, EPT3, ERF, FAX, FILE, FITS, FLV, FRACTAL, FTP, FTS, G, G3, G4, GIF, GIF87, GRADIENT, GRAY, GRAYA, GROUP4, H, HALD, HDR, HEIC, HEIF, HISTOGRAM, HRZ, HTM, HTML, HTTP, HTTPS, ICB, ICO, ICON, IIQ, INFO, INLINE, IPL, ISOBRL, ISOBRL6, JNG, JNX, JPE, JPEG, JPG, JPS, JSON, K, K25, KDC, LABEL, M, M2V, M4V, MAC, MAGICK, MAP, MASK, MAT, MATTE, MEF, MIFF, MKV, MNG, MONO, MOV, MP4, MPC, MPEG, MPG, MRW, MSL, MSVG, MTV, MVG, NEF, NRW, NULL, O, ORF, OTB, OTF, PAL, PALM, PAM, PANGO, PATTERN, PBM, PCD, PCDS, PCL, PCT, PCX, PDB, PDF, PDFA, PEF, PES, PFA, PFB, PFM, PGM, PGX, PICON, PICT, PIX, PJPEG, PLASMA, PNG, PNG00, PNG24, PNG32, PNG48, PNG64, PNG8, PNM, POCKETMOD, PPM, PS, PS2, PS3, PSB, PSD, PTIF, PWP, R, RADIAL-GRADIENT, RAF, RAS, RAW, RGB, RGBA, RGBO, RGF, RLA, RLE, RMF, RW2, SCR, SCREENSHOT, SCT, SFW, SGI, SHTML, SIX, SIXEL, SPARSE-COLOR, SR2, SRF, STEGANO, SUN, SVG, SVGZ, TEXT, TGA, THUMBNAIL, TIFF, TIFF64, TILE, TIM, TTC, TTF, TXT, UBRL, UBRL6, UIL, UYVY, VDA, VICAR, VID, VIDEO, VIFF, VIPS, VST, WBMP, WEBM, WEBP, WMV, WPG, X3F, XBM, XC, XCF, XPM, XPS, XV, Y, YCbCr, YCbCrA, YUV

Wenn man ältere PHP Versionen beibehält, zieht man Leichen mit womöglich gefährlichen Sicherheitslücken mit. Und gerade bei kritischen Sicherheitslücken sollte es nicht unbedingt einem Endkunden überlassen werden zu reagieren.

Warum sollte man Minor Versionen weiter mit schleppen? Sollte es mit einer Minor Version geben, wäre der richtige Weg die Anwendung zu patchen.

Zitat von Revolution

Leider trifft es nicht einmal Jahre, denn bisher sind es nicht 6 Jahre, sondern schon 2x6 Jahre, also ein Dutzend Jahre. 👀

Was ist denn genau das Problem?

Zitat von monderka

echo "" | openssl s_client -servername server17.onit4u.de -connect server17.onit4u.de:25 | openssl x509 -noout -dates

Zitat von monderka

echo "" | openssl s_client -servername server17.onit4u.de -connect server17.onit4u.de:587 | openssl x509 -noout -dates

Die Befehle sind falsch. Auf Port 25 und 587 kommt nicht TLS, sondern STARTTLS zum Einsatz. Es muss dabei noch "-starttls smtp" ergänzt werden:

echo "" | openssl s_client -servername server17.onit4u.de -starttls smtp -connect server17.onit4u.de:587 | openssl x509 -noout -dates