Beiträge von weltmeister

Zitat von suppenuser

Bitte nicht. So wie es ist, so ist es eindeutig perfekt.
Kunden jetzt auch noch mit irgendwelchen überflüssigen Abfragen zum Spamhandling überfordern braucht niemand wirklich. Nebenbei, der Normalkunde ist sich bewusst, dass er Spam normal entweder im Spamfolder findet oder dieser schon vorher abgelehnt wurde.

Gruß Ralf

Die Sache ist keinesfalls überflüssig, ich arbeite im Kundenservice und muss fast täglich solche Anfragen beantworten. Ich weiß also wovon ich schreibe und was sich die Kunden wünschen. Und so eine Checkbox "überfordert" nun wirklich niemanden, wenn es vom Großteil aller Kunden gewünscht wird. Insbesondere die jenigen, die vorher auf P***k-Servern waren, vermissen diese praktische Funktion der serverseitigen vorsortierung.

Da hier fast täglich Anfragen reinkommen: wird es eine Lösung wie bei z.B. P***k geben, wo der Kunde per Checkbox selbst entscheiden kann, was mit "Spam" passieren soll? (Im Posteingang belassen oder in einen Spamordner verschieben)

Es ist jedesmal sehr schade, dem Kunden mitteilen zu müssen, dass es eine solche Funktion nicht gibt.

Vielen Dank, das werden wir gleich einmal testen.

Zitat von kk

Aktuell sehen die smtpd_client_restrictions ja etwa so aus:

Code

smtpd_client_restrictions =
    permit_mynetworks,
    check_sasl_access hash:/etc/postfix/sasl_access,
    permit_sasl_authenticated,
    reject_invalid_hostname,
    reject_unknown_reverse_client_hostname,
    reject_rbl_client ix.dnsbl.manitu.net

Ich schlage vor, dass wir nach "permit_sasl_authenticated" noch eine (manuell pflegbare) Liste für's Server-Whitelisting aufnehmen:

Code

