www.fabiankeil.de/blog-surrogat/2006/02/15/domainfactory-mail-probleme.html
Zur Abwechselung jedoch nicht beim Senden, sondern beim Empfangen. Statt mit neuer Mail erfreute Sylpheed-Claws
mich mit der hilfreichen Meldung Can't connect to server
. Das Logwindow
wusste auch nicht
mehr, auf der Konsole stand immerhin:
** (sylpheed-claws:1019): WARNING **: sock_connect_address_list_async: connection to pop.fabiankeil.de:995 failed ** (sylpheed-claws:1019): WARNING **: can't connect to server. ** (sylpheed-claws:1019): WARNING **: [12:50:37] Connection failed. ** (sylpheed-claws:1019): WARNING **: sock_connect_address_list_async: connection to pop.fabiankeil.de:995 failed ** (sylpheed-claws:1019): WARNING **: can't connect to server. ** (sylpheed-claws:1019): WARNING **: [12:50:39] Connection failed.
Für DNS-Probleme hat Sylpheed-Claws eine andere Fehlermeldung, blieben noch mögliche Probleme mit der Firewall (seit ein paar Tagen spiele ich mit dem von OpenBSD geerbten PF) und dem Server selbst.
pfctl -sa meldete keine blockierten ausgehenden Verbindungen, die
PF-Konfiguration hatte ich zudem einige Zeit nicht mehr geändert.
telnet brachte Erleuchtung: über Nacht wurde von Domainfactory der für verschlüsseltes
Mail-Abholen zuständige Port 995 geschlossen.
fk@TP51 ~ $telnet pop.fabiankeil.de 995 Trying 80.67.18.23... telnet: connect to address 80.67.18.23: Connection refused telnet: Unable to connect to remote host
Diese unbedeutende Änderung wurde nicht angekündigt, auch auf der Domainfactory-Website habe ich keine Informationen dazu gefunden.
Die E-Mail-Konfigurations-Anleitung
nennt für verschlüsselte Verbindungen nur die Server sslmailpool.ispgateway.de
und
smtprelaypool.ispgateway.de
, bis gestern habe ich pop.fabiankeil.de
und
smtp.fabiankeil.de
benutzen dürfen. Auch sie sind allerdings nur Aliase für einen Sammel-Server,
den ich mit einem Haufen Spammer teile.
Nach der Anpassung der Sylpheed-Claws-Einstellungen kann ich wieder empfangen und senden, doch der Sinn der Aktion bleibt im Dunkeln.
Möglicherweise soll deutlich gemacht werden, dass der Kunde den Mail-Server nicht für sich hat, auf Grund der regelmäßigen Spamcop-Sperrungen wird das aber niemanden mehr überraschen und für unverschlüsselte Verbindungen stehen die alten Adressen weiter zur Verfügung.
Bei der Zertifikat-Verwaltung gibt es auch keine Erleichterung, das Zertifikat des neuen Servers muss ebenfalls noch abgenickt werden, wurde folglich nicht von einer anerkannten Instanz signiert.