Beiträge von Denny

Das ist die Frage, woher sie kommen spielt keine rolle, vorher kamen Sie vom Mailserver direkt jetzt vom PMG, das hat irgendwas mit der Warteschleife zu tun.

 	Heute, 08:22:59 (2; Inbound pipe: b1gMail pipe rejected message data (keep-alive: 1).)

Wenn ich jetzt "Alle abarbeiten klicke" werden alle zugestellt. Komisch wie ne Verzögerung, ich schau mal eben ins logging. root@mail ~ # systemctl

Jun 08 08:45:39 mail.skymail.de bms-queue[2563633]: PHP Deprecated:  mysqli_real_escape_string(): Passing null to parameter #2 ($string) of type string is deprecated in /var/www/web0/htdocs/serverlib/db.class.php on line 78
Jun 08 08:46:06 mail.skymail.de bms-queue[2563631]: PHP Deprecated:  mysqli_real_escape_string(): Passing null to parameter #2 ($string) of type string is deprecated in /var/www/web0/htdocs/serverlib/db.class.php on line 78
Jun 08 08:46:58 mail.skymail.de bms-queue[2563967]: PHP Deprecated:  mysqli_real_escape_string(): Passing null to parameter #2 ($string) of type string is deprecated in /var/www/web0/htdocs/serverlib/db.class.php on line 78
Jun 08 08:47:06 mail.skymail.de bms-queue[2563930]: PHP Deprecated:  mysqli_real_escape_string(): Passing null to parameter #2 ($string) of type string is deprecated in /var/www/web0/htdocs/serverlib/db.class.php on line 78

soll ich mal keep alive abschalten?

Zitat von patrick

Wenn da alle Mails angenommen werden auch für nicht-existente lokale Adressen, hast du ein Problem. Zeig doch mal die Subnetz- und DNSBL-Regeln.

Das Problem ist gelöst, da gab es tatsächlich wie im anderen Thread beschrieben keine Einschränkungen daher nahm der alles an

Zitat von patrick

Das ergibt m.E. mehr Sinn, ja. Greylisting usw sollte ja schon Proxmox machen.

Ich hatte jetzt die Doku gefunden, wenn PMG als Vertrauenwürdig eingestellt ist, dann macht er gar keine Userprüfung (immer 250) und lässt alles durch. Ich wusste nicht, dass die Userprüfung mit einer Einschränkung der Verbindung kommt. Jetzt klappt alles und die gelöschten User weden direkt in PMG abgelehnt, somit keine Nullsender mehr. Auch der Hinweis mit der Gruppensignatur in der Doku war super wichtig, seitdem keine DKIM Probleme mehr.

Das Problem tritt jetzt vor allem bei einem Dienst mit der neuesten Version 7.2 RC2 auf ich muss immer manuell ein paar mails abholen, etwas komisch, da sind auch ruguläre mails dabei keine Nullsender oder sowas, einige Bounces aber ich glaube der Inhalt ist es nicht eher eine Verzögerung der QUEUE

Danke für die Doku, ist gold wert

Zitat von patrick

Wie sieht denn deine Proxmox-Config aus?

Ich hoffe, du hast den nicht einfach als vertrauenswürdig in b1gMailServer klassifiziert und lässt den alles annehmen; dann kann der nämlich tatsächlich alles einkippen und Backscatter und jede Menge andere Probleme sind vorprogrammiert.

Fehler gefunden:

Habe gerade in der Doku gesehen, dass ich eventuell den PMG nicht als vertrauenwürdig klassifizieren sollte, jetzt klappts mit der Empfängerverifizierung.

Grey Listing und IP Ban deaktivieren als Vertrauensstufe?

Ich muss das hier nochmal aufgreifen, der B1gmailserver hat aktuell keine Usererkennung. Proxmoxx stellt dann einfach alles gültige an b1gmailserver zu und b1gmailserver wird dann zum Backscatter und versucht den Ballast loszuwerden , ich kämpfe die ganze Zeit mit Outlook, jemand ne Idee muss ich proxmox wirklich auch zum Versand nutzen?

	 	ID / Typ:	339283280 (14390D50) (Ausgehende E-Mail)
 	Datum:	Heute, 09:16:06
 	Größe:	34,64 KB
	Von:	< - >
	An:	<bounces@bounce.wahrse.com>
 	Zustell-Versuch(e):	1
 	Letzter Zustell-Versuch:	Heute, 09:17:06 (2; imap.com: Timeout while connecting socket (1))
	Eingeliefert für:	System
	SMTP-User:	Unbekannt