smtpd_client_restrictions =
    permit_mynetworks,
    check_sasl_access hash:/etc/postfix/sasl_access,
    permit_sasl_authenticated,
    [COLOR=#ff0000][B]check_client_access hash:/etc/postfix/client_exceptions,[/B][/COLOR]
    reject_invalid_hostname,
    reject_unknown_reverse_client_hostname,
    reject_rbl_client ix.dnsbl.manitu.net

Diese Liste enthält dann die IP-Adressen oder Hostnamen von Servern, die man immer durchlassen möchte, z.B.:

Code

mailout01.t-online.de OK
mailout02.t-online.de OK
...

wobei statt "OK" evtl. ein "DUNNO" angebracht wäre, das müssten wir noch testen. Schließlich sollen die restlichen Prüfungen (insbes. Antivirus) ja weiterhin ausgeführt werden.

Alles anzeigen

Wird diese Funktion künftig umgestezt? Aktuell haben wir wieder das Problem mit der Telekom. Natürlich sind die Kunden im glauben, der Fehler liegt bei uns, wo sonst? So eine Whitelist-Funktion wäre eine große Hilfe, auch wenn ich die Telekom nicht mag. Es geht hier jedoch an erster Stelle um die Kundenzufriedenheit.

In der Hoffnung, dass diese Funktion ----> https://www.liveconfig.com/de/…-PHP-Mail-und-etc-aliases bald integriert wird, noch eine Ergänzung: der Return-Path fehlt leider auch bei Mails, welche der Autoresponder automatisch verschickt.

Hintergrund: es kamen schon mehrfach Hinweise von Kunden, dass bestimmte Empfänger deren Spamfilter so "scharf" eingestellt haben, dass alle Mails ohne "Return-Path" im Spam landen.

Ich möchte nochmals darum bitten, diese Funktion alsbald zu integrieren.

LiveConfig ist gut, aber die Entwicklung ist einfach viel zu langsam. Das Forum ist voll mit sinnvollen Funktionsvorschlägen, die woanders schon seit Jahren standard sind und bei LiveConfig noch immer fehlen bzw. schon seit ewigkeiten versprochen werden.

** push **

Zitat von BMK-Media

Mir ist aufgefallen, das bei den Subdomains immer der Pfad von der Domain steht.

Kann ich so bestätigen. Viele irritierte Kunden haben sich schon gemeldet. Das sollte schnellstens behoben werden!

Ich denke das ist derzeit eher verwirrend für den Kunden. Sieht er unter SSL kein Zertifkat, wundert er sich --> und wieder kommen Support-Mails, wie: "Wo ist das Zertifikat?" "Warum ist kein Zertifikat sichtbar" ...

Gibt es mittlerweile eine offizielle Upgrade-Anleitung seitens LiveConfig? (Wurde schon vor Wochen versprochen!)

Zitat von tfi

Eigentlich wollen wir die Certs für die Kunden-Domains nicht mit unserem LE-Account verwalten.

Exakt das ist mir auch schon so aufgefallen und sollte nachgebessert werden. D.h. das Zertfikat soll im Account des Kunden angelegt werden.

Zitat von suppenuser

Hi,

in /usr/lib/liveconfig/lua/custom.lua

z.B.

postfix.LOCALCONFIG = {
['smtpd_sender_restrictions'] = "pcre:/etc/postfix/rejected_domains, permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname,reject_unknown_helo_hostname,reject_unknown_address,reject_unknown_sender_domain,reject_non_fqdn_sender,check_sender_access hash:/etc/postfix/sender_access";
}

dann lc neu starten und /etc/postfix/rejected_domains anlegen.
Dort z.b.

/\.ru$/ REJECT dont like you!

eintragen und dann ein

postmap /etc/postfix/rejected_domains machen und Postfix neu laden. Danach ist der Fisch dann geputzt

Gruß Ralf

Alles anzeigen

Danke, aber das gilt ja dann ja sicher global. Jeder Kunde sollte selbst entscheiden, was er will, und was nicht.

Zitat von bfal

Nicht wenn der Kunde das für seine Adressen selbst entscheiden kann.

Genau das wünschen viele unserer Kunden auch.

Die Anfragen hiernach reißen nicht ab. Insbesondere von Kunden, die IMAP nutzen, kommt immer wieder die Anfrage, ob eine Möglichkeit gibt, Spam-Mails in einen bestimmten Ordner zu verschieben.

Funktionsvorschlag: der Kunde sollte selbst per Haken entscheiden können, ob Spam-Mails normal im Posteingang landen oder einem sog. "Spam-Ordner".

Gibt es denn eine Möglichkeit für den normalen Endkunden, Mails mit solchen Endungen abzuweißen?

Ein Kunde fragt an, inwiefern man komplette TLDs mit Spamassin sperren kann, z.B. alle Absender in der Form

*@*.pro

(Funktioniert leider nicht)

D.h. der Kunde will alle Mails mit der Absender-TLD ".pro" abweisen. Geht das?

lclogparse.conf:

#  _    _          ___           __ _     (R)
# | |  (_)_ _____ / __|___ _ _  / _(_)__ _
# | |__| \ V / -_) (__/ _ \ ' \|  _| / _` |
# |____|_|\_/\___|\___\___/_||_|_| |_\__, |
#                                    |___/
# Copyright (c) 2009-2019 Keppler IT GmbH.
# ----------------------------------------------------------------------------
!STATUS-FILE:/var/lib/liveconfig/lclogparse.status
!PID-FILE:/var/run/lclogparse.pid


/var/log/mail.log
	# Postfix
	NEW:	-I-f	^.* postfix/([^/]+/)?smtp.*: ([A-Za-z0-9]+): (client=[^,]+), sasl_method=[^,]+, sasl_username=([^ ]+)
	NEW:	-IE	^.* postfix/([^/]+/)?smtp.*: ([A-Za-z0-9]+): (client=[^,]+)$
	UPDATE:	IX	^.* postfix/.*: ([A-Za-z0-9]+): from=(<>)
	UPDATE:	IS	^.* postfix/.*: ([A-Za-z0-9]+): from=<[^>]+>, size=(\d+)
	UPDATE:	IO---	^.* postfix/.*: ([A-Za-z0-9]+): (to)=<([^>]+)>, relay=(?!dovecot).*, status=(sent|bounced)
	UPDATE:	IOt--	^.* postfix/.*: ([A-Za-z0-9]+): (to)=<[^>]+>, orig_to=<([^>]+)>, relay=(?!dovecot).*, status=(sent|bounced)
	UPDATE:	IOt	^.* postfix/.*: ([A-Za-z0-9]+): (to)=<([^>]+)>, relay=dovecot
	UPDATE:	IOt	^.* postfix/.*: ([A-Za-z0-9]+): (to)=<[^>]+>, orig_to=<([^>]+)>, relay=dovecot
	DONE:	I	^.* postfix/.*: ([A-Za-z0-9]+): removed
	OUTPUT-FILE:	/var/lib/liveconfig/smtp.stats


# <EOF>-----------------------------------------------------------------------

lclogparse.status: exakt diese Datei gibt es nicht, auch nicht auf einem funktionierenden System.

Zitat von kk

Was genau steht dann im diff?

Beide Dateien sind und bleiben jeweils unverändert identisch, trotz dem die Datei smtp.stats stets neu erstellt wird. Wo könnte man noch nach der Ursache suchen?

Das Problem besteht leider immer noch. Gibt es noch weitere Ideen, um dem Fehler auf die Spur zu kommen?

Die genannten Probleme sind nun seit dem letzten Update allesamt behoben. Zertifikate können nun wieder wie bisher gewohnt ohne Wartezeit und Probleme angelegt werden, wenn Domains gerade "frisch" umgezogen worden sind.