TProgressBar property out of range

[Henry]

I'am using PopTray 3.1 (beta 4).
When viewing messages with the Preview option on one account I get the next message:

Unable to Retrieve message.
TProgressBar property out of range

while previeing this message on another account doesn't result in an error message.
What could be wrong?

--
henry

[Henry]

Still the case in Beta 5.

[Renier]

Maybe your server reports a different size than the download gets.
_________________
Renier Crause

[vitoco]

Charsets? May the server is reporting chars and transmiting bytes?

[Henry]

I've had a discussion on the Mailtraq support forum (because that's the server causing the problems) and quoted this below

Henry in <1e4kwmq9jhxyb.dlg@lt10.procura.nl>:
> Op Thu, 29 Apr 2004 11:50:31 +0100 schreef Jim Hill:
> > Henry in <ybpfiw69rzou$.dlg@lt10.procura.nl>:
> >
> >> I'm using poptray to preview messages. Previewing a message in my remote
> >> (providers) mailbox shows the message, but when downloaded to MTQ (Version
> >> 1607) previewing the same message results in an error.
> >
> > What error? What do Mailtraq's logs say?
>
> Unable to Retrieve message.
> TProgressBar property out of range.

That's an internal poptray error message, nothing to do with
Mailtraq, afaict.

> The logfile says:

Presumably, this is a log of poptray connecting to your Mailtraq
mailbox to check/collect mail. If so ...

> [snip ok protocol lines]
> LIST 1 ---> +OK 1 259117 PRCRF47DD0E2

... I'd suggest that the addition of the message's uidl,
PRCRF47DD0E2, to that listing is what's causing poptray to barf.

> > What makes you pick on message size as a possbility?
>
> I have asked this same question in the supportforum for Poptray and the
> response from the developer was: Maybe your server reports a different size
> than the download gets.
>
> The logfile shows that MTQ says the message size is 259117 bytes (LIST),

Yep, that seems a reasonable message size.

> but nothing on UIDL.

You need to understand how the uidl command works in rfc1939. In
this case, the client asked ...

> 00000004 00003612 29-04-2004 13:58:49 UIDL

... which is an instruction to the server to list the uidl of
each message in the maildrop, which listing is terminated by a
dot "." on a line of its own. Mailtraq's logs ...

> 00000004 00003612 29-04-2004 13:58:49 UIDL ---> .

... merely show the terminating dot because the data is generally
of no interest to humans and would clutter the logfile. What's
actually happening is this ...

| C: uidl
| S: +OK 1 messages (806 octets)
| S: 1 RDNSF47FEE2F
| S: .

... where C: is the client and S: is the server.

> Poptray shows a size of 255 Kb on the remote
> pop3-server, and 1 Kb on MTQ.

For me, that confirms it's poptray's problem. The 1Kb value is
probably rounded up from its zero default.

> Hope this info helps.

It does, thanks. I suggest that you contact the poptray developer
and point him at this section in rfc1939 ...

| 5. The TRANSACTION State
| LIST [msg]
| Discussion:
| In order to simplify parsing, all POP3 servers are
| required to use a certain format for scan listings. A
| scan listing consists of the message-number of the
| message, followed by a single space and the exact size of
| the message in octets. Methods for calculating the exact
| size of the message are described in the "Message Format"
| section below. This memo makes no requirement on what
| follows the message size in the scan listing. Minimal
| implementations should just end that line of the response
| with a CRLF pair. More advanced implementations may
| include other information, as parsed from the message.

The discussion goes on to say that adding further detail to the
listing is "strongly discouraged" but some pop3 clients can pick
up uidl from that listing and it saves them another trip to the
server to request a separate uidl listing.

I'm a bit surprised that other poptray users haven't come across
this before now.

[Renier]

This might very well be the problem. I'm not sure what the Indy components will return when there are more data appended in the LIST command. If you say that PopTray show 1kb while the message is in fact bigger, it would seem that the Indy components doesn't handle the "discouraged" situation correctly.

To test this I would have to download the trail version of Mailtraq and see if I can re-create the problem. It might be difficult to fix though if it's a bug in Indy.

[edit]I'd have to recheck the code to see if I so the size filtering myself or whether the Indy components do it[/edit]
_________________
Renier Crause

[Davec]

I have the same problem with accounts on two different servers. I will try from a different computer when I get home.

[Davec]

Both Accounts work fine on my home machine. I'm running the same version of PT on both machines. However, upgarding to the latest beta of Spampal on the machine that was working caused the error.

[Davec]

Going back to Spampal 1.72v fixed both machines. No PT error.