Moin, ich habe ja nun schon fast 20 Jahre b1gmail im Einsatz, der Umstieg auf die OS Version ist bereits auf einem Projekt seit Version 7.4.1 im Einsatz.

Leider habe ich hier ein Problem mit der Warteschlange und mit Duplikat-Meldungen die ich sowohl in 7.4 als auch in 7.2 nicht habe.

Wie es aussieht handelt es ich hier um Bounces:

Message duplicate for <adresse@domain.at> (494787) detected (<0100019d0667682f-1cf6b381-4b95-495c-9d83-d514a532031f-000000@email.amses.com>), processing stopped

(mailbox.class.php:2513) Message duplicate for <adresse@domain.at> (652441) detected (<1032443376.13894.1773933754835@saved-search-application-57df9fbcd7-mk8z4>), processing stopped

Alles bounces ca. 500 am Tag...

Dier hängen dann auch gern mal in der Warteschleife.

Jetzt seit Umstellung auf proxmox als Filter habe ich noch mehr Dinger in der Warteschlage kleben.

Problem ist das b1gmailserver von außen keine Usererkennung hat

Warteschleife sieht jetzt immer so aus, die ist nie leer, weil die bounces nicht zugestellt werden können

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

 root@emg ~ # printf 'EHLO meinmailserver.de\r\nMAIL FROM:<probe@example.net>\r\nRCPT                                                                                                                                                                                                                                              TO:<definitivnichtvorhanden123456@server.de>\r\nQUIT\r\n' \
| openssl s_client -starttls smtp -connect mail.meinmailserver.de:25 -quiet
Connecting to 46.xxx.xx.xx
depth=2 OU=GlobalSign Root CA - R6, O=GlobalSign, CN=GlobalSign
verify return:1
depth=1 C=BE, O=GlobalSign nv-sa, CN=GlobalSign GCC R6 AlphaSSL CA 2025
verify return:1
depth=0 CN=*.server.de
verify return:1
250 8BITMIME
250-meinmailserver.emailn.de Pleased to meet you, proxmox.server.de [xxx.xxx.xxx.xxx]
250-SIZE 102400000
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250 8BITMIME
250 2.1.0 Return path OK
250 2.1.5 Recipient OK
221 mail.meinmailserver.de Closing connection

Er akzeptiert also erstmal jede Adresse egal ob sie existiert oder nicht.

Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Zitat von Loadbox

Sorry wenn ich das jetzt so raushaue!

wo muss das eingetragen werden bzw welche datei muss dafür verändert werden!

habe nämlich den selben fehler das emails nicht angezeigt werden erst nach dem der frame aktualisiert wurde

prüfe mal deine templates/modern/templatename/js/email.js

Moin,

leider nehmen die Zugriffe auf IMAP als ungeschütztes Protokoll zu, cred Angriffe werden immer zahlreicher und Passwörter sind durch leaks bekannt und werden dort einfach über Botnetze getestet. Ich weiß viel Zeit ist nicht, ich getraue mich ehrlich gesagt auch nicht an C++ ran obwohl ich die Stellen bereits identifiziert habe. Die eigentliche Idee war ja die Passwort/Salt Spalte umzubenennen und die PHP Logik anzupassen und dann die Orginalspalten mit generierten App Passwörtern zu füllen sofern der Kunde IMAP aktiviert. Aber das empfinde ich als zu großen Eingriff besser wäre hier die Logik in b1gmailserver direkt...zudem Wartung auch mist wenn es mal ein update gibt.

KI schlägt mir folgendes vor in b1gmailserver, ist mir alles zu riskant:

Empfohlenes Zielbild:

