Wir sind nun auch schon seit über 10 Jahren dabei. Vor allem eine funktionierende Backup-Funktion wäre das A und O und wird immer wieder erfragt. Wann ist denn nun soweit?
Beiträge von weltmeister
-
-
Jetzt wird es peinlich (für mich). Das nennt man Betriebsblindheit. Exakt diese Funktion ist vorhanden und funktioniert sehr gut.
Ich bedanke mich für die sehr schnelle Reaktion und den guten Service.
-
Die Logs unserer Server füllen sich in letzter Zeit mit Fehlermeldungen wie diesen:
CodeZeile 362740: Mar 23 13:57:37 s1 postfix/smtp[3984672]: connect to gmail-smtp-in.l.google.com[2a00:1450:400c:c07::1b]:25: Network is unreachable Zeile 371161: Mar 23 15:43:34 s1 postfix/smtp[4024859]: connect to gmail-smtp-in.l.google.com[2a00:1450:400c:c07::1a]:25: Network is unreachable Zeile 371545: Mar 23 15:48:36 s1 postfix/smtp[4026100]: connect to gmail-smtp-in.l.google.com[2a00:1450:400c:c07::1b]:25: Network is unreachable Zeile 371546: Mar 23 15:48:36 s1 postfix/smtp[4026100]: connect to alt1.gmail-smtp-in.l.google.com[2a00:1450:4013:c16::1b]:25: Network is unreachable Zeile 372209: Mar 23 15:58:36 s1 postfix/smtp[4027901]: connect to gmail-smtp-in.l.google.com[2a00:1450:400c:c07::1b]:25: Network is unreachable Zeile 372212: Mar 23 15:58:36 s1 postfix/smtp[4027901]: connect to alt1.gmail-smtp-in.l.google.com[2a00:1450:4013:c16::1a]:25: Network is unreachableDas Resultat ist, das Mails nicht ankommen. Die Lösung soll wie folgt in der /etc/postfix/main.cf sein:
inet_protocols=ipv4
Ist es möglich, das dies im nächsten Update angepasst wird?
Im Moment steht da: inet_protocols=all
Siehe auch: http://www.whitemiceconsulting.com/postfixIPv4only
Eine Möglichkeit das ganze umschaltbar zu machen, wäre eine feine Sache.
-
Vielen Dank an dieser Stelle für die vielseitige Hilfestellung und die Denkanstöße. Das Problem konnte gelöst werden.
-
Danke, exakt das habe ich so eingefügt, die config neu schreiben lassen, den Dienst neu gestartet, es wird einfach nicht übernommen.
Kann es sein, dass dies unter Deb. 11 nicht funktioniert?
doveconf -d | grep default_process_limit gibt immer noch 100 aus.
Ich wäre für jeden hilfreichen Tipp dankbar.
-
Ja, der Include steht in der dovecot.conf ordnungsgemäß.
Jedoch kann ich in die dovecot.local.conf einfügen was ich will, es wird einfach nichts übernommen.
Auch das neustarten der Dienste hat nicht zum Erfolg geführt.
Was kann man noch tun?
-
Leider ohne Funktion. Ich trage folgendes in die dovecot.local.conf ein:
service imap-login {
process_limit = 250
}Anschließend wird die Konfiguration neu gespeichert.
doveconf -d | grep default_process_limit zeigt folgendes:
Zitatdoveconf: Warning: please set ssl_dh=</etc/dovecot/dh.pem
doveconf: Warning: You can generate it with: dd if=/var/lib/dovecot/ssl-parameters.dat bs=1 skip=88 | openssl dhparam -inform der > /etc/dovecot/dh.pem
default_process_limit = 100Der Wert wurde also gar nicht übernommen. Was ist da falsch?
Ist es hoffentlich bald möglich, diesen Wert über LiveConfig einstellen zu können?
-
Alles anzeigen
Bitte ruhig bleiben...
Es geht hier um das process_limit, also die Gesamtzahl aller IMAP- und/oder POP3-Prozesse. Via LiveConfig lässt sich derzeit nur die Anzahl der Connections pro IP festlegen.
Ich denke, dass wir diesen Wert auch via LC einstellbar machen (ist ja wichtig für größere Setups); bis dahin wird es eine manuelle Lösung geben.Viele Grüße
-Klaus Keppler
Wird dies bald berücksichtigt, also ohne "Bastelarbeiten", wie bisher? Es wäre in der Tat schön, wenn man diesen Wert in der Oberfläche festlegen könnte.
-
An dieser Stelle sei mir eine kurze Nachfrage gestattet: bereits im Jahr 2021 wurden Ihnen in diesem Thread sowohl von thomas16 als auch von suppenuser entsprechende (wirklich simpel umzusetzende) Lösungsmöglichkeiten präsentiert.
Wurden diese von Ihnen tatsächlich knapp 1 1/2 Jahre einfach ignoriert und Sie warten stattdessen lieber auf eine entsprechende Implementation in LiveConfig?
Wer lesen kann, ist klar im Vorteil. Es ist eine Lösung gewünscht, wo der Kunde selbt entscheiden kann, was mit den Spam-Mails passiert. (Sortieren / nicht sortieren, wie bisher).
-
Heute die nächte Anfrage, eine von vielen: "Eine Frage hätte ich noch: gibt es eine Möglichkeit, den Spamfilter einzustellen? So weit ich sehen kann, markiert der nur Spam-Verdachtsfälle, schiebt sie aber in keinen speziellen Ordner oder löscht sie gar. Das ist für uns wichtig."
Ich selbst sage nur ungern nein, kann diese Funktion aber nicht aus dem Hut zaubern. Daher bitte die möglichkeit anbieten, den Kunde diese Einstellung vornehmen zu lassen. Alle, die es wollen. Die es nicht wollen, setzen den Haken nicht.
Wird es diese Möglichkeit hoffentlich bald geben?
-
Heute kam folgende Fehlermeldung rein:
channel 'spamassassin.heinlein-support.de': could not find working mirror, channel failed
Wurde der Dienst eingestellt?
-
Vielen Dank für die Erklärung.
-
Die Mailserver werden über LiveConfig verwaltet, DKIM wurde wie von LiveConfig bereitgestellt übernommen, als SPF nutzen wir v=spf1 a mx ip4:xx.xx.xx.0/24 ~all.
Bei https://www.mail-tester.com werden 10 / 10 Punkte erreicht , nur 2 Kleinigkeiten werden im Ergebnis "beanstandet":
-0.001 | SPF_HELO_NONE | SPF: HELO does not publish an SPF Record
Diese Regel wird angewendet, wenn die E-Mail eine DKIM Signatur aufweist, aber weitere positive Regeln werden bei einer gültigen DKIM Signatur ebenfalls angewendet.-0.1 | DKIM_SIGNED | Message has a DKIM or DK signature, not necessarily valid
Was muss konkret getan werden, damit man diese beiden eigentlich kaum nennenswerten Kleinigkeiten noch weg bekommt?
-
Wir erhalten hin und wieder diese Fehlermeldung:
Zitatservice(imap-login): process_limit (100) reached, client connections are being dropped
Die Werte
default_process_limit = X
default_client_limit = Xmüssten hierfür angepasst werden. (/etc/dovecot/10-master.conf)
Wenn in dieser Datei die Werte angepasst werden, wird dies vom System überhaupt berücksichtigt, oder gilt ausschließlich nur das, was in der Datei /etc/dovecot/dovecot.conf steht? Die Verwaltung von Devecot erfolgt über LiveConfig.Wie lässt sich das Problem am einfachsten lösen?
-
Danke für die Meinung. Der selben bin ich übrigens auch, ich finde es schon ein wenig dreist, das unsere Kunden mit so einem Bullshit belästigt werden und in den glauben versetzt werden, das hier alles "unsicher" sei. Ein Fall für die globale Blockliste.

