[Problem] checkmaild und SSL?

[60plus]

Hi,

ich habe das aktuelle Freetz mit checkmaild auf der 7390, leider wird über imap.gmx.de und secureimap.t-online.de wird vom jeweiligen Server abgelehnt "Ihre Verbindung ist nicht verschluesselt. Aktivieren Sie SSL in Ihrem Mailprogramm".
Gibt es vielleicht eine Möglichkeit.

Danke

mfg

60plus

 

[meiser79]

Ja, kombiniere stunnel mit checkmaild, dann kannst du auch SSL nutzen.

https://www.stunnel.org/pipermail/stunnel-users/2013-January/004065.html

 

[60plus]

Hi,

ich danke Dir und melde mich wenn es funkt.

mfg
60plus

 

[60plus]

Hier funktioniert etwas nicht

Feb 11 15:32:42 fritz daemon.info CheckMailD: shutdown
Feb 11 15:32:42 fritz daemon.info CheckMailD: 0.4.7 closed [11.02.2017 - 15:32:42]
Feb 11 15:32:44 fritz daemon.info CheckMailD: check 1 Account(s) every 5min without Logging
Feb 11 15:33:14 fritz daemon.debug stunnel: LOG7[main]: Found 1 ready file descriptor(s)
Feb 11 15:33:14 fritz daemon.debug stunnel: LOG7[main]: FD=4 events=0x2001 revents=0x0
Feb 11 15:33:14 fritz daemon.debug stunnel: LOG7[main]: FD=7 events=0x2001 revents=0x1
Feb 11 15:33:14 fritz daemon.debug stunnel: LOG7[main]: Service [imap] accepted (FD=3) from 127.0.0.1:35995
Feb 11 15:33:14 fritz daemon.debug stunnel: LOG7[1]: Service [imap] started
Feb 11 15:33:14 fritz daemon.debug stunnel: LOG7[1]: Option TCP_NODELAY set on local socket
Feb 11 15:33:14 fritz daemon.notice stunnel: LOG5[1]: Service [imap] accepted connection from 127.0.0.1:35995
Feb 11 15:33:14 fritz daemon.info stunnel: LOG6[1]: failover: round-robin, starting at entry #1
Feb 11 15:33:14 fritz daemon.info stunnel: LOG6[1]: s_connect: connecting 194.25.134.115:993
Feb 11 15:33:14 fritz daemon.debug stunnel: LOG7[1]: s_connect: s_poll_wait XXX.XX.XXX.115:993: waiting 10 seconds
Feb 11 15:33:14 fritz daemon.notice stunnel: LOG5[1]: s_connect: connected XXX.XX.XXX.115:993
Feb 11 15:33:14 fritz daemon.notice stunnel: LOG5[1]: Service [imap] connected remote server from 192.168.178.1:51167
Feb 11 15:33:14 fritz daemon.debug stunnel: LOG7[1]: Option TCP_NODELAY set on remote socket
Feb 11 15:33:14 fritz daemon.debug stunnel: LOG7[1]: Remote descriptor (FD=8) initialized
Feb 11 15:38:14 fritz daemon.info stunnel: LOG6[1]: s_read: s_poll_wait: TIMEOUTbusy exceeded: sending reset
Feb 11 15:38:14 fritz daemon.notice stunnel: LOG5[1]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
Feb 11 15:38:14 fritz daemon.debug stunnel: LOG7[1]: Remote descriptor (FD=8) closed
Feb 11 15:38:14 fritz daemon.debug stunnel: LOG7[1]: Local descriptor (FD=3) closed
Feb 11 15:38:14 fritz daemon.debug stunnel: LOG7[1]: Service [imap] finished (0 left)
Feb 11 15:38:14 fritz daemon.info CheckMailD: IMAP Server ()
Feb 11 15:38:14 fritz daemon.info CheckMailD: Account 0 skipped
Feb 11 15:38:14 fritz daemon.debug stunnel: LOG7[1]: str_stats: 1 block(s), 32 data byte(s), 58 control byte(s)
Feb 11 15:38:14 fritz daemon.debug stunnel: LOG7[1]: str_stats: 32 byte(s) at network.c:680
Feb 11 15:38:25 fritz kern.warn kernel: system-load 9  loadavg 0.0 0.0 0.0 - 103 tasks:0 % curr:busybox(0 %) max:vdsld(0 %, pid:867), readytorun: 2, pgfault 64/s (max 1 avg 1.0)

hat jemand eine Idee

 

[PeterPawn]

Ja, viele ... sogar zuviele, um sie alle aufzuschreiben.

Also wirst Du wohl oder übel ein paar zusätzliche Informationen zusammensuchen müssen.

Ein (durchaus vielversprechender) Ansatz könnte es ja sein, sich mit der "debug"-Option in der "stunnel"-Konfiguration zu befassen. Steht die tatsächlich auch für das, was man hinter dem Namen vermuten würde, wäre das Ergebnis wohl ein ausführlicheres Protokoll, in dem man dann vielleicht auch etwas sehen kann.

Auch wäre es vermutlich sinnvoller, den Tunnel erst einmal mit einem Telnet-Client o.ä. zu testen ... das muß ja nun nicht sofort auch noch ein Programm sein, wo man gar nicht sehen kann, was das zu diesem Zeitpunkt eigentlich genau macht. Das könnte man zwar in den Quelltexten erkunden, Deine Frage läßt aber bei mir den Verdacht aufkommen, daß es sich dabei eher nicht um ein Terrain handelt, auf dem Du Dich sicher bewegst.

Solltest Du ein ausführlicheres Protokoll einstellen wollen, wäre es vielleicht auch eine Überlegung wert, ob es sich dabei tatsächlich um PHP-Code handelt. Warum ist das wichtig? Das automatische Coloring hebt das "#1" in rot deutlich hervor ... der Leser wird also automatisch an diese Stelle "gezogen" (zumindest mir ging es so, aber ich könnte mich auch glatt angestellt haben) und dabei ist die vollkommen uninteressant. Es gibt für derartige Blöcke auch ein "ganz normales Code-Tag", da kann man dann die Farbgebung selbst steuern und das sollte man dann auch nur machen, wenn man die Aufmerksamkeit des Leser tatsächlich an diese Stelle lenken will.