Re: Fetchmail trouble
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 <806600007691053c@popauth2.net4india.com>
> 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 <stevev@efn.org> 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 <6229000062f95036@wakko>
#
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
Reply to: