On Fri, Jul 21, 2000 at 02:48:05PM -0300, Christoph Simon wrote: > > As a normal user I type: > fetchmail -v 2>&1 | tee /tmp/fm.log > [snip1]
> fetchmail: POP3< +OK <[EMAIL PROTECTED]> > fetchmail: POP3> USER ciccio > fetchmail: POP3< +OK ciccio gets mail here > fetchmail: POP3> PASS * [snip2] > fetchmail: POP3> LIST > fetchmail: POP3< +OK Iteration follows > fetchmail: POP3< 1 3363 > fetchmail: POP3< . > fetchmail: POP3> TOP 1 99999999 > fetchmail: POP3< +OK 3363 octets > reading message 1 of 1 (3363 octets) > fetchmail: SMTP< 220 baco.haus ESMTP Sendmail 8.9.3/8.9.3/Debian 8.9.3-21; > Fri, 21 Jul 2000 14:30:22 -0300 [snip3] > fetchmail: SMTP> DATA > fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself > > Here it stays eternally. Listing the incoming file in > /var/spool/mqueue already showed 32k for the data file. The actual > message is at the beginning, the rest are spaces (or non-printing > characters shown as spaces by less(1)). Well, I think, it is the POP server that is to be blamed. A POP3 server is supposed to return the message followed by a <CR><LF> and '.' when a TOP n 99999999 or a RETR n is given. It that does not happen, then a situation similar to the one you described can arise. Can you get your e-mail provider to change their broken POP server software? I am surprised that other e-mail users (using the same POP3 server) aren't complaining! > > I can't tell if the lines > fetchmail: POP3> LAST > fetchmail: POP3< -ERR invalid command > fetchmail: invalid command > where happening before, as usually I included the option -a, and now I > did not. Then it wouldn't show. Either way, it does not matter. LAST is an optional command and fetchmail can function with LAST. -- Manoj Victor Mathew (GPG#: 3D96A9B9) Cochin, India.
