Beiträge von weltmeister

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.

Danke, das hört sich doch nach einer vernünftigen Lösung an.

Zitat von kk

Zur Information für andere Mitlesende: im DNS war die IP XX.XX.XX.42 hinterlegt, im Apache war diese Domain aber auf XX.XX.XX.45 konfiguriert. Die Fehlermeldung war also korrekt und berechtigt.

Mit einem der nächsten Updates werden wir evtl. die Fehlermeldung noch etwas weiter aufbohren ("got XX.XX.XX.42, expected XX.XX.XX.45") - dann sieht man das vielleicht etwas schneller.

Viele Grüße

-Klaus Keppler

Alles anzeigen

Es ist aber schon seit über 15(!!!) Stunden eine neue(!!!) und korrekte IP hinterlegt und es ist noch immer nicht möglich ein Zertifikat zu erstellen.

Noch einmal: VOR dem Update wurde eine IP im DNS einer Domain geändert, anschließend war das Zertifikat sofort aktiv. Nun, nach dem Update dauert es ewigkeiten, wie in einem der letzten Fälle, schon über 16 Stunden.

Es kann doch nicht sein, das nach über 16 Stunden noch immer irgendwo die alte IP hinterlegt oder zwischengespeichert ist! Wie soll ich das den Kunden erklären, die zu uns umziehen und anschließend funktioniert nichts mehr, was vor dem Update immer zu 100% funktionierte? Soll ich denen sagen, das es bis zu 24 Stunden dauern kann, obwohl es vor dem Update nie länger als 5 Minuten dauerte, ein Zertifikat zu erstellen?

Gibt es denn keine Möglichkeit mehr, die Sache nachträglich manuell erneut anzustoßen um die Sache zu beschleunigen? Warum wird hier nach über 16 Stunden noch immer auf die alte IP zugegriffen?

Insbesondere bei künftigen Shop-Umzügen habe ich Bauchschmerzen, wenn die Sache nicht zu 100% so funktioniert, wie vor dem Update.

Zitat von kk

Ich wiederhole mich gerne noch zum vierten Mal, aber gleichzeitig auch zum letzten Mal: ohne konkrete Daten können wir nicht weiterhelfen. Gerne per Mail an support@liveconfig.com. Ohne Hilfe keine Hilfe - sorry...
Ich habe alleine in diesem Thread schon 3x geschrieben was wir brauchen, um das nachzuverfolgen:

• einen betroffenen Domainnamen
• dessen konfigurierte IP
• (am besten den zuständigen <VirtualHost>-Abschnitt aus /etc/apache2/sites-enabled/<Vertrag>.conf)
• und zudem alle Log-Einträge zu dieser Domain in /var/log/liveconfig/liveconfig.log

Letztes Angebot.

Mail geht gleich raus. Auch jetzt, nach 15 Stunden Wartezeit noch immer keine Chance / Möglichkeit, das Zertfikat zu beantragen.

Zitat von bfal

Wurde denn einmal geprüft ob die IP vom Server direkt richtig aufgelöst wird? Es kann ja sein das bei whatsmydns.net schon die neue IP angekommen ist aber beim Server selbst noch nicht. Das sagt eigentlich gar nichts aus.

Ja, das wurde selbstverständlich auch schon mehrfach geprüft. Der Server zeigte stets jeweils die korrekte IP der Domain an.

Zitat von kk

Nutzen Sie vielleicht NAT-IPs auf Ihrem Server?

Nein.

Die DNS hatte zum Zeitpunkt der beantragung gestimmt. Wie sonst auch seit Dez. 2015, als es nie bisher Probleme gab.

Auszug aus dem Log:

Zitat

[2019/08/27 20:47:05.923828] [15823|15826] DNS check for 'xxx.com' failed: DNS error: unknown/invalid IP(s) found in DNS: xx.xxx.xxx.xx

Das ganze wiederholt sich bereits 20 mal im Log. D.h. 20 x hat es bisher nicht funktioniert, trotz korrekter DNS, ein Zertifikat anzulegen.

