today's snapshot, still cannot pop email
hansa
Tim Altman
Please file a bug report and include a log file.
--
Tim Altman
Desktop QA
Opera Software
Remove NO SPAM from e-mail address to reply
hansa
wrote:
> On Tue, 06 May 2008 19:23:26 +0200, hansa
> <hansa_at_...@nospam.com> wrote:
>
>> Mac OS X 10.5.2 O9.5 build 4808.
>> pop account on zonnet.nl
>
> Please file a bug report and include a log file.
>
Well, just for the fun of it, here is the log file as well.
It is very brief, popping the account is stalled, while showing
"contacting server" in the status bar.
<start log>
==== Logging started ====
22:53:36 POP IN: +OK POP3 Ready 10.170.1.153 0001fdaf
22:53:36 POP OUT: CAPA
22:53:36 POP IN: +OK Capability list follows, mate
22:53:36 POP IN: TOP USER PIPELINING UIDL POP3S
.
22:53:36 Parse error: syntax error
22:53:36 Parse error: syntax error
</end log>
hansa
wrote:
> On Tue, 06 May 2008 19:23:26 +0200, hansa
> <hansa_at_...@nospam.com> wrote:
>
>> Mac OS X 10.5.2 O9.5 build 4808.
>> pop account on zonnet.nl
>
> Please file a bug report and include a log file.
>
Done, bug 328619
I also sent the log files both from 9.27 (which succeeds to pop) and from
9.5 build 4808.
Tim Altman
<hansa_at_...@nospam.com> wrote:
>On Wed, 07 May 2008 12:16:27 +0200, Tim Altman <do....@spam.me.invalid>
>wrote:
>
>> On Tue, 06 May 2008 19:23:26 +0200, hansa
>> <hansa_at_...@nospam.com> wrote:
>>
>>> Mac OS X 10.5.2 O9.5 build 4808.
>>> pop account on zonnet.nl
>>
>> Please file a bug report and include a log file.
>
>Done, bug 328619
Thank you. Your server is violating RFC 2449 (section 5), which
describes the CAPA response:
An +OK response is followed by a list of capabilities, one
per line. Each capability name MAY be followed by a single
space and a space-separated list of parameters. Each
capability line is limited to 512 octets (including the
CRLF). The capability list is terminated by a line
containing a termination octet (".") and a CRLF pair.
Your server outputs:
22:53:36 POP OUT: CAPA
22:53:36 POP IN: +OK Capability list follows, mate
22:53:36 POP IN: TOP USER PIPELINING UIDL POP3S
.
Each of the capabilities should be on a separate line. Your server's
implementation makes it impossible for capabilities to have
parameters. Please contact your mail server provider to notify them
about this problem.
hansa
wrote:
OK, thank you. I will inform them about that.
But... Opera 9.27 simply handles the reply, and successfully pops the
mail. Why doesn't 9.5 do that too.
I agree that the pop server should stick to the rules, but if Opera
handled this before, then why stop doing that?
Below a part of the log of v9.27, same spec violation (of course) by the
pop server, but Opera doesn't seem to care.
14:14:38 POP3 OUT :
CAPA
14:14:38 POP3 IN :
+OK Capability list follows, mate
TOP USER PIPELINING UIDL POP3S
.
14:14:38
HandleReply
Tim Altman
<hansa_at_...@nospam.com> wrote:
>On Thu, 08 May 2008 13:26:06 +0200, Tim Altman <do....@spam.me.invalid>
>wrote:
>
>> On Wed, 07 May 2008 23:08:09 +0200, hansa
>> <hansa_at_...@nospam.com> wrote:
>>
>>> On Wed, 07 May 2008 12:16:27 +0200, Tim Altman <do....@spam.me.invalid>
>>> wrote:
>>>
>>>> On Tue, 06 May 2008 19:23:26 +0200, hansa
>>>> <hansa_at_...@nospam.com> wrote:
>>>>
>>>>> Mac OS X 10.5.2 O9.5 build 4808.
>>>>> pop account on zonnet.nl
>>>>
>>>> Please file a bug report and include a log file.
>>>
>>> Done, bug 328619
>>
>> Thank you. Your server is violating RFC 2449 (section 5)
[...]
>> Each of the capabilities should be on a separate line. Your server's
>> implementation makes it impossible for capabilities to have
>> parameters. Please contact your mail server provider to notify them
>> about this problem.
>
>OK, thank you. I will inform them about that.
>But... Opera 9.27 simply handles the reply, and successfully pops the
>mail. Why doesn't 9.5 do that too.
Because we rewrote the POP back-end based on the RFC.
>I agree that the pop server should stick to the rules, but if Opera
>handled this before, then why stop doing that?
We've implemented a work-around for your server.
hansa
wrote:
[...]
>
>> I agree that the pop server should stick to the rules, but if Opera
>> handled this before, then why stop doing that?
>
> We've implemented a work-around for your server.
>
Ah that's great. Thanks to you all :)
I have not gotten any reply from the provider yet, other than that my
email was forwarded to the proper department. Right!