Na co dzień na komputerze z poczty korzystam za pomocą programu Mozilla Thunderbird, który towarzyszy mi już pewnie kilka lat, i mam wrażenie, że jego rozwój „ostatnio” trochę jakby zwolnił, a do tego jakieś 14-15 kont IMAP zaczyna dawać mu w kość, i to mimo 16 GB pamięci RAM i całkiem porządnego procesora (pewnie to też w jakiejś mierze zasługa/kwestia kilkudziesięciu kont POP3, i sięgającego kilka lat archiwum wiadomości).

Dlatego od jakiegoś czasu (niespiesznie) rozglądam się za jakąś alternatywą, i tu pojawił się pomysł, by może zamiast programu instalowanego na komputerze postawić jakiegoś webmaila (program pocztowy w formie strony internetowej).

I choć na razie zamiennika dla Thunderbirda nie znalazłem, to podczas poszukiwań trafiam na różne „problemy” – większością z nich nie ma nawet co Wam głowy zawracać, ale wczoraj testowałem polecany przez wielu RainLoop, i wprawdzie skrypt/webmail po krótkim teście wyleciał, to problem na jaki trafiłem wydaje się na tyle ciekawy, że być może kogoś z Was zainteresuje, komuś z Was się przyda…

RainLoop, Gmail i IPv6

Sama instalacja i konfiguracja RainLoop jest na tyle prosta, że nie będę się nad nią rozpisywał – nie trzeba nawet bazy danych, chyba, że chcecie korzystać z kontaktów.

Skrypt zainstalowałem w najnowszej dostępnej wersji, czyli 1.9.4.398:

Podstawowa konfiguracja, dodanie kilku obsługiwanych domen – wszystko OK, przynajmniej do momentu dodania domeny na której poczta jest w ramach Google Apps.

Ten sam test na domyślnie dodanej poczcie Gmail i ten sam błąd:

stream_socket_client(): unable to connect to ssl://imap.gmail.com:993 (Connection timed out)

stream_socket_client(): unable to connect to ssl://smtp.gmail.com:465 (Connection timed out)

By zweryfikować, czy nie jest to jakiś globalny problem oprócz własnych domen z pocztą m.in. w Zoho i Rackspace, sprawdziłem jeszcze Outlook.com – wszystko OK:

Gdy nie wiadomo o co chodzi, Telnet może pomoże

Z racji tego, że RainLoop zainstalowałem na nowym/kolejnym serwerze VPS w DigitalOcean, postanowiłem sprawdzić, czy przypadkiem przydzielony do niego adres IP nie ma nałożonej jakiejś blokady od Google.

patryk@vps08:~$ telnet smtp.gmail.com 465
Trying 2a00:1450:4013:c01::6d...

patryk@vps08:~$ telnet imap.gmail.com 993
Trying 2a00:1450:400c:c09::6c...

Od razu widać, że następuje próba połączenia z serwerami Google za pomocą protokołu IPv6, który faktycznie został włączony dla tego serwera podczas tworzenia, ale nie jest (jeszcze) wykorzystywany, a z długiego czasu „łączenia się z” można było wywnioskować, że pewnie tu jest problem (time out).

Wyłączam IPv6

Z racji tego, że IPv6 na tym serwerze został włączony niejako rutynowo, a nie jest obecnie wykorzystywany (tyle lat, a cały czas IP4 dominuje) to postanowiłem wyłączyć tymczasowo obsługę IPv6 w systemie i sprawdzić, czy zgodnie z moimi przypuszczeniami rozwiąże to problem.

Wprawdzie można kombinować coś tam na etapie jądra systemy, czy… To ja wybrałem metodę prosta, skuteczną, i co być może najważniejsze – równie prosto i szybko odwracalną:

sudo nano /etc/network/interfaces

I komentuje (za pomocą znaku #) linijki odpowiedzialne za IPv6, co w moim przypadku wygląda tak:

#iface eth0 inet6 static
#address A1B2:C3D4:0000:2121:0000:0000:0081:9001
#netmask 64
#gateway A1B2:C3D4:0000:2121:0000:0000:0000:0001
#autoconf 0
#dns-nameservers 2001:4860:4860::8844 2001:4860:4860::8888 8.8.8.8

Na koniec restart (ustawień) interfejsu:

sudo /etc/init.d/networking restart

Szybki test Telnetem:

patryk@vps08:~$ telnet imap.gmail.com 993
Trying 74.125.136.109...
Connected to gmail-imap.l.google.com.
Escape character is '^]'.

patryk@vps08:~$ telnet smtp.gmail.com 465
Trying 74.125.136.108...
Connected to gmail-smtp-msa.l.google.com.
Escape character is '^]'.

Działa, co potwierdza również test konfiguracji Gmail w RainLoop: