We download all mails in our intranet mail server using fetchmail. We have about 40 accounts with our mail service provider. From last few months some times some of the user mails are not getting downloaded. If a particular mail does not get downloaded then the newer mails also get stuck in the server as fetchmail skips remaining mails. Currently we delete that mail as a workaround from webmail interface.

Please see below log for user whose mails are stuck on the server.

fetchmail: POP3> USER support@xyz-infotech.com
fetchmail: POP3< +OK
fetchmail: POP3> PASS *
fetchmail: POP3< +OK server ready
fetchmail: POP3> STAT
fetchmail: POP3< +OK 2 20075
fetchmail: POP3> LAST
fetchmail: POP3< -ERR unknown command
fetchmail: unknown command
fetchmail: POP3> UIDL
fetchmail: POP3< +OK 2 messages
fetchmail: POP3< 1 5024.mYehr3XKLFMMaZ5z7wivFfzsvyPND2n9URskpWNMMpQ=
fetchmail: POP3< 2 5026.uW5UyaafrY7A8Gp5gMxcI0KPTU0E8WpbnZRuRVF7EI4=
fetchmail: POP3< .
fetchmail: 2 messages (2 seen) for support@xyz-infotech.com at zpop.logix.in (20075 octets).
fetchmail: skipping message support@xyz-infotech.com@zpop.logix.in:1 not flushed
fetchmail: skipping message support@xyz-infotech.com@zpop.logix.in:2 not flushed
fetchmail: POP3> QUIT

Why fetchmail is giving error for LAST command? What is a cause or solution of this problem?

My server is CENTOS 4.3 and fetchmail version is 6.2.5 We run fetchmail as daemon and we run fetchmail command as

server zpop.logix.in protocol pop3 user "support@xyz-infotech.com" with password "Passw@rd" is "support" here

The error on the LAST command isn't generated by fetchmail, it is generated by the POP3 server fetchmail is talking to.

The LAST command was present in the earlier version of the protocol RFC 1081 but in the most current version RFC 1939 LAST is not a valid POP3 command anymore so that error is expected. Some more on that can be found here.

On my system I see fetchmail trying to use the LAST command as well, also getting an error. I imagine that the fetchmail developers consider it too good a solution if the remote server still supports it to abandon it and remove the code.

After failing on the LAST command fetchmail simply continues with the more useful UIDL command that fetches the Unique-ID Listing, the list of all messages in the remote mailbox.

That lists two messages. Those messages have already been "seen" (read: downloaded successfully for local delivery and are listed in ~/.fetchids) and are therefore not downloaded again. That is typically the result of a -k | --keep option on your command line or in your .fetchmailrc.

Solution: removing the ID's from the .fetchids history will see the messages downloaded again.

  • Thanks for the answer, but I did not get the solution. As you said, I removed IDs' from ~./fetchids but they again restored by the Fetchmail. Secondly, there is no -k | --keep option explicitly declared in .fetchmailrc. Am I required to upgrade fetchmail to get rid of this issue?
    – Silkograph
    Jun 28 '14 at 6:52
  • 1
    I don't know off-hand what bug fixes have released for fetchmail, but since you're running CentOS 4.3 you hacen't been patching since 2006
    – HBruijn
    Jun 28 '14 at 8:01
  • Yes, never patched, but now I have planned to install latest version on a priority basis.
    – Silkograph
    Jun 28 '14 at 8:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.