Dotaz: Nefunkční fetchmail.

[Pfemir]

Dobrý den,

používám několik let postfix + dovecot + fetchmail a včera mi fetchmail přestal fungovat. Do ničeho jsem nevrtal, takže nevím co se mohlo stát. Děje se to, že když spustím fetchmail, tak se naloguje na mailserver, zjistí nové zprávy a začne stahovat první z nich. V této chvíli to vytuhne a po vypršení time outu se spojení ukončí. Na vzdáleném serveru problém zřejmě není, protože mám e-mailové schránky na více serverech a dělá to u všech. Zkoušel jsem stahovat přes IMAP i přes POP3 a je to stejné. Zkoušel jsem fetchmail odinstalovat a naistalovat, ale bez změny.

Tady je výpis z fetchmailu.

fetchmail: 6.3.26 querying Centrum (protocol IMAP) at Thu Oct 23 12:35:47 2014: poll started
Trying to connect to 46.255.224.65/143...connected.
fetchmail: IMAP< * OK Centrum.cz IMAP4rev1 balIMap server ready
fetchmail: IMAP> A0001 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ IDLE QUOTA NAMESPACE CHILDREN ID UNSELECT XLIST UIDPLUS SASL-IR AUTH=PLAIN
fetchmail: IMAP< A0001 OK CAPABILITY completed
fetchmail: IMAP> A0002 LOGIN "e_xxx" *
fetchmail: IMAP< * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ IDLE QUOTA NAMESPACE CHILDREN ID UNSELECT XLIST UIDPLUS
fetchmail: IMAP< A0002 OK Welcome e_xxx@centrum.cz
fetchmail: IMAP> A0003 SELECT "INBOX"
fetchmail: IMAP< * 4 EXISTS
fetchmail: IMAP< * 4 RECENT
fetchmail: IMAP< * OK [UNSEEN 1] First unseen message
fetchmail: IMAP< * OK [UIDNEXT 58944] Predicted next UID
fetchmail: IMAP< * OK [UIDVALIDITY 88004] UIDs valid
fetchmail: IMAP< * FLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded)
fetchmail: IMAP< * OK [PERMANENTFLAGS (\Deleted \Flagged \Answered \Seen \Draft $Forwarded)] Can be changed permanently
fetchmail: IMAP< A0003 OK [READ-WRITE] SELECT completed
fetchmail: IMAP> A0004 EXPUNGE
fetchmail: IMAP< A0004 OK EXPUNGE completed
4 messages for e_xxx at Centrum.
fetchmail: IMAP> A0005 FETCH 1:4 RFC822.SIZE
fetchmail: IMAP< * 1 FETCH (RFC822.SIZE 144750)
fetchmail: IMAP< * 2 FETCH (RFC822.SIZE 77148)
fetchmail: IMAP< * 3 FETCH (RFC822.SIZE 221856)
fetchmail: IMAP< * 4 FETCH (RFC822.SIZE 6979)
fetchmail: IMAP< A0005 OK FETCH completed
fetchmail: IMAP> A0006 FETCH 1 RFC822.HEADER
fetchmail: IMAP< * 1 FETCH (RFC822.HEADER {2147}    <--------------------------------- TADY TO VYTUHNE

reading message e_xxx@gm-ego.centrum.cz:1 of 4 (2147 header octets) 
Trying to connect to 81.95.108.77/25...connection failed.
fetchmail: connection to localhost:smtp [81.95.108.77/25] failed: Connection timed out.
fetchmail: Connection errors for this poll:
name 0: connection to localhost:smtp [81.95.108.77/25] failed: Connection timed out.
fetchmail: SMTP connect to localhost failed
fetchmail: IMAP> A0007 LOGOUT
fetchmail: IMAP< )
fetchmail: IMAP< A0006 OK FETCH completed
fetchmail: IMAP< * BYE Centrum Mail IMAP Server logging out
fetchmail: IMAP< A0007 OK LOGOUT completed
fetchmail: SMTP transaction error while fetching from e_xxx@Centrum and delivering to SMTP host localhost
fetchmail: 6.3.26 querying Centrum (protocol IMAP) at Thu Oct 23 12:37:55 2014: poll completed
fetchmail: Query status=10 (SMTP)
fetchmail: normal termination, status 10

V tuto chvíli už nevím na co se podívat, na co se zaměřit, co dál vyzkoušet. Může te mi někdo poradit?

Díky.

