Re: 'fetchmail' daemon stuck

Matthias Andree <[email protected]>
Newsgroups gmane.mail.fetchmail.user
Message-ID <[email protected]>
Am 02.05.19 um 21:25 schrieb [email protected]:
> Hello
>
> Every now and then my 'fetchmail' daemon gets stuck. After some time
> (varies between 1/2 hour and a few days) it stops fetching e-mails. I
> did start it in verbose mode and got the below log. The initial 30 MB
> of the log I threw away as it shows only successful operation, the
> interesting part is here:
>
> fetchmail: 6.3.26 querying imap.yandex.com (protocol IMAP) at xxx xxx
> xx xx:xx:xx xxxx: poll started
> fetchmail: Trying to connect to 87.250.251.124/993...connected.
> fetchmail: Certificate chain, from root to peer, starting at depth 3:
> fetchmail: Issuer Organization: Unizeto Sp. z o.o.
> fetchmail: Issuer CommonName: Certum CA
> fetchmail: Subject CommonName: Certum CA
> fetchmail: Certificate at depth 2:
> fetchmail: Issuer Organization: Unizeto Sp. z o.o.
> fetchmail: Issuer CommonName: Certum CA
> fetchmail: Subject CommonName: Certum Trusted Network CA
> fetchmail: Certificate at depth 1:
> fetchmail: Issuer Organization: Unizeto Technologies S.A.
> fetchmail: Issuer CommonName: Certum Trusted Network CA
> fetchmail: Subject CommonName: Yandex CA
> fetchmail: Server certificate:
> fetchmail: Issuer Organization: Yandex LLC
> fetchmail: Issuer CommonName: Yandex CA
> fetchmail: Subject CommonName: imap.yandex.ru
> fetchmail: Subject Alternative Name: imap.yandex.ru
> fetchmail: Subject Alternative Name: imap.yandex.kz
> fetchmail: Subject Alternative Name: imap.yandex.ua
> fetchmail: Subject Alternative Name: imap.yandex.com.tr
> fetchmail: Subject Alternative Name: imap.yandex.by
> fetchmail: Subject Alternative Name: imap.ya.ru
> fetchmail: Subject Alternative Name: imap.yandex.com
> fetchmail: imap.yandex.com key fingerprint:
> 12:09:8E:B7:44:DE:6F:6B:04:2B:C3:8B:AA:ED:99:53
> fetchmail: IMAP< * OK Yandex IMAP4rev1 at imapxxj.mail.yandex.net:993
> ready to talk with ::xxxx:xxx.xxx.xxx.xxx:xxxxx, xxxx-xxx-xx xx:xx:xx,
> xxxxxxxxxxxx
> fetchmail: IMAP> A0001 CAPABILITY
> fetchmail: IMAP< * BYE Autologout; idle for too long
> fetchmail: Received BYE response from IMAP server:  AUTOLOGOUT; IDLE
> FOR TOO LONGfetchmail: IMAP< * BYE Autologout; idle for too long
> fetchmail: Received BYE response from IMAP server:  AUTOLOGOUT; IDLE
> FOR TOO LONGfetchmail: IMAP< * BYE Autologout; idle for too long
> fetchmail: Received BYE response from IMAP server:  AUTOLOGOUT; IDLE
> FOR TOO LONGfetchmail: IMAP< * BYE Autologout; idle for too long
> ...
>
> The last line repeats forever, blocking any further polling. Only
> restarting 'fetchmail' helps.
>
> What could be the issue? Possible to circumvent it through further
> configuring 'fetchmail'?


First of all, this appears to be a server malfunction, but
unfortunately, you elided the instance information - if you still have
it, check with Yandex's user support (if there is such a thing) and
report the issue.

The server isn't supposed to answer with an untagged * BYE in response
to a CAPABILITY command that happens first in the session, and in
particular, it shouldn't repeat that message, "* BYE Autologout; idle
for too long".

I don't know a good approach to attack this. A brute force workaround is
to edit imap.c, find the line

    report(stderr, GT_("Received BYE response from IMAP server: %s"),
buf + 5);

and add a new line immediately below

    return PS_SOCKET;

then recompile and reinstall. This will make fetchmail disconnect
immediately without any more protocol chatter, unless the * BYE happens
in logout stage.

HTH
Matthias




_______________________________________________
Fetchmail-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fetchmail-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.