Open papiertiger960ff opened 1 year ago
Hallo @papiertiger960ff , danke für das Feedback.
Grundsätzlich lieber keine Sammeltickets. Einzelne Tickets lassen sich besser recherchieren und einzeln abarbeiten. Es ist unwahrscheinlich, dass ich alle angesprochenen Punkte gemeinsam abarbeite.
Ok, ich habe III. jetzt mal ausgefädelt. Soll ich I. und II. auch noch trennen? Nach meinem Dafürhalten sind beide Punkte miteinander verflochten: Wenn IPv6 VOrrang bekommt, könnte das zu Problemen führen, falls der Fallback zu IPv4 nicht funktioniert. Und mit Problem meine ich, dass die Software dann hängt und garnicht mehr reagiert. (Die mildere Variante wäre dann natürlich noch, dass es „nur“ einen Verbindungsfehler gibt, weil der nicht funktionierende Fallback unterbleibt.)
Bei Minecraft (auch Java-basiert) haben Probleme mit dem unterbleibenden Fallback von IPv6 zu IPv4 dazu geführt, dass die Entwickler die Vorrangregel auf den Kopf gestellt haben: IPv4 hat für die VErbindung zum Gameserver Vorrang; IPv6 ist nur der Fallback für den Fall, dass ein Server wirklich keinen A-Record hat. (Damit ist Minecraft allerdings an IPv6-only-Anschlüssen unspielbar, falls der Server Dualstack ist.)
Darüber hinaus vermute ich, dass meine Verbindungsprobleme eine Auswirkung meines Double NAT sein könnten. D. h. die Problemlage könnte sich mit IP6 bessern.
Soll ich I. und II. auch noch trennen?
Das kann so bleiben, vielen Dank!
Darüber hinaus vermute ich, dass meine Verbindungsprobleme eine Auswirkung meines Double NAT sein könnten. D. h. die Problemlage könnte sich mit IP6 bessern.
Könnte für schwer sein, das Problem überhaupt zu reproduzieren, würde mich ggf. melden, wenn ich daran arbeite.
Timeout-Settings:
IMAP: https://javaee.github.io/javamail/docs/api/com/sun/mail/imap/package-summary.html SMTP: https://javaee.github.io/javamail/docs/api/index.html?com/sun/mail/smtp/package-summary.html
String-Werte statt Integer: https://stackoverflow.com/questions/18970409/why-javamail-connection-timeout-is-too-long
So, ich hab was: Java hat zwei Einstellungen, mit denen man die IP-Version beeinflussen kann. Diese heißen java.net.preferIPv4Stack und java.net.preferIPv6Addresses. Dokumentiert sind beide hier: https://docs.oracle.com/javase/7/docs/api/java/net/doc-files/net-properties.html
preferIPv6Addresses scheint im Source Code garnicht vorzukommen; preferIPv4Stack hingegen wird an mehreren STellen auf true gesetzt, womit IPv6 natürlich unterbunden wird.
https://github.com/jlawyerorg/j-lawyer-org/search?q=preferIPv4Stack
Ich würde vorschlagen, zumindest preferIPv4Stack auf false zu setzen. preferIPv6Addresses sollte (auch wenn mir das überhaupt nicht gefällt) solange auf false bleiben, bis sichergestellt ist, dass der Fallback von IPv6 nach IPv4 zuverlässig funktioniert. Dafür sollte insbesondere die Timeout- und Hängerproblematik gelöst werden.
Alle diese Fundstellen sind Testkonfigurationen, die so nicht zum Tragen kommen. Ich muss erst schauen, wo diese Einstellung herkommt. (Möglich, dass auch eine Bibliothek diesen Wert setzt)
Uuuuups, ich hab mich also nicht umsonst gefragt, was nbproject ist.
Ok, also: Das IPv6-Problem lässt sich einfacher lösen als erwartet. Ich musste noch nicht einmal den Compiler bemühen. Wer ad hoc auf einen funktionierenden Mailclient angewiesen ist, öffnet /usr/local/bin/j-lawyer-Client
im Editor und ändert dort an genau 2 Stellen -Djava.net.preferIPv4Stack=true
in -Djava.net.preferIPv4Stack=false
. Dann funktioniert der Mailclient.
Im Quellcode liegt der Fehler im Repository j-lawyer-client-installer in der Datei j-lawyer-client-installer.install4j, die irgendwie für die Generierung von /usr/local/bin/j-lawyer-Client
zuständig ist. Anbei ein Diff.
fix_ipv6.diff.txt
So, ich bin mal einen Schritt weiter gegangen und habe ausprobiert, was passiert, wenn man -Djava.net.preferIPv6Addresses auf true setzt. Ergebnis:
Resümee: Ich kann mit -Djava.net.preferIPv6Addresses=true besser arbeiten und werde diesen Wert auch so beibehalten. Auf die Allgemeinheit kann diese Einstellung aber vorerst nicht losgelassen werden, weil
Guten Tag / Grüezi / Moin / Grüß Gott / Servus,
ich würde gerne mehrere Bugs im integrierten Mailclient melden.
Serverversion: 2.0.1.0 / Clientversion: 2.0.1.0
I. Kein IPv6 Ich war bisher fest davon ausgegangen, dass der Mailclient IPv6 unterstützen würde und dass der Mailverkehr mit selbigem auch längst darüber laufen würde. Als ich nun versucht habe, den neuen Mailserver einzurichten, kam plötzlich die nachstehende Ausschrift: E-Mail-Einstellungen VErsand / Postausgang nicht korrekt: Couldn't connect to host, port: submission.bielefeld.example.net, 587; timeout -1; submission.bielefeld.example.net Diese Angaben sind nicht wirklich aussagekräftig. Aber vor dem Hintergrund, dass ich meinen alten Server problemlos erreichen kann und netstat dort dann eine IPv4-VErbindung anzeigt, gehe ich davon aus, dass der Mailclient als IPv4-only implementiert ist. ICh möchte anregen, dass dieser Bug korrigiert und IPv6 künftig bevorzugt genutzt wird.
II. Client friert ein wegen Netzwerkproblemen Der Mailclient scheint irgendwie ein Problem mit der Netwerkkommunikation zu haben: ZUnächst einmal scheint ein Timeout zu fehlen, der dazu führt, dass hängende Verbindungen irgendwann abgebrochen werden. Dazu kommt aber auch noch, dass bei hängenden Netwerkverbindungen das ganze Programm blockiert wird und sich garnichts mehr bedienen lässt. D. h. J-Lawyer friert bei der Bearbeitung von E-Mails regelmäßig ein und es bleibt nur noch der Abschuss. Die Problematik geht bei Funkverbindungen (Mobilfunk, Richtfunk) ins Extreme. Bei schnurgebundenem Internet mit Double-NAT tritt die Problematik hingegen deutlich seltener auf; Allerdings hatte ich auch hier schon die Notwendigkeit, J-Lawyer abzuschießen. Evtl. würde sich die Situation auch schon verbessern, wenn der Client IPv6 unterstützen würde - dann würden nämlich die beiden NAT-Router als Fehlerquelle herausfallen. Anmerkung: Alle anderen Mailclients, die ich bisher unter den Fingern hatte, kommen mit Netzwerkproblemen deutlich besser klar.
III. EinstellungsdialogZUletzt würde ich ganz gerne noch ein paar Punkte zum Einstellungsdialog loswerden:1)Wenn ich im Einstellungsdialog das Emailkonto wechsel, ohne zu speichern, werden meine Eingaben stillschweigend gelöscht. Das sollte so eigentlich nicht passieren.--> ausgefädelt in #1883 2)TLS wird im Dialog fälschlich als SSL tituliert.--> ausgefädelt in #1882 3)Der Default-Port für SMTP Submission sollte 587 und nicht 25 sein. Port 25 ist sehr streng reglementiert, ich musste für meinen eigenen Mailserver erst kürzlich einen Genehmigungsantrag mit 3fachem Durchschlag schreiben, um den benutzen zu dürfen. Von daher halte ich es für verfehlt, diesen Port für die einfache Einlieferung zu nutzen.--> ausgefädelt in #1884 4)Bei IMAP sollte es eine Möglichkeit geben, die Portnummer einzustellen. ICh habe das Problem erstmal umschifft, indem ich den Server umkonfiguriert habe.(Dublette von #937)