Odpovědi

[Petr Šobáň]

A jsou v těch účtech normální maily? Skus se mrknout normálně přímo.

Mě se stala ta stejná věc před hromadou roku když jsem byl ještě připojen přes vytáčenou linku, najednou se fetchmail zakous pořád do jedné správy a nestáhnul ji, ani poštovním programem nešla stáhnout ani smazat přes pop3.

V tom mailu byl nějaký virus.

Už nevím jak jsem ji smazal zda přes ssh či ftp (k účtu byl i ftp přístup).

A pak zase vše fungovalo OK.

[Pfemir]

Ano jsou, to jsem se díval.

Problém asi je v tomto:

Na začátku se fetchmail naloguje na mail server, v mém případě centrum.cz, což je 46.255.224.65/143. Pak si pozjišťuje jestli tam jsou nové zprávy, atd. a když začne tu první stahovat, tak se chce připojit na 81.95.108.77/25 a to se mu nepodaří, viz. výpis:

.
.
.
Trying to connect to 81.95.108.77/25...connection failed.
fetchmail: connection to localhost:smtp [81.95.108.77/25] failed: Connection timed out.
.
.
.

Ale to vůbec nevím co je za adresu, proč se na ní připojuje. Asi ji mám někde nastavenou, ale nemůžu ji nikde najít. Hlavně jsem do žádného nastavení nevrtal, takže nechápu.

[Petr Šobáň]

No to co stáhne chce předat SMTP serveru takže jakému SMTP serveru to předáváš aby to doručil do schránek?

77.108.95.81.in-addr.arpa name = vpsfc108077.active24.cz.

Je to tvůj SMTP server? Pokud ne třeba skontrolovat konfiguraci fetchmailu.

Pokud ano skontrolovat proč tvůj SMTP server nechce přijímat - firewall, autorizace.....

[Pfemir]

Není, já používám SMTP svého providera. V configu fetchmailu žádné SMTP nastavení nemám a ani jsem nikdy neměl, takže předpokládám, že si SMTP nastavení přebírá z postfixu.

[Petr Šobáň]

No tak si to nastav co má se staženým mailem dělat kam ho odeslat.

[Pfemir]

Budu muset nastudovat jak na to, ale nechápu, jak to, že mi to několik let jelo takto. Dokonce tu mám na serveru více uživatelů a všem to do včerejška stahovalo.

[Petr Šobáň]

Protože to třeba posílalo na localhost a teď se ti změnil DNS server a místo localhost 127.0.0.1 tam máš něco jiného.

[Pfemir]

Přiznám se, že tomuhe až tak moc nerozumím. Jestli máš trochu času a mohl by jsi to trochu objasnit a hlavně pomoct zprovoznit, byl bych rád.

Nechápu jak se mi změnil DNS server? Mám pevnou IP adresu na které mám svůj server, na něm DNS nemám, běží mi na něm, kromě jiného, postfix, dovecot, fetchmail a procmail. V postfixu mám SMTP nastaveno na svého providera. SMTP funguje, e-maily odchází. Proč mi tedy, z ničeho nic, fetchmail doručuje místo na localhost na 81.95.108.77 ? Tuto adresu jsem nikde nedával, nikde jsem ji nenašel, tak jak na ní fetchmail přišel?

Díky.

[Pfemir]

Tak nakonec jsem musel všem uživatelům do fetchmail configu doplnit mda "/usr/bin/procmail -d %T"

Takže teď mi to zase stahuje, ale stejně bych byl rád, kdyby mi mohl někdo vysvětlit, co se vlastně stalo?

[petr_p]

Tady je to naprosto jasně napsaný. Fetchmail si myslí, že doménové jméno localhost má IP adresu 81.95.108.77. Takže něco vám špatně překládá localhost. Ověřit to můžete příkazem:

$ getent ahosts localhost
::1             STREAM localhost
::1             DGRAM  
::1             RAW    
127.0.0.1       STREAM 
127.0.0.1       DGRAM  
127.0.0.1       RAW    

Jestli tam máte něco jiného, tak je třeba zjistit, z které databáze se ta špatná adresa bere. Buďto použijte program strace, nebo si pročtěte nastavení v /etc/nsswitch.conf a podle tam uvedených databází pravděpodobně /etc/hosts, /etc/resolv.conf a nakonec asi i vyzkoušejte dotazy na vaše DNS servery.

