Beiträge von KB19

    Bildschirmfoto_2018-08-08_19-53-53.pngDa debuggt man ein Problem irgendwo zwischen OpenDKIM/DNSSEC/Unbound/iptables und verwechselt beim Testen die Nicht-DNSSEC-Domain mit der DNSSEC-Domain. Ganz großes Kino, wenn man sich wundert, warum der Key immer noch nicht "secure" ist… ||


    Wenn dann zusätzlich die DNS-Server des Domainregistrars nicht synchron sind (siehe Screenshot) und man das nicht gleich merkt, wundert man sich noch mehr über ein Verhalten, das alle paar Minuten anders ist…


    Jetzt muss ich nur noch rausfinden, warum sich OpenDKIM nicht mit meinem lokalen Unbound verträgt.

    Die maximale Ausführungszeit wird aber durch diverse Faktoren beeinflusst. Gerade externe Abfragen (DB, …) können die Zeit deutlich mehr ausnützen, als erlaubt!

    Die set_time_limit()-Funktion und die max_execution_time Konfigurationsdirektive beschränken nur die Ausführungszeit des Skripts selbst. Zeit die für Aktivitäten außerhalb des Skripts aufgebracht wird wie z.B. die Ausführung von Systemaufrufen mit system(), Streamoperationen, Datenbankabfragen usw. werden nicht in die Berechnung der Ausführungszeit mit einbezogen.

    Hat hier schon mal jemand CNAME-Records für TLSA verwendet? Laut RFC sollte das klappen, aber trifft das in der Praxis wirklich zu?

    Code
    _25._tcp.example.net -> CNAME _tlsa.example.net
    _443._tcp.example.net -> CNAME _tlsa.example.net
    
    _tlsa.example.net -> TLSA foobar1
    _tlsa.example.net -> TLSA foobar2

    Es gibt nur ein Problem, das ich nicht gelöst bekomme: Lokale Scripte (wie z.B. Roundcube) können zwar zu dovecot-submissiond verbinden und sich erfolgreich authentifizieren, danach dreht allerdings Postfix durch und verweigert den Versand, weile er behauptet, dass man nicht eingeloggt ist.

    Und es geht doch, mit einem kleinen Umweg… 8o

    Verstehe ich richtig: in meinem Client System rufe ich das auf ?


    […]


    Also dem Gast-System gebe ich bestimmt nicht meine Zugangsdaten für das SCP.

    Du hast es Dir eigentlich schon selbst beantwortet. Am gleichen System sollte man das natürlich nicht ausführen, wenn es nicht unbedingt sein muss.


    Ich persönlich würde es z.B. in einer gut abgesicherten VM zu Hause oder auf einem Raspberry Pi ausführen. Wie genau kann ich Dir allerdings nicht beantworten, da ich die API-Funktionen des SCP nicht nutze.


    Ob man sich diesen Aufwand antun möchte, nur um ein winziges Flag auszulesen, muss jeder für sich entscheiden.

    @nlights: Deine Dateien sieht man leider nicht. ("Seite nicht gefunden")


    Von Weiterleitungen würde ich in Zeiten von SPF/DKIM/DMARC sowieso abraten. Ohne SRS geht das schnell nach hinten los. Und selbst SRS wäre kein Allheilmittel.


    Kannst Du die Mails nicht alternativ mittels IMAP/POP3 vom Zielserver abholen lassen? Viele Systeme und Mailanbieter bieten so etwas an, oft unter der Bezeichnung Sammeldienst, Fetchmail, Getmail, …

    Wenn ich das richtig sehe ist es seit Ende März ein Entwurf, der im September ausläuft ;)

    Afaik wird die finale Version genau wie Draft 28 sein. Warum es noch immer kein offizielles und finales RFC-Dokument gibt, ist eine andere Frage.


    Bevor das nicht draußen ist, wird es allerdings sicher kein Release von OpenSSL 1.1.1 geben.

    […] entspricht also dem Standard.

    Und der wäre? Da ich Deine Postfix Version nicht kenne, sagt das wenig aus. Die Konfiguration und somit einen Standardwert gibt es nämlich erst seit Kurzem.

    Bash
    postconf -d | grep ^header_from_format

    Edit: Die verlinkte Anleitung spricht von Debian Stretch, also Postfix 3.1, da gab es die Konfigurationsmöglichkeit noch nicht. Ok, alles klar… :)

    Der Vorfall beim anderen Anbieter zeigt mal wieder deutlich, wie praktisch der Benachrichtigungsservice bei HIBP von Troy Hunt ist.


    Dieses Mal war es "nur" ein Pastebin Eintrag, der automatisch gefunden wurde. Der wäre eventuell lange unentdeckt geblieben.

    Die Konfigurationen für Filter gibt es in der SOGo Oberfläche bei netcup jedenfalls.


    Ob die derzeit funktionsfähig sind… keine Ahnung. Muss ich mal testen.


    Edit: War erfolgreich, der Filter scheint zu greifen, auch während SOGo nicht geöffnet ist! :thumbup:


    Ich hatte vorher geschrieben, dass es nicht funktioniert.

    Daran war ich selbst schuld, da die Regel fehlerhaft war.

    Wenn das stabil läuft, sehe ich trotzdem keinen Grund mehr, für Postfix mehr als Port 25 nach außen zu öffnen.

    Läuft bisher übrigens größtenteils zufriedenstellend.


    Es gibt nur ein Problem, das ich nicht gelöst bekomme: Lokale Scripte (wie z.B. Roundcube) können zwar zu dovecot-submissiond verbinden und sich erfolgreich authentifizieren, danach dreht allerdings Postfix durch und verweigert den Versand, weile er behauptet, dass man nicht eingeloggt ist. Die Ursache dafür ist wahrscheinlich, dass über XCLIENT der Client nicht auf 127.0.0.1 bzw. ::1 gesetzt werden darf. Ob das wirklich so ist, weiß ich noch nicht sicher, aber es wäre eine gute Erklärung. Andernfalls könnte der dahinter liegende Client sonst vielleicht selbst nochmals XCLIENT ausführen, nehme ich mal an.


    Lässt man die Scripte ganz normal mit STARTTLS oder TLS über die öffentliche IP-Adresse verbinden, klappt es einwandfrei. Aber das ist irgendwie nicht Sinn der Sache… :rolleyes:


    Edit: Eventuell klappt es, wenn man ein Dummy-Interface mit einer privaten IP-Adresse anlegt und Postfix <-> Dovecot darüber kommunizieren lässt? Das muss ich in nächster Zeit einmal ausprobieren! :)

    Ich erinnert mich gerade an einen Fall, wo selbst 128 zu klein war. Probier mal 256 und notfalls 512.


    Die Position stimmt schon, wo es steht.