Re: fetchmail troubles
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
> fetchmail: POP3< +OK <0332.397889D5@mail.prestonet.com.br>
> fetchmail: POP3> USER ciccio
> fetchmail: POP3< +OK ciccio gets mail here
> fetchmail: POP3> PASS *
> 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
> 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)