Beiträge von kk

  • Postfix Konfiguration - reject_sender_login_mismatch

    Zitat von aho546745

    Wie ist denn hier der Status? Wäre halt gut, wenn man das pro Vertrag ein/ausschalten könnte, denn Exchange-User, die den Server als Smarthost benutzen, habe ich auch.


    Status ist, dass so eine Konfiguration technisch möglich, aber relativ komplex ist.
    (zu komplex, damit LiveConfig das derzeit mit abdecken könnte).


    Man kann das manuell wie folgt einrichten:
    1.) Paket "postfix-pcre" installieren, damit Postfix mit PCRE-Lookups zurecht kommt.
    2.) die /etc/postfix/main.cf wie folgt anpassen:

    Code
    smtpd_restriction_classes = sasl_restricted_senders
smtpd_sender_restrictions =
  check_sasl_access hash:/etc/postfix/sasl_access,
  [...]
sasl_restricted_senders =
  reject_sender_login_mismatch
smtpd_sender_login_maps =
  pcre:/etc/postfix/sender_login_map_default,
  hash:/etc/postfix/sender_login_map


    3.) Datei /etc/postfix/sasl_access anlegen:

    Code
    # SASL-Accounts, die nur definierte Absenderadressen verwenden dürfen:
user@example.org sasl_restricted_senders


    Danach natürlich noch "postmap /etc/postfix/sasl_access" ausführen.
    4.) Datei /etc/postfix/sender_login_map_default anlegen:

    Code
    /^(.*)$/   ${1}


    5.) Datei /etc/postfix/sender_login_map anlegen:

    Code
    # Liste der Absender (MAIL FROM) und der erlaubten Mailbenutzer