Osobně tipuji dvě příčiny: DNS servery vašeho poskytovatele připojení začaly na dotaz na localhost vracet vaši IP adresu, což je moc špatné a zasloužili by vytahat za nějaký orgán.

Nebo vaše distribuce je děsně chytrá a přes nějaký modul do nsswitche překládá localhost mimojiné i na nějakou non-host-scope IP adresu. Něco podobného dělá ns_myhostname ze systemd.

Existuje ještě třetí možnost, že se vám to tak překládalo odjakživa, ale na dané adrese do té doby běžel SMTP server, takže jste nic nepoznal. Pak to ale bylo blbě nakonfigurovaný od začátku.

[Pfemir]

Děkuji za nasměrování, dost mi to pomohlo. Od rána se tím zabývám, ale protože v linuxu jsem pouze osoba poučená (nikoliv znalá), tak z těch výpisů strace, atd. jsem toho až tak moc nevyčetl.

Nicméně jsem zjistil, že v následujících souborech mám:

/etc/hosts

127.0.0.1	localhost
127.0.1.1	ppp

/etc/resolv.conf 

tam mám akorát DNS svého providera

Když zadám:

> getent ahosts localhost

81.95.108.77    STREAM localhost.cz
81.95.108.77    DGRAM  
81.95.108.77    RAW    

> nslookup localhost

Name:	localhost
Address: 127.0.0.1

Pak jsem si všiml, že vy máté ve výpisu "getent ahosts localhost" STREAM localhost, ale já tam mám STREAM localhost.cz.

Tak jsem zkusil:

> nslookup localhost.cz

Non-authoritative answer:
Name:	localhost.cz
Address: 81.95.108.77

Takže buď je problém, že fetchmail nevolá localhot, ale localhost.cz nebo já mám někde něco blbě nastaveno. V každém případě jsem momentálně asi v koncích, takže kdyby se někomu z vás podařilo pošoupnou mě ještě kousek dál, budu vděčný.

[petr_p]

Pokud resolver není schopen přeložit jméno, tak k němu připojí doménu uvedenou v /etc/resolf.conf u položky search nebo domain a zkusí to s takovou hodnotou znovu.

Hádám, že v /etc/nsswitch.conf máte u záznamu hosts uveden nejprve dns, poté hosts a v /etc/resolv.conf máte search cz. Takže se nejprve zkusí DNS, které localhost nezná, tak se zkustí přes DNS localhost.cz, který skutečně existuje a směřuje na 81.95.108.77.

[Pfemir]

Děkuji za trpělivost, bohužel se mi stále nedaří. Máte pravdu, že v /etc/nsswitch.conf mám u hosts uvedeno DNS. Ale zkoušel jsem i files,DB nebo myhostname a je to stále stejné. Co se týká souboru /etc/resolv.conf, tak ten v /etc nenám, resp. nemám ho tam jako soubor, ale jako odkaz na /etc/resolvconf/run/resolv.conf. V /etc/resolvconf mám run zase jako odkaz na /run/resolv.conf. V adresáři /run je už resolv.conf jako soubor a v něm je:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 77.xxx.xxx.xxx

77.xxx.xxx.xxx je IP adresa DNS serveru mého poskytovatele. Žádnou položku search nebo domain tam nemám. Nemůže být nějaký problém v těch odkazech na resolv.conf ?

[petr_p]

Pokud na stroji běží démon nscd, tak ten odpovědi kešuje, takže i když změníte konfiguraci, tak můžete po nějakou dobu dostávat zapamatované odpovědi. Cache zničíte tak, že démona restartujete nebo zneplatníte záznamy určitého druhu (nscd -i hosts).

Pak ještě je možné, že místo nscd máte sssd, což je něco podobného, akorát mnohem složitějšího.

Do /etc/nsswitch.conf bych doporučil dát hosts files,dns, případně pokud opravdu musíte, tak ještě na konec řádku přidat ,myhostname.

nslookup u neplně kvalifikovaných doménových jmen (ty, co nekončí tečkou) automaticky přidává vyhledávácí doménu. Osobně mám raději nástroj dig, který není tak chytrý a ukazuje více informací včetně odesílaného DNS dotazu.

Že /etc/resolv.conf je odkaz, ničemu nevadí. Pokud tam ale nemáte uvedeny vyhledávací domény, tak už jedině mě napadá doména uložená v jádře (domainname(1)).

[pavlix]