1. Hauptpasswort für IMAP komplett verbieten.
2. Beim Aktivieren von IMAP automatisch ein zufälliges App-Passwort erzeugen.
3. App-Passwort nur einmal im Klartext anzeigen (danach nie wieder).
4. In DB nur Hash speichern (Argon2id/bcrypt), plus created_at, last_used_at, revoked_at, label.
5. Optional mehrere App-Passwörter pro Kunde (Outlook, iPhone, Thunderbird), einzeln widerrufbar. -> näh

Das hat mir die KI ausgeworfen aber ich denke Patrick weiß besser was zu tun ist.

Umsetzungsvorschlag für b1gMailServer IMAP

1) IMAP-Hauptpasswort deaktivieren (LOGIN)
Datei: C:\xampp\htdocs\b1gMailServer-main\b1gMailServer-main\src\imap\nonauth.cpp
Funktion: IMAP::Login (ab Zeile ~38)
Ersetzen:
- Aktuelle SQL-Prüfung gegen bm60_users.passwort (Zeilen ~61, ~68, ~76) entfernen.
Neu:
- User + Gruppe + IMAP-Recht ohne Passwort laden.
- Aktive App-Passwörter aus bm60_imap_app_passwords laden (revoked_at IS NULL).
- strPass gegen password_hash (Argon2id/bcrypt) verifizieren.
- Bei Erfolg wie bisher DoLogin().

2) IMAP-Hauptpasswort deaktivieren (AUTHENTICATE)
Datei: C:\xampp\htdocs\b1gMailServer-main\b1gMailServer-main\src\imap\nonauth.cpp
Funktion: IMAP::Authenticate (ab Zeile ~174)
Ersetzen:
- Aktuelle SQL-Prüfung gegen bm60_users.passwort (Zeilen ~270, ~277, ~285) entfernen.
Neu:
- Gleiche Logik wie bei LOGIN: User laden, App-Hash prüfen, bei Erfolg DoLogin().

3) last_used_at pflegen
Datei: C:\xampp\htdocs\b1gMailServer-main\b1gMailServer-main\src\imap\nonauth.cpp
Nach erfolgreichem Login zusätzlich:
- UPDATE bm60_imap_app_passwords SET last_used_at=UNIX_TIMESTAMP() WHERE id=%d

4) TLS für IMAP-Login erzwingen
Datei: C:\xampp\htdocs\b1gMailServer-main\b1gMailServer-main\src\imap\nonauth.cpp
In Login() und Authenticate() am Anfang:
- if (!this->bTLSMode) -> "NO ... TLS required" und return
Referenz TLS-Flag:
- C:\xampp\htdocs\b1gMailServer-main\b1gMailServer-main\src\imap\imap.h (bTLSMode)

5) Hash-Verify-Funktion ergänzen
Dateien:
- C:\xampp\htdocs\b1gMailServer-main\b1gMailServer-main\src\core\utils.h
- C:\xampp\htdocs\b1gMailServer-main\b1gMailServer-main\src\core\utils.cpp
Neu:
- bool VerifyPasswordHash(const std::string &plain, const std::string &hash);
Implementierung mit Argon2id oder bcrypt.

6) Neue Tabelle für IMAP-App-Passwörter
SQL:
CREATE TABLE bm60_imap_app_passwords (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  user_id INT NOT NULL,
  label VARCHAR(100) NOT NULL,
  password_hash VARCHAR(255) NOT NULL,
  created_at INT NOT NULL,
  last_used_at INT NULL,
  revoked_at INT NULL,
  INDEX idx_user_active (user_id, revoked_at)
);

7) App-Passwort-Erzeugung + Einmalanzeige
Nicht im IMAP-C++-Server, sondern Web/Admin:
- Beim Aktivieren von IMAP automatisch App-Passwort erzeugen.
- Klartext nur 1x anzeigen.
- In DB ausschließlich password_hash + label + created_at + last_used_at + revoked_at speichern.

Zitat von Sebijk

Danke. KI generiert oder selbst geschrieben?

KI - ich arbeite momentan an einer neuen Seite da konnte ich das direkt auch mit meinem Testsystem reproduzieren. Läuft produktiv seit einer Woche, die Kunden haben sich auch alle positiv zurückgemeldet, bestes Zeichen^^

