On Thu, 29 Nov 2001, Sridhar M.A. wrote: > On Wed, Nov 28, 2001 at 10:08:07AM -0200, Henrique de Moraes Holschuh wrote: > > > > Your server just told fetchmail that there are no messages to be > > downloaded... > > > > Try enabling the fetchall option (see fetchmail manpage). But it is a > broken > > server, I do not know if that will help you. > > > > See RFC 1939 for details. > > > > I don't know for sure.
Well, I do :P > On a hunch downgraded fetchmail. Problem solved. What led me to it was Hmm... > fetchmail: POP3< +OK Cubic Circle's v1.31 1998/05/13 POP3 ready <[EMAIL > PROTECTED]> > fetchmail: POP3> USER z1585531-001 > fetchmail: POP3< +OK z1585531-001 selected > fetchmail: POP3> PASS * > fetchmail: POP3< +OK Congratulations! > fetchmail: POP3> STAT > fetchmail: POP3< +OK 3 9149 Where one can clearly see that this time the server did not lie. Talk about broken behaviour... Tell your ISP to change that thing to something that actually works as per the RFCs, maybe a new version of the pop server, or of whatever they run the server with. Meanwhile, I think you can explicitly tell fetchmail to use USER+PASS, and it will not try to autodetect anything in that case. That might avoid annoying that sensitive pop3 server of your ISP. To do that, use the protocol pop3 (do not let fetchmail try to autodetect it), and tell it to use "auth password". Here is what the fetchmailconf BadCrap database has to say on the issue: ---8<--- # Steve VanDevender <[EMAIL PROTECTED]> writes: # The only system I have seen this happen with is cucipop-1.31 # under SunOS 4.1.4. cucipop-1.31 runs fine on at least Solaris # 2.x and probably quite a few other systems. It appears to be a # bug or bad interaction with the SunOS realloc() -- it turns out # that internally cucipop does allocate a certain data structure in # multiples of 16, using realloc() to bump it up to the next # multiple if it needs more. # # The distinctive symptom is that when there are 16 messages in the # inbox, you can RETR and DELE all 16 messages successfully, but on # QUIT cucipop returns something like "-ERR Error locking your # mailbox" and aborts without updating it. # # The cucipop banner looks like: # # +OK Cubic Circle's v1.31 1998/05/13 POP3 ready <[EMAIL PROTECTED]> # I see your server is running cucipop. Better make sure the server box isn't a SunOS 4.1.4 machine; cucipop tickles a bug in SunOS realloc() under that version, and doesn't cope with the result gracefully. Newer SunOS and Solaris machines run cucipop OK. Also, some versions of cucipop don't assert an exclusive lock on your mailbox when it's being queried. This means that if you have more than one fetchmail query running against the same mailbox, bad things can happen. ---8<--- > So, is this a bug? If the gurus feel so, should I file a bug report? How Don't bother, I am the fetchmail maintainer :) File a bug on your ISP, tell them to run Debian instead of whatever they use there, and a True pop3 server, such as the one in Cyrus ;-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