-
Die Antwort möchte nicht vorenthalten, es ist alles im grünen Bereich. Wie "irre" einen solche Klugsch... doch machen können.
ZitatAlles anzeigenHallo Zusammen,
kurze Antwort: ja (Ende-zu-Ende).
Meine persönlichen Erfahrungen damit.
Wenn man nicht täglich zu 100% mit DATEV arbeitet relativ witzlos.
Für uns Mandanten ein Ärgernis und nicht wirklich praktikabel.
Lösung A besteht über einen Zugriff aufs DATEV Portal mit Zugangsdaten (für seltene Zugriffe ala 1x/Monat).
Sehr nervig da es keinen Verlauf gibt, keine Suchmöglichkeit, kein Postfach.
Da auch kein Zusammenhang mit Outlook (dort ist nur die Benachrichtigungsmail mit dem Link zur „Email“ im Portal).
Nachdem alle Emails gleich aussehen weiss man nach 5 Emails nicht mehr was was ist (geschweige denn nach ein paar Monaten oder Jahren).
Lösung B besteht in einem Plugin für Outlook was extrem zäh ist und bei Fehler oder schwacher Maschine/altem Outlook fähig ist die gesamt Outlook Instanz zu blockieren.
Im Fehlerfall tanzt man zwischen DATEV und Steuerkanzlei hin und her (Fehler kann an 3 verschiedenen Stellen liegen).
Ergo: Wie Herr X geschrieben hat > Transportverschlüsselung ist gut und aktuell.
Wenn ein dauerhaftes und sehr reges Mandantenverhältnis zwischen Steuerkanzlei/DATEV und Kunde besteht = muss der DATEV Dienstleister eine Lösung anbieten die schmerzfrei ist.
Ansonsten ist die bestehende Stand der Technik ausreichend.
Es muss ja noch möglich sein vernünftig arbeiten zu können (siehe meine Beispiele oben).
Hoffe geholfen zu haben.Viele Grüsse in die Runde.
-
Ein Kunde hat folgende Mail erhalten, auf dem Server ist Debian 11, alles aktuell, Konfiguration durch LiveConfig, der Haken bei "SSL/TLS" und "verschlüsselte Benutzeranmeldung erlauben" ist gesetzt:
ZitatAlles anzeigenSehr geehrte Damen und Herren,
Sie erhalten mit dieser E-Mail den Hinweis, dass es uns nicht möglich war, unsere E-Mail von xxx.xxx@xxx.de an xxx@xxx-xxx.com mit einer qualifizierten Transportverschlüsselung zuzustellen.
Auf Ihrem E-Mail-Server stand nur eine unsichere Form der Transportverschlüsselung zur Verfügung. Die genannte E-Mail wurde dennoch versendet.Es ist uns ein hohes Anliegen, zur Datensicherheit beizutragen und vertrauliche Informationen bestmöglich zu schützen.
In Bezug auf den E-Mail-Verkehr versuchen wir, E-Mails gemäß den Vorgaben der deutschen Datenschutzkonferenz
sowie des Bundesamts für Sicherheit in der Informationstechnik
zuzustellen und entsprechend beim Versand unserer E-Mails die sog. qualifizierte Transportverschlüsselung einzusetzen.
In Ihrem Fall war uns dies leider nicht möglich.Diese E-Mail soll lediglich als ein Hinweis dienen und impliziert keinen direkten Handlungsbedarf.
Dennoch möchten wir Sie ermutigen, Ihr E-Mail-Empfangssystem so zu konfigurieren, dass eine qualifizierte Transportverschlüsselung möglich ist.Leiten Sie diese Information am besten an Ihren IT-Verantwortlichen weiter.
Bei etwaigen Rückfragen können Sie sich gerne an nitscheSECUREMAIL@nitsche.com wenden.Wir bedanken uns für Ihre Mitarbeit für eine sicherere, digitale Arbeitswelt.
Wir werden diese Nachricht frühestens in 30 Tagen erneut an Sie senden.Freundliche Grüße
Ihr nitsche-Team
Ist das nur Werbung oder besteht hier tatsächlich Handlungsbedarf? Eine Mail habe ich rausgeschickt mit der Anfrage, was denn konkret "unsicher" sein sollte. Auf die Antwort bin ich gespannt. Da hier alles durch LiveConfig verwaltet wird, verlasse ich mich und vertraue auf eine saubere, sichere und fehlerfreie Konfiguration.
-
Danke, das sollte auf jeden Fall irgendwo gut dokumentiert werden. Derzeit fehlt an der entsprechenden Stelle übrigens die Übersetzung.
-
externe E-Mails mit lokaler Absenderdomain können nun abgelehnt werden (konfigurierbar pro Domain)
Was heißt dies genau, bzw. welchen sinn hat dies? Ich habe es einmal aktiviert, Mails konnten in dem Postfach trotzdem empfangen werden.
-
Freundliche Erinnerung an die doch nicht ganz unwichtige Funktion. Viele Kunden wissen übrigens gar nicht, das für jede Subdomain manuell ein Zertfikat angelegt werden muss. Daher macht diese Funktion schon sinn.