Menu
▾
▴
fetchmail-users
|
From: Frederik <fr...@gm...> - 2005-12-23 19:56:47
|
Since tonight, I'm suffering from "message [...] was not the expected length" errors. I see it on one mailbox on my ISP (the other mailbox is unaffected though), and it makes fetchmail completely fail to retrieve mails from the mailbox concerned. I tried my ISP's webmail, and could access my mailbox without any problems. I deleted the whole contents of the mailbox, in the hope that it was one particual mail causing the problem. Unfortunately, on the first mail which arrived, the problem was there again. I have this problem with both fetchmail from sarge (6.2.5-12sarge3), and with self compiled fetchmail 6.3.1. Here's part of the output of an /etc/init.d/fetchmail debug-run: fetchmail: 6.2.5 querying pop.pandora.be (protocol POP3) at Fri 23 Dec 2005 07:24:18 PM CET: poll started fetchmail: POP3< +OK pop s`maHegdelS fetchmail: POP3> CAPA fetchmail: POP3< -ERR not implemented fetchmail: not implemented fetchmail: Repoll immediately on use...@po... fetchmail: POP3< +OK pop s`maHegdelS fetchmail: POP3> USER username fetchmail: POP3< +OK 1332 fetchmail: POP3> PASS * fetchmail: POP3< +OK .. welcome fetchmail: selecting or re-polling default folder fetchmail: POP3> STAT fetchmail: POP3< +OK 1 4693 fetchmail: POP3> LAST fetchmail: POP3< +OK 0 1 message for username at pop.pandora.be (4693 octets). fetchmail: POP3> LIST 1 fetchmail: POP3< +OK 1 4693 fetchmail: POP3> TOP 1 99999999 fetchmail: POP3< +OK 4693 octets reading message use...@po...:1 of 1 (4693 octets) About to rewrite Return-Path: <coo...@ma...> Rewritten version is Return-Path: <coo...@ma...> About to rewrite To: co...@ma... Rewritten version is To: co...@ma... About to rewrite From: "dvg...@xs..." <bug...@qa...> Rewritten version is From: "dvg...@xs..." <bug...@qa...> About to rewrite Sender: ap...@qa... Rewritten version is Sender: ap...@qa... About to rewrite Reply-To: co...@ma... Rewritten version is Reply-To: co...@ma... fetchmail: SMTP< 220 localhost.localdomain ESMTP Exim 4.50 Fri, 23 Dec 2005 19:24:22 +0100 fetchmail: SMTP> EHLO localhost fetchmail: SMTP< 250-localhost.localdomain Hello localhost [127.0.0.1] fetchmail: SMTP< 250-SIZE 52428800 fetchmail: SMTP< 250-PIPELINING fetchmail: SMTP< 250 HELP fetchmail: forwarding to localhost fetchmail: SMTP> MAIL FROM:<coo...@ma...> SIZE=4693 fetchmail: SMTP< 250 OK fetchmail: SMTP> RCPT TO:<frederik@localhost> fetchmail: SMTP< 250 Accepted fetchmail: SMTP> DATA fetchmail: SMTP< 354 Enter message, ending with "." on a line by itself #**********************************.****************fetchmail: message use...@po...:1 was not the expected length (4803 actual != 4693 expected) fetchmail: SMTP>. (EOM) fetchmail: terminated with signal 2 The mail in question is this mail: http://article.gmane.org/gmane.linux.mandrake.cooker.devel/177796 Any help to further debug this problem, would be appreciated, as now I cannot access my e-mail anymore. -- Frederik |
|
From: Rob M. <rob...@gm...> - 2005-12-23 21:45:18
|
On 23/12/05, Frederik <fr...@gm...> wrote:
> Since tonight, I'm suffering from "message [...] was not the expected
> length" errors. I see it on one mailbox on my ISP (the other mailbox is
> unaffected though), and it makes fetchmail completely fail to retrieve
> mails from the mailbox concerned.
I've often seen this before and it's never caused a problem in the
past. However my days of using that horribly buggy POP server are
long over :-)
> fetchmail: POP3< +OK 1 4693
> 1 message for username at pop.pandora.be (4693 octets).
> fetchmail: POP3< +OK 1 4693
> fetchmail: POP3< +OK 4693 octets
> reading message use...@po...:1 of 1 (4693 octets)
Right, so the POP server has stated that the message is 4693 bytes long, total.
> fetchmail: SMTP> MAIL FROM:<coo...@ma...> SIZE=4693
And fetchmail passes this on.
> #**********************************.****************fetchmail: message
> use...@po...:1 was not the expected length (4803 actual != 4693
> expected) fetchmail: SMTP>. (EOM)
> fetchmail: terminated with signal 2
And it turns out to be a bit longer. It would be useful to see what
the message from your SMTP server is - I suspect the problem may be on
that end.
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: Jason W. <jas...@in...> - 2005-12-24 01:34:43
|
On Fri, Dec 23, 2005 at 08:45:18PM +0000, Rob MacGregor wrote: > > #**********************************.****************fetchmail: message > > use...@po...:1 was not the expected length (4803 actual != 4693 > > expected) fetchmail: SMTP>. (EOM) > > fetchmail: terminated with signal 2 > > And it turns out to be a bit longer. It would be useful to see what > the message from your SMTP server is - I suspect the problem may be on > that end. If, as I also suspect, that is where the problem is, try setting the mda option in your fetchmailrc file to, e.g., procmail. This will bypass your local MTA. You might also be able to configure your MTA somehow to ignore the declared message size. |
|
From: Matthias A. <mat...@gm...> - 2005-12-24 03:11:28
|
Rob MacGregor <rob...@gm...> writes: >> #**********************************.****************fetchmail: message >> use...@po...:1 was not the expected length (4803 actual != 4693 >> expected) fetchmail: SMTP>. (EOM) >> fetchmail: terminated with signal 2 > > And it turns out to be a bit longer. It would be useful to see what > the message from your SMTP server is - I suspect the problem may be on > that end. Would the SMTP server send a SIGINT to its client? I doubt that. How would it find out the PID of its client? -- Matthias Andree |
|
From: Matthias A. <mat...@gm...> - 2005-12-24 03:10:46
|
Frederik <fr...@gm...> writes: > fetchmail: SMTP< 354 Enter message, ending with "." on a line by itself > #**********************************.****************fetchmail: message > use...@po...:1 was not the expected length (4803 actual != 4693 > expected) fetchmail: SMTP>. (EOM) > fetchmail: terminated with signal 2 These "not the expected length" messages are hints that the upstream server is broken and is misreporting the actual message size. Many POP3 server software packages are broken like this, for instance some Exchange versions, qmail-pop3d and the one your server uses, fetchmail just reports them and continues. This "not the expected length" message does not cause fetchmail to fail. fetchmail aborts because someone or something is sending signal 2 (SIGINT, ^C), and it's not fetchmail, which has no code to raise SIGINT. Stop that something from sending fetchmail signals like SIGINT. Check your scripts that run fetchmail, the shells that you run this script from, and perhaps check if fetchmail is somehow part of a process group with rampant programs. plugin, plugout are also possible candidates. Details about your setup, such as fetchmail configuration and how you start fetchmail, may help in tracking down the problem. -- Matthias Andree |
|
From: Sunil S. <sh...@bo...> - 2005-12-24 06:29:14
|
Quoting from Frederik's mail on Fri, Dec 23, 2005: > Since tonight, I'm suffering from "message [...] was not the expected > length" errors. I see it on one mailbox on my ISP (the other mailbox is > unaffected though), and it makes fetchmail completely fail to retrieve > mails from the mailbox concerned. > > I tried my ISP's webmail, and could access my mailbox without any > problems. I deleted the whole contents of the mailbox, in the hope that it > was one particual mail causing the problem. Unfortunately, on the first > mail which arrived, the problem was there again. > > I have this problem with both fetchmail from sarge (6.2.5-12sarge3), and > with self compiled fetchmail 6.3.1. > > Here's part of the output of an /etc/init.d/fetchmail debug-run: > > fetchmail: 6.2.5 querying pop.pandora.be (protocol POP3) at Fri 23 Dec > 2005 07:24:18 PM CET: poll started ... > fetchmail: forwarding to localhost > fetchmail: SMTP> MAIL FROM:<coo...@ma...> SIZE=4693 > fetchmail: SMTP< 250 OK > fetchmail: SMTP> RCPT TO:<frederik@localhost> > fetchmail: SMTP< 250 Accepted > fetchmail: SMTP> DATA > fetchmail: SMTP< 354 Enter message, ending with "." on a line by itself > #**********************************.****************fetchmail: message > use...@po...:1 was not the expected length (4803 actual != 4693 > expected) fetchmail: SMTP>. (EOM) > fetchmail: terminated with signal 2 Please try adding the "forcecr" option to your fetchmailrc. In case it doesn't work, please send the output of "fetchmail -V" and the details of your smtp server. Is the "message ... was not the expected length" error coming on every mail or on specific mails only? -- Sunil Shetye. |
|
From: Frederik <fr...@gm...> - 2006-01-19 20:09:52
|
On 12/24/05, Sunil Shetye <sh...@bo...> wrote: > Quoting from Frederik's mail on Fri, Dec 23, 2005: > > Since tonight, I'm suffering from "message [...] was not the expected > > length" errors. I see it on one mailbox on my ISP (the other mailbox is > > unaffected though), and it makes fetchmail completely fail to retrieve > > mails from the mailbox concerned. > Please try adding the "forcecr" option to your fetchmailrc. > > In case it doesn't work, please send the output of "fetchmail -V" and > the details of your smtp server. > > Is the "message ... was not the expected length" error coming on every > mail or on specific mails only? The problem disappeared as suddenly after it appeared. Well, till today at least, because now exactly the same problem started again. It seems to happen on all messages, deleting the message which causes the problem, just makes it halt on the next message. I cannot understand why it works fine so lang, and then it starts to go mad like this. Another e-mail account I have from the same ISP, works still fine. Also something which is not yet clear to me: is it a problem that my ISP's POP3 server is giving wrong info about the size of the mail to fetchmail, or is it my own local MTA that complains that the e-mail it receives is not the size fetchmail said it is? In the first case, it would not matter much which MTA I am using locally? Adding forcerc did not help. My own setup: exim 4.50 from Debian Sarge (using sa-exim and clamav, but that should not matter much). Problem happens with both Sarge's fetchmail 6.2.5-12sarge3 and recompiled 6.3.1-4 from unstable. # fetchmail -V fetchmail: WARNING: Running as root is discouraged. This is fetchmail release 6.3.1+NTLM+SDPS+SSL+NLS Fallback MDA: (none) Linux Luna 2.6.14-cks4 #1 Wed Nov 9 16:10:51 CET 2005 i686 GNU/Linux Taking options from command line No mailservers set up -- perhaps /root/.fetchmailrc is missing? Is not there simply a way to make it *ignore* this problem? Actually fetchmail is completely unusable to me now, as I cannot access my e-mail anymore :-( -- Surf veilig en snel met de Mozilla Firefox web browser http://spreadfirefox.com/community/?q=affiliates&id=617&t=1 |
|
From: Frederik <fr...@gm...> - 2006-01-19 22:22:34
|
On 1/19/06, Frederik <fr...@gm...> wrote: > On 12/24/05, Sunil Shetye <sh...@bo...> wrote: > > Quoting from Frederik's mail on Fri, Dec 23, 2005: > > > Since tonight, I'm suffering from "message [...] was not the expected > > > length" errors. I see it on one mailbox on my ISP (the other mailbox is > > > unaffected though), and it makes fetchmail completely fail to retrieve > > > mails from the mailbox concerned. > > > Please try adding the "forcecr" option to your fetchmailrc. > > > > In case it doesn't work, please send the output of "fetchmail -V" and > > the details of your smtp server. > > > > Is the "message ... was not the expected length" error coming on every > > mail or on specific mails only? > > The problem disappeared as suddenly after it appeared. Well, till > today at least, because now exactly the same problem started again. And a bit after I wrote this, all started to work again. That means: while doing a fetchmail -v -v, it still had the error messages about inccorret size, but it continued to download everything. After that, I restarted fetchmail, and mails are now being downloaded without errors. Weird... -- Surf veilig en snel met de Mozilla Firefox web browser http://spreadfirefox.com/community/?q=affiliates&id=617&t=1 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X