Gibt es dafür auch eine offizielle Anleitung oder Hinweise ähnlich wie für Deb. 8 ---> 9? (https://www.liveconfig.com/wiki/de/upgrade/debian)

Zitat von kk

Ich denke das hatten wir schon geklärt?
Wenn die IP-Adresse zum Zeitpunkt der Bestellung korrekt wäre, dann würde es diese Fehlermeldung nicht geben.

Ansonsten bitte konkrete Daten (IP, Domainname, alle Log-Meldungen aus /var/log/liveconfig/liveconfig.log) an support@liveconfig.com schicken.

Die DNS-Einträge werden von LiveConfig alle 15 Minuten überprüft - sobald die stimmen, wird die SSL-Bestellung automatisch fortgesetzt.

Die DNS sind korrekt, laut https://www.whatsmydns.net zeigt jedes Ergebnis auf die korrekte IP. In den Logs steht das gleiche, wie ich schon einmal für eine andere Domain übermittelt hatte.

Wir warten nun schon seit über einer Stunde, das Zertifikat aktiviert sich einfach nicht. Sonst hat das keine 5 Minuten gedauert. Der Endkunde des Resellers ist stocksauer (weil die Webseite nicht erreichbar ist) und vom Reseller haben wir auch schon eine klare Ansage bekommen. (Zitat: "Wenn das Problem nicht in den Griff zu bekommen ist, dannn ... bla bla bla... kündige ich sämtliche Verträge, von P***k kenne ich so etwas nicht.")

Solche Probleme gab es vor dem Update nie, das war jeweils ein nur Klick und nach ca. 3 bis 5 Minuten war das Zertifikat immer und ohne solche Probleme aktiv. Niemand musste so lange warten. Was soll ich dem Kunden nun erklären? Der Schriftverkehr ist endlos.

Das Problem haben wir leider immer noch. Reseller schalten Domains (bei denen DNS-Einträge vorhanden sind) auf und wollen ein Zertifikat für deren Kunden beantragen. Ich weiß gar nicht, wie viele Anfragen es schon gab, immer und immer wieder das selbe:

Zitat

[27.08.2019 18:10:15] ACME2: xxx.com: DNS check failed: DNS error: unknown/invalid IP(s) found in DNS: xx.xx.xx.xx

Anschließend geht nichts mehr, was vor dem Update alles kein Problem war und funktionierte.

Die Domain ist erreichbar und mit korrekten DNS-Einträgen versehen.

Zitat von kk

Workaround in so einem Fall ist, das noch nicht beantragte Zertifikat aus der SSL-Verwaltung zu löschen und dann erneut eines zu beantragen. Wir planen aber auch einen Button anzulegen, um die DNS-Prüfung manuell vorzuziehen.

Hierum würde ich bitten!

Unser Domainanbieter lässt leider keine sehr kleinen TTL-Werte zu. Und: vor dem Update konnte man ja auch ohne Wartezeit innerhalb v. 5 Minuten das Zertifikat beantragen, sobald die DNS umgestellt worden ist. TTL spielte dabei bisher keine Rolle.

Vielen Dank im Voraus für's nachbessern in Form eines Buttons.

Nun ist schon weit über eine Stunde vergangen und das Zertifikat ist leider noch nicht aktiv. Der Kunde wird langsam sauer, da ich ihm mitteilte, dass SSL wie bisher gewohnt sofort aktiv wird, wenn die DNS-Einträge stimmen, womit es bisher ansonsten noch nie Probleme gab.

Zitat von kk

Es liegt schlicht am DNS. Ich kann von hier aus leider nicht sagen was exakt die Ursache war, aber die Meldungen lassen ja keinen Spielraum zur Interpretation: in einem Fall wurde ein "NXDOMAIN" vom DNS-Server geliefert (das bedeutet also nicht dass der DNS-Server nicht geantwortet hat, sondern die Domain war tatsächlich (noch) nicht vorhanden). Im anderen Fall liefert der angefragte DNS-Server andere IPs als auf dem Server vorhanden sind. Beide Fälle führen bei einer Domainvalidierung durch Let's Encrypt zu einem Fehler - das Verhalten ist also richtig.

Bei neu angelegten Domains kann es immer ein wenig dauern bis diese im DNS konnektiert sind. Es macht keinen Sinn, eine Domainvalidierung anzustoßen bevor die Domain vollständig konfiguriert ist.

Bei der zweiten Domain: schicken Sie uns einfach mal den Domainnamen an support@liveconfig.com, dann prüfen wir das gerne mal.

Viele Grüße

-Klaus Keppler

Alles anzeigen

Nachricht ist raus. Zertifikat 2 ist noch immer nicht aktiv (trotz korrekter und geprüfter DNS), so endlos lange hat es noch nie gedauert, wie nach dem Update.

Logs werden gleich studiert, ich gehe aber davon aus, dass in diesen selbiges vermerkt sein wird.