Nachvollziehbarkeit von EMail Anlieferungen

grufo 2025-12-26 15:15:17 UTC #1

Problem/Frage/Anregung:

Ich habe aktuell des Problem gehabt dass mein Mailserver von einer chinesischen IPV6 Adresse innerhalb kürzester Zeit jede Menge Mails injiziert bekommen hat und diese vom Zielsystem korrekter weise abgelehnt wurden. Das führte zu vielen undelivered Nachrichten, was weiter mal nicht so schlimm wäre.

Jetzt würde ich aber gerne nachvollziehen wie der Spammer von seiner IPV6 Adresse aus die Mails in das Mailsystem rein bekommen hat. Der übliche Weg wäre jetzt mal ein genauer Blick auf die Logfiles.

docker logs egroupware-smtp
und
docker logs egrouware-mail

liefern allerdings nur bei ausgehenden Mails IP Adressen. Alles Eingehende steht mit der IP Adresse des Docker Containers 172.20.0.1 im Logfile und ist somit nicht wirklich aussagekräftig.

“ss -6 -tnp” im Hostsystem hat mir die established Verbindung angezeigt bis ich den Störenfried auf IP Ebene ausgesperrt habe.

Da docker-proxy den SMTP Port aber in den Container übersetzt und somit keine öffentlichen IP Adressen mitliefert, kann man in den Logfiles von Postfix hier nichts finden.

Wäre es hier nicht besser den SMTP Port zu exponieren so dass die IP Adressen auch in den Logfiles zu finden sind?

Welche Möglichkeiten gibt es bei EGroupware nachzuvollziehen wie die E-Mails versendet werden konnten?

Vielen Dank
Manfred

StefanU 2025-12-26 15:51:44 UTC #2

Hi Manfred.

Du meinst, jemand hat dein Mail-Server als Mail-Relay zum Versenden von Mail missbraucht?

Kann ich dir nicht wirklich was zu sagen.
Vielleicht @RalfBecker

Ich würde einem reinem SMTP unbedingt ein “Gateway-Service” davor setzen.
Siehe auch:

Stefan

grufo 2025-12-26 15:55:31 UTC #3

Als Relay wäre jetzt nicht ganz richtig weil der Server keine nicht authentifizierten Mails annimmt, da müsste es eigentlich beim SMTP Versand eine Authentifizierung geben. Leider lässt sich da nicht wirklich was nachvollziehen wenn alle Zugriffe mit der selben lokalen IP Adresse im Logfile stehen.

StefanU 2025-12-26 16:14:15 UTC #4

Sind die Mails an extern denn wirklich von deinem Server gekommen/versendet worden?
Stefan

grufo 2025-12-26 16:19:54 UTC #5

Ich denke schon - der bounce erfolgt laut Logfile direkt beim Versuch das Mail an den qq.com Server zuzustellen.

