abbrechen
Suchergebnisse werden angezeigt für 
Stattdessen suchen nach 
Meintest du 
Aktuelle Eilmeldungen

TV: Kabelfernsehen wird Mietersache. Jetzt handeln!
Deine Störung ist nicht dabei? Dann nutz unseren Störungsfinder!

1

Frage

2

Antwort

3

Lösung

Seit dem 23.02.2023 kein Zugriff per IMAP/IMAPS auf MailServer
an-dre-as
Netzwerkforscher
Netzwerkforscher

Hallo zusammen!

 

Ich habe einen Vodfone Kabelanschluss in NRW mit Dual Stack und nutze eine Fritz!Box 6690.

Auf einer Synology DS916+ nutze ich den Synology MailPlus Server, der meine diversen externen MailKonten  (z.B. bei GMX oder Web.de) abruft. Das läuft auch einwandfrei und per Synology MailPlus (WebClinet) kann ich auch auf den Server und meine Mails zugreifen.

 

Seit dem 23.02.2023 kann ich jedoch mit meinem MailClient Thunderbird nicht mehr per IMAP von externe, über meine DynDNS-Adresse (***.myds.me) zugreifen. Ich habe das von unterschiedlichen PC und mit unterschiedlichen MailClients getestet. Der Zugriff über die interne IP funktioniert.

Trotz Portfreigabe (110, 995, 25, 587, 465, 143, 993) in der Fritzbox für IPv4 und IPv6 werden die Ports für IMAP bzw. IMAPS offenbar geblockt. Es ist keine weiter Firewall aktiviert.

 

Bis zum 23.02.2023 lief alles störungsfrei. Ich habe aktiv keine Veränderungen vorgenommen. Die Einstellungen am NAS, MailServer, Thunderbird, BlueMail und Fritzbox habe ich mehrfach überprüft, aber ich kann keine Fehlkonfiguration feststellen.

 

Blockiert die Vodafone diverse Ports oder Protokolle oder hat jemand eine Idee oder Tip? 

6 Antworten 6
MaBö
Daten-Fan
Daten-Fan

Ich habe das gleiche Problem seit letzter Woche. Online auf Vodafonemail.de geht alles wunderbar. Doch der Abruf mit einem externen Programm absolut nicht möglich. Ich habe in der zwischenzeit verschiedene Mailprogramme ausprobiert. Geht alles nicht. Und die Mobil App "Mail & Cloud" ist auch noch nicht ausgereift für @vodafone.de.

 

Hier muss dringend geholfen werden. So kann es nicht weiter gehen. Portfreigaben auf der Fritzbox hilft ebenso nicht.

an-dre-as
Netzwerkforscher
Netzwerkforscher

Dann liegt die Lösung offenbar bei Vodafone. Daher werde ich einen  Servicefall aufmachen  müssen.

Ich habe aber zunehmend den Verdacht, das Vodafone nicht der richtige Provider für meinen Bedarf ist.

wrwr
App-Professor
App-Professor

Gab es hier eine Lösung?

an-dre-as
Netzwerkforscher
Netzwerkforscher

Ja! In meinem Fall hat das Update des Mailservers von Synology dafür gesorgt, dass IMAP bzw. IMAPS auf 993 und 143 nicht mehr IPv6 zugeordnet waren.

Kann man als root angemeldet mit "netstat -an | grep port" auf der SSH Konsole testen.

 

Lösung:

netstat -an | grep 993
ergibt bei nur:

tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN
tcp6 <- fehlt !

Modifiziere mit root-Rechten die Datei:
/volume1/@appstore/MailPlus-Server/etc/template/10-master.template
entferne (oder mir # auskommentieren) die 14 Zeile:

address = __NODE_IP__

Diese sorgt dafür, dass die Adresse später auf 0.0.0.0 (IPv4) gebunden ist!

Anschließend: netstat -an | grep 993

tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN
tcp6 0 0 :::993 :::* LISTEN

Das Ganze überlebt leider kein Update des MailPlus-Servers.
Man kann sich aber ein Script basteln, welches die Manipulationen nach Update wieder korrigiert.

sed -i "/address = __NODE_IP__/d" /volume1/@appstore/MailPlus-Server/etc/template/10-master.template

Quelle: https://www.synology-forum.de/threads/mailplus-server-und-ipv6-imap-geht-nicht.103929/

wrwr
App-Professor
App-Professor

Danke. Die Zeile habe ich aber mehrfach:

====

#default_process_limit = 100
#default_client_limit = 1000

# Default VSZ (virtual memory size) limit for service processes. This is mainly
# intended to catch and kill processes that leak memory before they eat up
# everything.
#default_vsz_limit = 256M
# FIXME: workaround for out of memory
default_vsz_limit = 0
mail_never_cache_fields = *

# Login user is internally used by login processes. This is the most untrusted
# user in Dovecot system. It shouldn't have access to anything at all.
default_login_user = dovecot


# Internal user is used by unprivileged processes. It should be separate from
# login user, so that login processes can't disturb other processes.
default_internal_user = root

protocols = $protocols imap pop3
service imap-login {
service_count = 0
process_limit = 256
inet_listener imap {
address = __IMAP_NODE_IP__
port = __IMAP_PORT__
}
inet_listener imaps {
address = __NODE_IP__
port = __IMAPS_PORT__
ssl = yes
}

# Number of connections to handle before starting a new process. Typically
# the only useful values are 0 (unlimited) or 1. 1 is more secure, but 0

# is faster. <doc/wiki/LoginProcess.txt>
#service_count = 1

# Number of processes to always keep waiting for more connections.
#process_min_avail = 0

# If you set service_count=0, you probably need to grow this.
#vsz_limit = $default_vsz_limit
}

service pop3-login {
service_count = 0
process_limit = 256
inet_listener pop3 {
address = __NODE_IP__
port = __POP3_PORT__
}
inet_listener pop3s {
address = __NODE_IP__
port = __POP3S_PORT__
ssl = yes
}
}

service indexer-worker {
process_limit = __NPROC__
}
#service submission-login {
# inet_listener submission {
# #port = 587
# }
#}


[...]

====

Welche muss ich auskommentieren?

Alle?
Braucht es einen Neustart?
Danke im Voraus

 

 

 

an-dre-as
Netzwerkforscher
Netzwerkforscher

Sorry, für die späte Antwort! Ich habe heute ein update vom Mail-Server durchgeführt und musste den Spaß wiederholen.

Es geht ja hier um imaps. Daher geht es um die Zeile in diesem Abschnitt:

}
inet_listener imaps {
address = __NODE_IP__
port = __IMAPS_PORT__
ssl = yes
}

Ich habe die Zeile address = __NODE_IP__  hier gelöscht.

Dann den Mail-Server einmal stoppen und wieder starten.

Läuft! 🙂

 

Gruß

Andreas