Ja, habe ich behoben, das Rendering habe ich über iframe.srcdoc gelöst

function initEMailTextArea(code)
{
	var iframe = EBID('textArea'), lastSize = 0, hasRendered = false;
	if(!iframe) return;

	var resolveDoc = function()
	{
		return iframe.contentDocument || (iframe.contentWindow && iframe.contentWindow.document) || null;
	};

	var renderIframeHTML = function()
	{
		if(!iframe) return null;

		// Firefox-safe: srcdoc bevorzugen (kein about:blank load-race)
		if('srcdoc' in iframe)
		{
			try { iframe.srcdoc = code; } catch(e) {}
			return resolveDoc();
		}

		// Fallback: document.write
		var d = resolveDoc();
		if(!d) return null;

		try {
			d.open();
			d.write(code);
			d.close();
		} catch(e) {}

		return d;
	};

	var resCB = function()
	{
		var d = resolveDoc();
		if(!d) { window.setTimeout(resCB, 500); return; }

		try
		{
			var h = 0;
			var el = d.getElementById('__bmMailText');

			if(el)
				h = el.clientHeight || 0;
			else if(d.documentElement)
				h = d.documentElement.scrollHeight || 0;

			var iframeHeight = iframe.offsetHeight || iframe.clientHeight || 0;

			if(h > lastSize + 60 && h > iframeHeight + 20)
			{
				iframe.style.height = (h > 140 ? (h + 60) : 200) + 'px';
				lastSize = h;
			}
		}
		catch(e) {}

		window.setTimeout(resCB, 500);
	};

	var cb = function()
	{
		if(!iframe) return;

		// nur einmal rendern, danach kein reliance auf load-event
		if(!hasRendered)
		{
			var rendered = renderIframeHTML();
			if(!rendered) { window.setTimeout(cb, 50); return; }
			hasRendered = true;
			try { removeEvent(iframe, 'load', cb); } catch(e) {}
		}

		var d = resolveDoc();
		if(!d) { window.setTimeout(cb, 50); return; }

		var mm = function(event)
		{
			if(typeof(parent._hSepDragging) == 'undefined') return;
			if(!parent._hSepDragging && !parent._vSepDragging) return;

			if(parent.document.createEvent)
			{
				var ev = parent.document.createEvent('MouseEvents');
				ev.initMouseEvent('mousemove', true, true, window, 0,
					event.screenX, event.screenY,
					event.screenX - parent.diffScreenClientX,
					event.screenY - parent.diffScreenClientX,
					false, false, false, false, 0, null);
				parent.document.dispatchEvent(ev);
			}
		};

		var mc = function(event)
		{
			if(parent.document.createEvent)
			{
				var ev = parent.document.createEvent('MouseEvents');
				ev.initMouseEvent('mouseup', true, true, window, 0,
					event.screenX, event.screenY,
					event.screenX - parent.diffScreenClientX,
					event.screenY - parent.diffScreenClientX,
					false, false, false, false, 0, null);
				parent.document.dispatchEvent(ev);
			}
		};

		addEvent(d, 'mousemove', mm);
		addEvent(d, 'click', mc);

		resCB();
	};

	// alte WebKit/Opera-Logik behalten, aber immer cb einmal triggern
	if(/WebKit/i.test(navigator.userAgent) || /Opera/i.test(navigator.userAgent))
	{
		var _isLoaded = false;
		setInterval(function()
		{
			if(/loaded|complete/.test(document.readyState))
			{
				if(!_isLoaded) cb();
				_isLoaded = true;
			}
			else
				_isLoaded = false;
		}, 50);
	}
	else
		addEvent(iframe, 'load', cb);

	window.setTimeout(cb, 0);
}

Noch eine Frage dazu warum wurde memcached jetzt eigentlich deaktiviert, so wie ich das lesen kann funktioniert er unter 8.3 immer noch oder geht das nur intern nicht mehr. Ich bin dabei das gerade anzupassen vermutlich werde ich aber redis nehmen

Zitat von informant