Dec 26 13:50:31 smtp postfix/smtp[9702]: 322895FB67: to=2831538986@qq.com, relay=mx3.qq.com[203.205.219.57]:25, delay=5.7, delays=2.8/0.02/0.93/2, dsn=5.0.0, status=bounced (host mx3.qq.com[203.205.219.57] said: 550 Mail content denied [MNWMIIZ6r68GVtBANC6Wx5/oFBWJmfyfPc02eHvHhehPoVJXXr9rg

grufo 2025-12-27 10:36:00 UTC #6

Heute wieder das gleiche Spiel, in kürzester Zeit über 4000 Mails mit undelivered Nachrichten eingelangt.

Hier Mail die Header Daten von einem der Mails die als undelivered zurück kommen:

Return-Path: <admin@…>
Received: from vessenged.com (egroupware.local [172.20.0.1])
by smtp… (Postfix) with ESMTP id 8C68265354
for 1304491246@qq.com; Sat, 27 Dec 2025 09:14:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=…; s=dkim;
t=1766826858;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type;
bh=kexd6m3Ke6SDmtsc/48yrCCiBzDJeWTVyqRAQVFa8k8=;
b=OE4E5vD98en2vXtZwKdiEMufWjhmC6jlroX3NqdhLOuUWS2unMrhFM5BjsohPoy4a+xL63
M7tXgvDaOVPX55mCHtTHkX0f485TPByIZKoM9Vhi9+DxkDbyE/eQWwsp2xB0bE0+SVCLoZ
Dy+x7sP6jnqqaDaXqmrcnTKDNas7Kw0=
Message-Id: <96f46b2ca395af9a05ef3ef931709906@…>
From: =?utf-8?B?ODg4OOWQr+WKqOmHkS1WaW5v?= <admin@…>
To: 1304491246 1304491246@qq.com
Subject: =?utf-8?B?RGFyaSBteSBzd2VldCBCZWF0cmljZe+8gSByZXBsaWVkIEV1?=
=?utf-8?B?dGhhbmFzaWHvvJ8gcGxheWZ1bGx5Py7qs6DrrqTsrKzth7TjhYfrnYQ=?=
Date: Sat, 27 Dec 2025 17:14:15 +0800
X-Priority: 3
X-Mailer: WTZEHYJUWPR FOXECPXM 594
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary=“a4fabf0d5d0c6bd6154358ee000cf551”

Received From “vessenged.com” ist offensichtlich gefälscht, die Domain ist nicht registriert.
Mit den Daten die hier mitgelogged werden kann man leider nicht wirklich was anfangen.

Die “admin@…” Adresse ist bei mir eigentlich nur eine Alias Adresse, damit sollte man eigentlich nicht versenden können. Laut Mail Log wurde die Mail aber wirklich mit dem Absender versendet.

Dec 27 09:14:17 smtp postfix/smtpd[1241]: 8C68265354: client=egroupware.local[172.20.0.1]
Dec 27 09:14:18 smtp postfix/cleanup[1249]: 8C68265354: message-id=<96f46b2ca395af9a05ef3ef931709906@…>
Dec 27 09:14:19 smtp postfix/qmgr[73]: 8C68265354: from=<admin@…>, size=6576, nrcpt=1 (queue active)
Dec 27 09:14:21 smtp postfix/smtp[1244]: 8C68265354: to=1304491246@qq.com, relay=mx3.qq.com[203.205.219.57]:25, delay=4.2, delays=1.8/0.01/0.87/1.5, dsn=5.0.0, status=bounced (host mx3.qq.com[203.205.219.57] said: 550 Mail content denied [MCFVzlKBg2Gfn5nUMhzk1V+XPUOekVIByHZ19x23LFC2T9L8CivHBUo940fOAbvV8Q== IP: 135.181.203.217]. https://service.mail.qq.com/detail/122/171. (in reply to end of DATA command))
Dec 27 09:14:21 smtp postfix/bounce[1253]: 8C68265354: sender non-delivery notification: 771F465356
Dec 27 09:14:21 smtp postfix/qmgr[73]: 8C68265354: removed

Kennwörter habe ich am Mailserver bereits geändert, mir stellt sich hier die Frage wie die E-Mail hier ins System kommt.
Kann es sein dass die Postfix Config per default das Absender Spoofing nicht verhindert?

Ich habe versucht die Postfix Config um folgende Zeilen erweitert:

smtpd_sender_login_maps = mysql:/etc/postfix/sql-sender-login.cf
smtpd_sender_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_authenticated_sender_login_mismatch

und in der sql-sender-login.cf Datei steht folgende Abfrage drinnen:

query = SELECT mail_value FROM egw_mailaccounts WHERE mail_type=3 AND mail_value="%s";

Leider klappt das nicht weil die postfix Version im Docker Container keine SASL kennt.

Dec 27 10:49:47 smtp postfix/smtpd[75]: warning: restriction `reject_authenticated_sender_login_mismatch’ ignored: no SASL support

Sehe ich das richtig dass hier SASL nicht im Einsatz ist und somit die Authentifizierung eines Absenders nicht verifiziert werden kann/wird? Also kann jeder mit meinem Absender über meinen Mailserver Mails versenden?

itwo 2025-12-27 16:03:18 UTC #7

Das ist wirklich eine seht gute Frage, kann es sein das Du ein verseuchten Client hast?
Ich hatte das vor langer Zeit mal bei einem Bekannten, kaum das Passwort in (damals) Outlook geändert schon ging es ein paar Stunden später wieder los. Die Schadenssoftware war direkt auf dem Client…

grufo 2025-12-27 18:14:56 UTC #8

Das kann ich definitiv ausschließen, die Verbindung sehe ich ja im ip6tables und sie kommt von extern von einer chinesischen Adresse. Blocke ich diese Adresse gehen auch keine Mails mehr raus.

RalfBecker 2025-12-27 18:32:20 UTC #9

Leider hast Du viel zu wenig Informationen gegeben, um da irgendetwas sagen zu können

Generell gibt es zwei Möglichkeiten:

der Angreifer kennt das Passwort eines Deiner Konten oder
Du erlaubst wegen einem Konfigurationsfehler das Relaying (ohne Authentifizierung)

Der Postfix in EGroupware Mail erlaubt normal das unauthentifizierte Senden nur auf dem Docker Netz, die Konfiguration kann man natürlich ändern …

Normal sollte das Postfix Log darüber Auskunft geben, welche IP Postfix beim Einliefern sieht (docker logs -f egroupware-smtp).

Wichtig das authentifizierte Senden erfolgt nicht direkt über den Postfix, sondern über den Dovecot der erst die Authentifizierung prüft und dann die Mail über den Postfix versendet.

Ralf

grufo 2025-12-27 18:57:59 UTC #10

Hallo Ralf,
ich würde ja gerne mehr Informationen geben - allerdings steht im egroupware-smtp log immer nur die eine 172.20.0.1 IP Adresse vom Docker drinnen und niemals eine externe.

Hier nochmal ein solcher Auszug aus dem Log:

Dec 27 09:08:51 smtp postfix/smtpd[1218]: disconnect from egroupware.local[172.20.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
Dec 27 09:08:51 smtp postfix/smtpd[1205]: 2F5AD6531A: client=egroupware.local[172.20.0.1]
Dec 27 09:08:51 smtp postfix/smtp[1215]: 4720F65345: to=2804487161@qq.com, relay=mx3.qq.com[203.205.219.57]:25, conn_use=2, delay=3.5, delays=1.6/0.03/0.29/1.5, dsn=5.0.0, status=bounced (host mx3.qq.com[203.205.219.57] said: 550 Domain frequency limited [MGdfb4XezrXZi9DIAnFgUCRvCc7Ovj5V73GBOong29Mdw2HsaK3ASJPDy+bBd6Rjsg== IP: 135.181.203.217]. https://service.mail.qq.com/detail/122/173. (in reply to end of DATA command))
Dec 27 09:08:51 smtp postfix/cleanup[1235]: 665BC65352: message-id=20251227090851.665BC65352@smtp.example.com
Dec 27 09:08:51 smtp postfix/bounce[1232]: 4720F65345: sender non-delivery notification: 665BC65352
Dec 27 09:08:51 smtp postfix/qmgr[73]: 665BC65352: from=<>, size=13956, nrcpt=1 (queue active)
Dec 27 09:08:51 smtp postfix/qmgr[73]: 4720F65345: removed
Dec 27 09:08:51 smtp postfix/lmtp[1231]: 665BC65352: to=ml@example.com, orig_to=admin@example.com, relay=mail[172.20.0.5]:24, delay=0.19, delays=0.05/0.02/0.01/0.11, dsn=2.0.0, status=sent (250 2.0.0 ml@example.com SGElHSOiT2lCNgAAj6DK4A Saved)
Dec 27 09:08:51 smtp postfix/qmgr[73]: 665BC65352: removed
Dec 27 09:08:51 smtp postfix/smtpd[1227]: connect from egroupware.local[172.20.0.1]

Das mit dem Kennwort kann man vermutlich ausschließen sonst wäre es nach dem Ändern des Kennwort nicht noch einmal passiert.

Wenn ich mich von außen via telnet zum Mailserver verbinde und anschließend die üblichen Befehle zum absenden eines Mails eingeben dann sieht das wie folgt aus:

telnet mailserver.example.com 25
Trying 35.117.23.127…
Connected to mailserver.example.com.
Escape character is ‘^]’.
220 mailserver.example.com ESMTP Postfix
ehlo example.com
250-mailserver.example.com
250-PIPELINING
250-SIZE 35000000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 CHUNKING
mail from: admin@example.com
250 2.1.0 Ok
rcpt to: ml@example.com
250 2.1.5 Ok

Die Mail wird also ohne Authentifizierung von einer externen IP Adresse mit einer internen Mail Adresse akzeptiert. Gebe ich als Empfänger eine externe Mail Adresse an wird die Mail mit “Relay access denied” abgelehnt.

Das erklärt also nicht warum die Mails an die qq.com Domain funktionieren. Allerdings sollte auch niemand auf dem Mailserver ohne Authentifizierung Mails mit einem internen Absender an eine Interne Adresse schicken können.

Das wären die Einstellungen die von der Default Postfix Config abweichen:

alias_database =
command_directory = /usr/sbin
compatibility_level = 2
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5
header_size_limit = 4096000
html_directory = no
inet_protocols = ipv4
lmtp_dns_support_level = disabled
local_transport = lmtp:mail:24
mail_owner = postfix
maillog_file = /dev/stdout
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
message_size_limit = 35000000
meta_directory = /etc/postfix
milter_default_action = accept
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
milter_protocol = 6
mydestination = localhost mysql:/etc/postfix/sql-domains.cf
myhostname = mailserver.example.com
mynetworks_style = subnet
newaliases_path = /usr/bin/newaliases
non_smtpd_milters = inet:35.117.23.127:11332
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix/readme
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
shlib_directory = /usr/lib/postfix
smtpd_milters = inet:35.117.23.127:11332
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/certificate.pem
smtpd_tls_dh1024_param_file = /etc/postfix/dh.pem
smtpd_tls_key_file = /etc/postfix/certificate.key
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_security_level = may
smtputf8_enable = no
tls_medium_cipherlist = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
tls_preempt_cipherlist = no
unknown_local_recipient_reject_code = 550
virtual_alias_maps = mysql:/etc/postfix/sql-aliases.cf
virtual_mailbox_maps = mysql:/etc/postfix/sql-mailboxes.cf

Wenn du mir sagst welche Informationen ich noch liefern soll, dann mache ich das gerne!

RalfBecker 2025-12-27 18:59:22 UTC #11

Welcher Container ist das?

Die authentifizierten Mails werden - wie gesagt - über den Dovecot gesendet.

Die tatsächliche externe IP Adresse zu loggen, hängt sehr von der Architektur Deiner Installation ab. Du könnest an einer Stelle die die tatsächlichen Adressen sieht, einen Nginx laufen lassen, und den per Proxy Protocol die IP Adresse mitschicken lassen, dann kann Dovecot oder Postfix (entsprechend konfiguriert!) diese verwenden.

Ralf

RalfBecker 2025-12-27 19:04:26 UTC #12

Das ist die normale Funktion eines Mailservers, er nimmt auf Port 25 Mails ohne Authentifizierung für die eigene(n) Domain(s) an

Der Authentifizierte Submission Port ist bei EGroupware-Mail 465 (TLS) bzw. 587 (StartTLS), dabei sprichst Du mit dem Dovecot, da der Postfix keine Authentifizierung macht.

Ralf

grufo 2025-12-27 19:04:51 UTC #13

Das ist die IP Adresse der Docker Network Bridge:

{
    "Name": "egroupware-docker_default",
    "Id": "6e4338be84973d7fe9da5b34da9b418a83dfc2e1246f029c0b07d52c49f6aabb",
    "Created": "2021-07-06T13:57:57.791893601+02:00",
    "Scope": "local",
    "Driver": "bridge",
    "EnableIPv4": true,
    "EnableIPv6": false,
    "IPAM": {
        "Driver": "default",
        "Options": null,
        "Config": [
            {
                "Subnet": "172.20.0.0/16",
                "Gateway": "172.20.0.1"
            }
        ]
    },
    "Internal": false,
    "Attachable": true,
    "Ingress": false,
    "ConfigFrom": {
        "Network": ""
    },

grufo 2025-12-27 19:07:38 UTC #14

Das ist nur zum Teil korrekt, von eigenen Mail Adressen sollte ein Mailserver Mails für die eigene Domain nur annehmen wenn die User vorher authentifiziert wurden - sonst kann jeder von extern im Namen des Bundeskanzlers ans Parlament Mails verschicken…

Hier klappt das aber über den Port 25 und das sollte nicht sein.

grufo 2025-12-27 19:13:09 UTC #15

Was würde dagegen sprechen den SMTP Port 25 zu exponieren?
Dann würde die externe IP Adresse direkt im Docker aufschlagen, auch ganz ohne Proxy.
Habe ich hier einen Denkfehler oder sollte das so auch möglich sein?

RalfBecker 2025-12-27 19:19:52 UTC #16

Das hängt sehr von Deine Architektur ab, generell sieht ein Container mit bridged Networking immer nur die Bridge und nicht die externe Adresse, falls der Host diese überhaupt sieht, was davon abhängt wie er angebunden ist.

Wenn Du für die eigene(n) Domain(s) den Port 25 ausschließen, bzw. nur Authentifizierte Absender erlauben willst, hier eine Anleitung von La Chat von Mistral (die bestimmte IP Adresse wäre die des Dovecot Containers):

Um Postfix so zu konfigurieren, dass es E-Mails mit Absenderadressen deiner eigenen Domain(en) nur von einer bestimmten IP-Adresse annimmt, kannst du die smtpd_sender_restrictions-Direktive in der Postfix-Konfiguration verwenden. Hier ist eine Schritt-für-Schritt-Anleitung:

1. Postfix-Konfiguration anpassen

Öffne die Hauptkonfigurationsdatei von Postfix, normalerweise /etc/postfix/main.cf:

sudo nano /etc/postfix/main.cf

Füge oder bearbeite folgende Zeilen:

smtpd_sender_restrictions =
    check_sender_access hash:/etc/postfix/sender_access,
    reject

2. `sender_access`-Datei erstellen

Erstelle eine Datei /etc/postfix/sender_access mit folgendem Inhalt:

# Erlaube Absenderadressen deiner Domain nur von der IP 192.0.2.1
@deine-domain.de   OK
# Erlaube alle anderen Absenderadressen nur von der IP 192.0.2.1
!@deine-domain.de   reject_unless_client_address=192.0.2.1

Erklärung:

@deine-domain.de OK: Erlaubt Absenderadressen von @deine-domain.de generell (wird später durch die nächste Regel eingeschränkt).
!@deine-domain.de reject_unless_client_address=192.0.2.1: Lehnt Absenderadressen von @deine-domain.de ab, es sei denn, die Verbindung kommt von der IP 192.0.2.1.

3. `sender_access`-Datei kompilieren

Postfix verwendet eine kompilierte Version der Datei. Führe folgenden Befehl aus:

sudo postmap /etc/postfix/sender_access

4. Postfix neu laden

Lade die Postfix-Konfiguration neu, damit die Änderungen wirksam werden:

sudo systemctl reload postfix

5. Testen

Teste die Konfiguration, indem du E-Mails von verschiedenen IPs mit Absenderadressen deiner Domain sendest. Nur E-Mails von der erlaubten IP (192.0.2.1) sollten akzeptiert werden.

Wichtig

Ersetze deine-domain.de mit deiner tatsächlichen Domain.
Ersetze 192.0.2.1 mit der IP-Adresse, von der aus Absenderadressen deiner Domain akzeptiert werden sollen.
Falls du mehrere Domains hast, wiederhole die Regeln für jede Domain.

Falls du weitere Anpassungen oder spezifischere Regeln benötigst, lass es mich wissen!

RalfBecker 2025-12-27 19:24:06 UTC #17

Da ist ein kleiner Logischer Fehler drin, den die AI Sachen so gerne machen

Du willst die restriction für Deine Domain(s)…

Ralf

grufo 2025-12-27 19:24:43 UTC #18

So ähnliche Anleitungen habe ich schon durchgearbeitet, bin aber immer daran gescheitert dass in dem Docker Container leider beim Postfix kein hash und kein lmdb oder sonst was möglich ist. Letzen Endes habe ich es dann mit mysql probiert weil das ja schon von egroupware verwendet wird. Damit konnte ich dann aber auch nur erreichen dass alle Mails abgelehnt werden, was mich nicht weiter gebracht hat.

Das “reject_authenticated_sender_login_mismatch” würde wohl helfen, funktioniert aber nicht weil im egroupware-smtp Docker keine SASL Login Prüfung verfügbar ist - siehe früherer Post weiter oben.

RalfBecker 2025-12-27 20:00:07 UTC #19

Nimmst Du texthash:
A table that produces similar results as hash: files, except that you don’t have to run the postmap(1) command before you can use the file, and that texthash: does not detect changes after the file is read. The lookup table name is “texthash:filename”, where the file name is taken literally; no suffix is appended.

Ralf

grufo 2025-12-29 08:41:49 UTC #20

Hallo Ralf,
mit hashtext habe ich es nicht probiert.
Das würde mein Problem aber leider auch nicht wirklich lösen, reject_authenticated_sender_login_mismatch meldet ja dass keine Authentifizierung mit SASL genutzt wird und daher greift das Setting nicht.
Wenn ich die Config korrekt verstehe dann nutzt ihr Dovecot für Port 465 und 587 und der übergibt die Mail dann an Postfix nachdem sie dort Authentifiziert wurde. Daher sieht Postfix keine SASL Authentifizierung und der reject_authenticated_sender_login_mismatch greift nicht.
Die Regeln die ich jetzt auf Port 25 setze greifen also auch für die Anlieferung via Dovecot, sobald ich hier auf Port 25 Mails mit eigener Absende-Domain ablehne, werden diese auch wenn sie authentifiziert via Dovecot kommen abgelehnt.
Ich habe da jetzt noch keine Variante gefunden die hier funktioniert und von extern angelieferte Mails mit eigenen Absender ablehnt aber von Dovecot authentifizierte Mails zulässt.
Schöne Grüße
Manfred