Posts by voja

    Laut Google wurde die Entwicklung von POP before SMTP für Postfix/Dovecot vor ca. 6 Jahren eingestellt und die Lösung soll nicht mehr verwendet werden.


    Für die aktuellen Versionen von Postfix/Dovecot finde ich auch keine Hinweise mehr auf eine solche Lösung.


    POP before SMTP dürfte damit technisch komplett überholt sein und sollte nicht mehr verwendet werden.


    Seit langem wird SMTP Auth eingesetzt und ich habe schon seit gefühlten Ewigkeiten von keinen Problemen mehr damit gehört.

    Ich kann Icinga2 empfehlen. Die Hosts kann man z.B. auch per Ansible Playbook ins Monitoring aufnehmen. EMail Alerts und Telegram Nachrichten habe ich zur Alarmierung drin.

    Du müsstest die /etc/network/interfaces vom Proxmox und von Deinem Container (von mir aus kannst Du die letzten Ziffern in den IPs z.B. durch X ersetzen) posten. Irgendwo dort würde ich das Problem vermuten, wenn die Container nicht mal den Proxmox Host erreichen können.


    BTW: Proxmox Firewall ist komplett aus?

    Ist die Abweisung der Mail mit dem Gtube Pattern denn ein Anzeichen dafür dass Sieve überhaupt funktioniert? Ein ps aux | grep sieve liefert mir nichts, aber sieve läuft ja soweit ich das verstanden habe auch nicht immer sondern wird nur von Dovecot aufgerufen wenn eine Mail eingeht.

    Schau mal in /var/log/mail.log nach, ob er die eMail weitergeleitet hat. Vielleicht sieht sieve, dass die Umleitung nicht geklappt hat und schreibt deshalb die Mail in die Inbox. Hast Du es mal mit einer normalen Mail versucht?

    Hab den Pfad nochmal überprüft, müsste richtig sein:

    Code
    1. root@mail:/var/vmail/sieve/<meinedomain2.de>/mail/scripts# ls -l
    2. insgesamt 4
    3. -rw-r--r-- 1 vmail vmail 41 Mai 26 17:39 weiterleitung.sieve

    Muss eventuell irgendein Dienst neugestartet werden wenn ich die Datei ändere?

    Eigentlich nicht, da Dovecot die Sieve Files auch replizieren kann und die dann auf dem anderen Server direkt funktionieren.

    Stimmt der Pfad? Bei mir liegen die Scripte unter /var/vmail/sieve/username/scripts/


    Ich manage mein Sieve mit dem roundcube Plugin, auch wenn das eingestampft wird.

    Einzelunternehmer führen doch soweit ich weiß den eigenen Namen im/als Firmennamen.


    Ich bin da schon ne Weile raus, aber als ich Einzelunternehmer war, habe ich zum Beispiel immer „Vorname Nachname Hard- und Software“ auf die Rechnungen geschrieben. Aber auch nur der Name hat gereicht, weil Einzelunternehmer.

    Der Support konnte inzwischen auch das Problem nachvollziehen, aber noch nicht die genaue Ursache finden. Sie versuchen das zu klären, es könnte mit dem Zielprovider zusammen hängen.


    Edit: wobei ich nicht verstehe warum ich vom Root-Server aus den ersten Hop nicht sehe. Das passt für mich nicht ins Bild.

    Hast du schon mal selbst per Rettungssystem getestet?

    Ja, im Rettungssystem kann ich das Problem genau so feststellen.


    root@grml ~ # ip addr add 2a03:4000:10:29c::1/64 dev ens3

    root@grml ~ # /sbin/ip -6 route add default via fe80::1 dev ens3

    RTNETLINK answers: File exists


    D.h. ich musste die IP hinzufügen, aber die Default Route war schon gesetzt. Das Problem tritt auf genau wie vorher:


    root@grml ~ # traceroute6 2001:4178:2:1113::42

    traceroute to (2001:4178:2:1113::42) from 2a03:4000:10:29c::1, 30 hops max, 24 byte packets

    1 * * *

    2 * * *

    3 * * *

    ^C


    Gegenprobe Google, die auch vom Support angewendet wurde:


    root@grml ~ # traceroute6 google.de

    traceroute to (2a00:1450:4001:816::2003) from 2a03:4000:10:29c::1, 30 hops max, 24 byte packets

    1 2a03:4000:10::3 (2a03:4000:10::3) 0.715 ms 2.094 ms 1.121 ms

    2 2a00:11c0:47:3::1e (2a00:11c0:47:3::1e) 0.49 ms 0.495 ms 0.339 ms

    3 2a00:11c0:47:1:47::141 (2a00:11c0:47:1:47::141) 3.6 ms 3.779 ms 3.596 ms

    4 2001:4860:1:1::6bc (2001:4860:1:1::6bc) 3.786 ms 3.906 ms 3.785 ms

    5 2001:4860:0:11e0::1 (2001:4860:0:11e0::1) 4.019 ms 3.985 ms 3.9 ms

    6 2001:4860:0:1::6f9 (2001:4860:0:1::6f9) 4.075 ms 3.927 ms 3.924 ms

    7 fra16s07-in-x03.1e100.net (2a00:1450:4001:816::2003) 3.528 ms 3.483 ms 3.543 ms

    Der Support meinte auch schon die Netze werden jeweils korrekt announced und sollten erreichbar sein. Sind sie aber nicht.

    br0 ist eine Bridge über die Container mit public IPs versorgt werden.


    lxdbr0 ist die Default Bridge von LXD.


    Edit: bridge_ports ist jeweils none


    Die veth Interfaces gehören zu den lxc Containern. Zwei hängen an br0, einer an lxdbr0.


    Ob ich wirklich alle Bridges abgedreht kriege müsste ich mal gucken.


    tshark werde ich mir später mal anschauen.