ps: Denny warum baust du dir das nicht so wie du willst oder machst nen extra Thread dazu im Thema: gewünnschte Features oder so...?

Weil ich dachte, dass es auch mein Problem zielt mit dem fehlenden return-path....Diese Betrüger mit den angeblich echten Passwörtern verwenden noreply@domain.de (gefälschte E-Mail Adresse) und der Return-Path ist dann leer, das sowas überhaupt durchkommt ohne gültigen return-path, das Problem ist bei mir sehr aktuell und da kam dein Thread ohne weitere Informationen dazu, passte halt

Zitat von patrick

Ich verstehe leider nicht, was du damit bezwecken willst.

Er möchte gefälschte Mails blockieren, da der b1gMailServer aktuell keine vollwertige DMARC-Prüfung durchführen kann. Zusätzlich gibt es einige Punkte, die mir im Bereich SPF noch fehlen und die ich bereits angesprochen hatte.

SPF

Aktuell kommt es dazu, dass SPF auch dann abgelehnt wird, wenn große, legitime Absender sehr umfangreiche include:-Ketten verwenden und die SPF-Prüfung aufgrund von DNS-Lookup-Limits oder Timeouts fehlschlägt. In diesen Fällen wird der Versand fälschlich blockiert, obwohl der Absender korrekt konfiguriert ist.

Gleichzeitig wäre es sinnvoll, SPF none nicht mehr vollständig zu akzeptieren, sondern dieses Ergebnis zumindest als zusätzlichen Negativ- oder Ablehnungsfaktor zu berücksichtigen – insbesondere in Kombination mit weiteren Auffälligkeiten wie leerem Return-Path <> oder einem ungültigen bzw. auffälligen HELO/EHLO.

Das ließe sich gut kombinieren, etwa über Regeln wie:

• SPF-Status
• Return-Path
• HELO/EHLO
  Wenn mehrere dieser Kriterien gleichzeitig negativ sind, sollte eine Ablehnung erfolgen.

Schutz von IMAP, SMTP und POP (aus meiner Sicht noch wichtiger)

Noch wichtiger finde ich aktuell jedoch den Schutz der externen Schnittstellen (IMAP, SMTP, POP). Das BSI arbeitet derzeit an einem Maßnahmenplan zur weiteren Absicherung von Webmail und Schnittstellen. Im Forum gab es dazu bereits einen Vorschlag, den ich für äußerst wertvoll halte:

Externe Schnittstellen sollten nur noch per Token erreichbar sein.

Konkret zum Beispiel so:

1. Jeder Kunde erhält einen individuellen Token, der im Webmail einsehbar ist
2. Wenn diese Option aktiviert ist, können externe Schnittstellen ausschließlich mit diesem Token genutzt werden
3. Eine Anmeldung mit dem normalen Passwort wird dann abgelehnt

Warum ich das für wichtig halte:

1. Passwörter sind faktisch kaum noch sicher. Wird ein Passwort kompromittiert, kann ein Angreifer innerhalb von Sekunden auf den Account zugreifen und zumindest alle Mails lesen
2. Externe Schnittstellen lassen sich nicht sinnvoll mit Passkeys oder klassischem 2FA absichern – das funktioniert nur im Webmail

Aus meiner Sicht ist diese Token-Lösung daher ein „Must-Have“. Technisch müsste der Mailserver dann statt auf die Passworttabelle auf eine Token-Tabelle prüfen. Oder übersehe ich hier einen grundsätzlichen Denkfehler?

Gibt es denn eine richtige Anleitung wie die Toolbox erstellt wird, im Admin finde ich dazu ja nichts mehr

Ich hab hier noch so ein Ding nur weiß ich nicht ob das mit der alten Version von b1gmail zusammenhängt

SPF Prüfung schlägt fehl weil der include scheinbar einen timeout bekommt

v=spf1 include:spf-0.secureserver.net -all

Wenn eine E-Mail das interne Speicherlimit überschreitet, erscheint aktuell kein Hinweis oder Dialog.
Die Nachricht wird zwar korrekt versendet, aber nicht im Ordner „Gesendet“ oder als Entwurf gespeichert.