info@example.org   user@example.org
manfred.mustermann@googlemail.de   user@example.org


    Danach auch "postmap /etc/postfix/sender_login_map" ausführen.


    Dieses Beispiel erlaubt es grundsätzlich allen SASL-Benutzern, die in "sasl_restricted_senders" stehen, nur E-Mails zu versenden, bei denen der Absendername ("From:") identisch mit dem SASL-Benutzernamen ist.
    Zudem wird dem Benutzer "user@example.org" erlaubt, E-Mails auch als "info@example.org" oder als "manfred.mustermann@googlemail.de" zu versenden.


    WICHTIG: bei "smtpd_sender_restrictions" auch noch die bisherigen Einschränkungen übernehmen, sonst baut man sich ein "open relay".
    Alle Einstellungen lassen sich über die custom.lua in "postfix.LOCALCONFIG" eintragen.


    Alle Angaben ohne Gewähr, o.g. Konfigurationsanweisungen sind "from scratch"!

  • ProFTPD und TLS


    So weit klappt ja alles. Das heißt, die FTP-Anmeldung funktioniert einwandfrei. Das Problem liegt woanders:


    "Passive mode" bedeutet, dass der FTP-Server darauf wartet dass Sie eine separate Datenverbindung dorthin aufbauen. Alle weiteren Details dazu finden Sie z.B. hier: http://www.proftpd.org/docs/howto/NAT.html
    So wie es aussieht, geht genau das schief. Ob das nun auf dem Zielserver nicht klappt (z.B. aufgrund von Firewall-Regeln!) oder vom lokalen Netzwerk aus (Virenscanner der die FTP-Verbindung "kapert" und untersucht) kann man von hier aus nicht sagen.


    Dass das "plötzlich" nicht mehr geht, kann ich mir nicht vorstellen - irgendetwas muss sich geändert haben. Am häufigsten sind es eigentlich Firewall-Einstellungen, die da was stören. Wenn es sich um einen vServer handelt, prüfen Sie, ob auf dem Host vielleicht gefiltert wird.



    Was wird denn in den "üblichen" Logdateien (/var/log/messages|syslog|auth.log, proftpd.log etc.) protokolliert, wenn so eine Anmeldung stattfindet?
    Vielleicht stört hier eine lokale Firewall die Verbindung wenn sie sieht, dass da eine unverschlüsselte FTP-Verbindung aufgebaut werden soll?


    Viele Grüße


    -Klaus Keppler

  • Mail Adressen export

    Hallo,


    naja, dass das ein Problem sei war bislang noch nicht bekannt. ;)
    Wurde aber eben geändert - künftig erhalten alle CSV-Downloads den Dateinamen "data.csv".
    (ab v2.3.0-r4519).


    Viele Grüße


    -Klaus Keppler

  • SPF-Record

    Zitat von Webdesign Kronberg

    Sollte ich IPV6 für ausgehende Mails deaktivieren, um nicht als Spam erkannt zu werden?


    Als Spam erkannt? Wenn Sie Spam versenden, dann sollte dieser bitte auch korrekt erkannt werden. ;)


    Wenn Sie aber legitime Mails versenden, die nicht als Spam verdächtigt werden sollten, dann: ja, IPv6 ausgehend deaktivieren. Ist nicht im Sinne von IPv6, aber Google will das ja leider so. :(

  • SPF-Record

    Zitat von Webdesign Kronberg

    Dies führt bei großen Anbietern wie Google dazu, dass man teilweise auf die Spam-Liste gesetzt wird.


    Nein, ein fehlender SPF-Record ist sicher noch kein Spam-Merkmal.
    Bei Google ist es nur problematisch, wenn man Mail per IPv6 einliefert und kein SPF gesetzt ist.


    SPF ist "broken by design", Mailweiterleitungen werden damit zwangsweise als Spam bewertet. Als Workaround dafür gibt es SRS (Sender Rewriting Scheme), was dann wiederum DKIM-Signaturen beschädigt.
    Technisch betrachtet ist es also ordentlicher, keinen SPF-Record zu haben als aufgrund von Mailweiterleitungen und kaputten DKIM-Signaturen als Spam eingestuft zu werden.


    Wir empfehlen ganz klar DKIM als halbwegs ordentliche Methode zur Markierung "echter" Mails.


    Viele Grüße


    -Klaus Keppler

  • Usability Fehler - Passwortfeld bitte nur bei Postfächern

    Es gibt auch den Anwendungsfall, dass reine Weiterleitungs-"Benutzer" ein Passwort erhalten, um sich damit direkt im LiveConfig anmelden und die Zieladresse selbst bearbeiten zu können.


    Wir könnten die Passworteingabe aber deaktivieren, wenn weder die Postfach-Checkbox noch die Web-Login-Checkbox aktiviert sind.

  • Letsencrypt Integration

    Zitat

    Error creating new cert :: Certificate public key must be different than account key


    Interessant... auf die Idee muss man auch erst mal kommen ;)
    Das dürfte an sich aber unkritisch gewesen sein (die Fehlermeldung von LE wurde ja erkannt und ausgegeben).


    Zitat

    Error while parsing SSL certificate (PEM): error:0906D06C:PEM routines:PEM_read_bio:no start line


    Diese Log-Meldung wird ausgegeben, wenn eine vHost-Konfiguration geschrieben werden soll und bei der Prüfung ob das SSL-Zertifikat OCSP unterstützt ein Fehler auftritt.
    Ich tippe auf ein Timing-Problem (vHost-Konfiguration wird ausgelöst bevor das Zertifikat in der Datenbank commited ist, o.ä.). Wir werden in der Konsequenz nun zwei Änderungen vornehmen:
    1.) wenn ein SSL-Zertifikat aus der Datenbank "unbrauchbar" ist (warum auch immer) wird der SSL-vHost nicht mehr konfiguriert (besser nicht als kaputt).
    2.) der Programmfluss zwischen "Zertifikat in Datenbank schreiben" und "vHost-Konfiguration aktualisieren" wird geprüft und ggf. geändert, um dieses vermeintliche Timing-Problem zu vermeiden.


    Das Ganze wird umgehend bearbeitet, Update folgt umgehend.


    Viele Grüße


    -Klaus Keppler

  • Spamcheck für alle Postfächer aktivieren

    Führen Sie in der LiveConfig-Datenbank folgenden SQL-Befehl aus:

    SQL
    UPDATE MAILBOXES SET MB_STATUS=9 WHERE MB_STATUS=1;


    und starten Sie LiveConfig anschließend neu. Damit werden alle Postfacheinstellungen neu geschrieben.


    Viele Grüße


    -Klaus Keppler

  • Postfix Lua, Annahme nur von einer IP

    Steht doch eigentlich alles in der Postfix-Dokumentation... ;)


    Wichtig ist hier die Einstellung smtpd_client_restrictions. Damit authentifizierte Benutzer zugelassen werden, sollte da permit_sasl_authenticated drin stehen.
    Wenn ansonsten nur noch Mails von einer anderen (bestimmten) IP erlaubt sind, ist die Einstellung check_client_access das Mittel der Wahl.
    Vollständig sähe das also etwa so aus:

    Code
    smtpd_client_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  check_client_access hash:/etc/postfix/allowed-ips,
  reject


    In die Datei /etc/postfix/allowed-ips gehören dann die erlaubten IP-Adressen:

    Code
    203.0.113.25 OK


    Danach noch den Befehl "postmap /etc/postfix/allowed-ips" ausführen.


    Um die o.g. Einstellung in die von LiveConfig verwaltete main.cf aufzunehmen, folgende Zeilen in die custom.lua hinzufügen:

    Code
    postfix.LOCALCONFIG = {
  ['smtpd_client_restrictions'] = "permit_mynetworks, permit_sasl_authenticated, check_client_access hash:/etc/postfix/allowed-ips, reject"
}


    Verwendung auf eigenes Risiko, alle Angaben ohne Gewähr.

  • Letsencrypt Integration

    Hallo,


    wir haben inzwischen herausfinden können, dass es in der HTTP-Kommunikation mit den Let's-Encrypt-Servern manchmal zu einem Problem kam. Vereinfacht gesagt brach LiveConfig die HTTP-Verbindung vorzeitig ab, wenn z.B. "halbe" HTTP-Header in einem separaten TCP-Paket empfangen wurden. Das haben wir früher nie beobachtet, den Meldungen im Forum nach zu urteilen häuft es sich aber inzwischen. Ich schätze, dass das mit dem gestiegenen Anfragevolumen bei Let's Encrypt zusammenhängt.
    Jedenfalls sollte ab v2.3.0-r4510 bei der Kommunkation mit Let's Encrypt nun kein Fehler mehr auftreten.
    Wir arbeiten mit Hochdruck am Release von v2.3.0 - da es gerade im "Unterbau" viele Änderungen gab bitte ich noch um ein paar Tage Geduld.
    Mit den in v2.3.0 verfügbaren neuen Funktionen sind uns derzeit keine Fehler mehr bekannt, die offenen Änderungen (vor dem Release) betreffen nun nur noch die GUI.


    Viele Grüße


    -Klaus Keppler

  • Postfix virtual_domains Tabelle wird nicht aktualisiert

    Danke für die Rückmeldung.
    Wir haben einen Fall identifizieren können: wird das letzte Postfach mit Domain "A" bearbeitet und auf Domain "B" umgestellt, so verbleibt die Domain "A" in der virtual_domains-Datei.
    Vermutlich selten, aber dennoch ärgerlich. Fix ist bereits in Arbeit.


    Viele Grüße


    -Klaus Keppler

  • PHP 5.4 für Debian Jessie?

    Nein, so etwas bieten wir nicht an. Das würde bedeuten, dass man einzelne Patches "backporten" müsste.
    PHP 5.4 ist seit 03.09.2015 end-of-life.


    Wir stellen die PHP-Pakete kostenfrei zur Verfügung, Backporting ist da leider nicht drin.