sssd neposkytuje cache pro getaddrinfo/gethostbyname, to dělá jen nscd, jehož podpora je zadrátovaná přímo do libc.

Ano, /etc/nsswitch.conf má obsahovat files jako první volbu pro hosts, aby se používal jako první /etc/hosts.

hosts: files dns

Aby nss-files správně překládal localhost, musí /etc/hosts obsahovat alespoň následující a musí mít správně nastavená práva. Na testování doporučuju pouštět getent pomocí strace.

127.0.0.1       localhost
::1             localhost

Při správné konfiguraci je odpověď glibc okamžitá a nepoužijí se žádné jiné pluginy než files.

[Pfemir]

Tak konečně se zadařilo, chtělo to ten restart. Teď už mi fetchmail opět stahuje. Velice děkuji za pomoc.

Bohužel se mi ale objevil jiný problém. Nelze mi posílat emaily z mé domény ven. Odesílání skončí s hláškou unknown mail transport error. V logu pak je postfix/smtp[5201]: fatal: unknown service: smtp/tcp, přitom v /etc/services smtp mám, viz.:

> grep '^smtp' $(sudo postconf -h queue_directory)/etc/services
smtp		25/tcp		mail

Zajímavé je, že z klienta mi to funguje (používám roundcubemail). Pátral jsem na netu a našel jsem radu, že je potřeba do konfiguráku postfixu do relayhost doplnit port :25, že ho postfix nezná. Toto opravdu pomohlo, ale opět nechápu co se přihodilo, do teď postfix port znal a najednou ne? Musím se znovu opakovat, že mi to fungovalo několik let, do ničeho (už z principu) nevrtám a teď řeším jeden problém za druhým (jsem v obavách, co mě čeká zítra).

Napadá vás nějaké rozumné vysvětlení?

[NN]

Neprovadel jsi treba update balicku?

[Pfemir]

Ne, neprováděl. Postfix jedu na verzi 2.10.2, což je verze z 5.11.2013. Aktuální verze je 2.11.3, ale jak už sem psal, pokud něco funguje, tak do toho nevrtám.

Fetchmail mám sice poslední verzi 6.3.26, ale ta byla uvolněna už 23.4.2013.

[pavlix]

Osobně mám raději nástroj dig,

Mimochodem dig je nástroj na DNS a vůbec nebere v potaz /etc/hosts apod.

[petr_p]

nslookup taktéž.

[pavlix]

Tudíž ani jeden z nich není moc vhodný na otestování mappingu, který je typicky řešen v /etc/hosts.

[petr_p]

Tudíž oba jsou vhodné na otestování, jestli ten, do přidává doménu cz., je rekurzivní server.

[pavlix]

S tím nemůžu souhlasit.

[pavlix]

$ strace -e open getent ahosts localhost
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 3
open("/etc/gai.conf", O_RDONLY|O_CLOEXEC) = 3
::1             STREAM localhost
::1             DGRAM  
::1             RAW    
127.0.0.1       STREAM 
127.0.0.1       DGRAM  
127.0.0.1       RAW    

$ grep hosts /etc/nsswitch.conf 
hosts:       files mdns_minimal dns mdns

$ grep localhost /etc/hosts
127.0.0.1       localhost
::1             localhost

Není důvod se nějak více zabývat /etc/resolv.conf, kromě toho, že search cz může dělat problémy v jiných případech než je localhost.

[pavlix]

O něco bohatší strace:

$ strace -e file,network getent ahosts localhost
execve("/usr/bin/getent", ["getent", "ahosts", "localhost"], [/* 63 vars */]) = 0
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
socket(PF_NETLINK, SOCK_RAW, 0)         = 3
bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=5424, groups=00000000}, [12]) = 0
sendto(3, "\24\0\0\0\26\0\1\3y\317KT\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"L\0\0\0\24\0\2\0y\317KT0\25\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 164
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"H\0\0\0\24\0\2\0y\317KT0\25\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 216
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0y\317KT0\25\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 20
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 3
open("/etc/gai.conf", O_RDONLY|O_CLOEXEC) = 3
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(33205), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
getsockname(3, {sa_family=AF_INET6, sin6_port=htons(46098), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
::1             STREAM localhost
::1             DGRAM  
::1             RAW    
127.0.0.1       STREAM 
127.0.0.1       DGRAM  
127.0.0.1       RAW    
+++ exited with 0 +++

[mrtn]

mě se stalo to stejné včera a nakonec jsem zjistil, že neběžel Postfix