Das liegt daran, dass die Mailgröße intern nach der MIME-Kodierung deutlich zunimmt – z. B. kann aus einer 25 MB-Datei durch Kodierung eine effektive Größe von ca. 38 MB werden.
Das überschreitet dann das interne Speicherlimit des Accounts, wodurch der Speichervorgang scheitert – allerdings ohne Fehlermeldung.

hier mal im Debug eine 38MB wav: === StoreMail run at 2025-10-10 00:27:06 ===
Mail size: 55292475 bytes
Error: Mail too big konnte man nur intern nachvollziehen

---edit

Das bedeutet, nicht nur die email.compose.php muss sicherstellen, dass die E-Mail nach der MIME64-Kodierung tatsächlich maximal 25 MB groß ist (und nicht 30 MB), sondern im Idealfall bereits vor dem Senden eine entsprechende Warnung oder Ablehnung ausgegeben werden sollte.

Ich habe das Anlagen-Limit daher jetzt mit dem Faktor 1,33 angepasst.
Das heißt: Die tatsächliche Größe, die beim Hinzufügen einer Anlage berechnet wird, ist jetzt Größe × 1,33.
Der Kunde wundert sich zwar vielleicht, warum bei einer 20 MB-Anlage das 25 MB-Limit bereits erreicht ist – aber so gibt es keine Beschwerden mehr, dass die Mail anschließend nicht gespeichert oder zugestellt wird. Besser wäre die Ermittlung der tatsächlichen Größe aber so geht's erstmal

Zitat von SLM

Ehrlich gesagt, auf ein paar Unbelehrbare sollte man keine Rücksicht mehr nehmen. Jeder seriöse Provider hat heute zumindest DKM/DMARC und SPF aktiviert.

Google, Yahoo und auch GMX setzen seit Anfang 2024 SPF/DKIM/DMARC voraus, damit sie E-Mails überhaupt verarbeiten:
https://support.google.com/a/answer/81126?hl=de
https://postmaster.gmx.net/de/best-practices#:~:text=Um%20die%20Sicherheit%20und%20Vertraulichkeit,From%2DDomain%20(RFC%205322.

Zu klären wäre aus meiner Sicht, in welchen Fällen

Bei fehlgeschlagener Prüfung:

E-Mail ablehnen

greift.
- Received-SPF: SoftFail
- Received-SPF: Fail
- Received-SPF: Pass
- Received-SPF: Neutral
- Received-SPF: None

Wobei ich bei Stichproben festgestellt habe, dass die meisten Spamversender lustigerweise einen korrekten SPF Eintrag gesetzt haben, der mit SPF: Pass quittiert wird.

Alles anzeigen

Ja, die kommen meist von gehackten Servern mit SPF pass aber es gibt noch eine Menge an Spam die SPF none hat und wenn man das nur kurz einschaltet reciht das manchmal schon um abzuschrecken. Diese Mails mit Passwörtern kommen in Wellen, jetzt sind es sogar schon Morddrohungen mit BTC, wird immer verrückter

Zitat von informant

Fehlerhafte sind normalerweise lt. Norm auch nicht vorhandene. Jedoch wird dann der EIngang an eMail sum >= 90% schrumpfen, da soviele keinen SPF haben lt. Statisik.

Ja, das ist genau das Problem. Viele nutzen überhaupt kein SPF, aber gerade bei Google und Outlook wird es mittlerweile immer stärker vorausgesetzt. Man könnte es daher zeitweise einschalten und mitlaufen lassen.

DANE teste ich auch nicht, weil damit praktisch gar nichts mehr durchkommt. Den HELO-Check habe ich ebenfalls deaktiviert und beim DKIM-Check brauchen wir eigentlich gar nicht erst anfangen – das ist aktuell noch zu wenig zuverlässig umgesetzt.

Hallo,

das lehnt fehlerhafte SPF ab (hoffe ich) aber nicht welche die gar keinen Eintrag haben, zumindest kommen halt diese Mails noch durch, SPF-fail ist mir noch nicht aufgefallen, die hatten wenn dann SPF NONE also keinen SPF gesetzt