STAT command failure

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

STAT command failure

Andrew Charnley
Hi,

Regarding STAT which appears to have an issue with Dovecot:-

[23:50:46] POP< +OK Dovecot ready.
[23:50:46] POP> USER xxxxx
[23:50:46] POP< +OK
[23:50:46] POP> PASS ********
[23:50:46] POP< +OK Logged in.
[23:50:46] POP> STAT
[23:50:46] POP< -ERR Unknown command:

I have enabled the logging as previously instructed for pop3 however
this is only up to the point of login. After this there is no further
information. Login is successful.

Other commands are working fine, I can use Evolution which doesn't use
STAT and access email fine. The issue only came to light due to an
attempt to change to Claws email.

Strangely one of my four accounts on the same server does work. There
is no difference in the settings and I've tried recreating them on both
Claws and the server. The Claws team are 100% sure it's a Dovecot issue.

This is the latest version available with Centos 7 so not the most
up-to-date but I can't see anything in the logs which would suggest a
change for 2.2.

Regards,

Andrew
Reply | Threaded
Open this post in threaded view
|

Re: STAT command failure

Steffen Kaiser-9
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 23 Oct 2017, Andrew Charnley wrote:

> Regarding STAT which appears to have an issue with Dovecot:-
>
> [23:50:46] POP< +OK Dovecot ready.
> [23:50:46] POP> USER xxxxx
> [23:50:46] POP< +OK
> [23:50:46] POP> PASS ********
> [23:50:46] POP< +OK Logged in.
> [23:50:46] POP> STAT
> [23:50:46] POP< -ERR Unknown command:

This response usually has the offending command behind the colon - at
least in Dovecot v2.2

BTW: could you launch a secure connection, e.g. from the mail server

telnet localhost 110

then type in the commands yourself:

user xxxxx
pass ***
stat

- --
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBWe7PYHz1H7kL/d9rAQKI4Af7Bn/6d5UQnINGPMSdkQgNyy5h0cWHvsmQ
U8guJnwtlEcLe0MdJD++vrM6jVeFBjgNqZrqD5Je9dei2GaNz8ti4iwr3WEi2k3I
rkBjznX2Z2bIxpXIFjA3T4I0xSnJ7ohv3qhk1ixebpiNzi9MoA53OYre3r/ghsq8
px6L/vMpuyQ0hiztQKyMpNUBtCE4Y/epG0R5Qy5u1VqQY4giJvSWKWdT0dE4XTkZ
MNUt+d+/RlGTFHc6iiw+mDCUEzOnwIhuTEd25TJhh5Gm/8FS4zu1ayqHoRiRE0gB
uTE2C842BSEuN0yUVucWc35ZWra4yW59Ugf+9OYJbU5LjBwF4Bkrqw==
=H1JT
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: STAT command failure

Andrew Charnley
Hi,

I can confirm this works.

So two issues here;

1. Dovecot logging is useless - there is no logging or stderr output

2. Likely an issue with CLAWS email.

I'm conversing with the CLAWS support group to see what they think.

Regards,

Andrew




On Tue, 24 Oct 2017 07:28:00 +0200 (CEST)
Steffen Kaiser <[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, 23 Oct 2017, Andrew Charnley wrote:
>
> > Regarding STAT which appears to have an issue with Dovecot:-
> >
> > [23:50:46] POP< +OK Dovecot ready.
> > [23:50:46] POP> USER xxxxx
> > [23:50:46] POP< +OK
> > [23:50:46] POP> PASS ********
> > [23:50:46] POP< +OK Logged in.
> > [23:50:46] POP> STAT
> > [23:50:46] POP< -ERR Unknown command:  
>
> This response usually has the offending command behind the colon - at
> least in Dovecot v2.2
>
> BTW: could you launch a secure connection, e.g. from the mail server
>
> telnet localhost 110
>
> then type in the commands yourself:
>
> user xxxxx
> pass ***
> stat
>
> - --
> Steffen Kaiser
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEVAwUBWe7PYHz1H7kL/d9rAQKI4Af7Bn/6d5UQnINGPMSdkQgNyy5h0cWHvsmQ
> U8guJnwtlEcLe0MdJD++vrM6jVeFBjgNqZrqD5Je9dei2GaNz8ti4iwr3WEi2k3I
> rkBjznX2Z2bIxpXIFjA3T4I0xSnJ7ohv3qhk1ixebpiNzi9MoA53OYre3r/ghsq8
> px6L/vMpuyQ0hiztQKyMpNUBtCE4Y/epG0R5Qy5u1VqQY4giJvSWKWdT0dE4XTkZ
> MNUt+d+/RlGTFHc6iiw+mDCUEzOnwIhuTEd25TJhh5Gm/8FS4zu1ayqHoRiRE0gB
> uTE2C842BSEuN0yUVucWc35ZWra4yW59Ugf+9OYJbU5LjBwF4Bkrqw==
> =H1JT
> -----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: STAT command failure

Joseph Tam-2
In reply to this post by Andrew Charnley
Andrew Charnley <[hidden email]> writes:

>>> Regarding STAT which appears to have an issue with Dovecot:-
>>>
>>> [23:50:46] POP< +OK Dovecot ready.
>>> [23:50:46] POP> USER xxxxx
>>> [23:50:46] POP< +OK
>>> [23:50:46] POP> PASS ********
>>> [23:50:46] POP< +OK Logged in.
>>> [23:50:46] POP> STAT
>>> [23:50:46] POP< -ERR Unknown command:
>>
>> user xxxxx
>> pass ***
>> stat
>
> I can confirm this works.

> 2. Likely an issue with CLAWS email.

If you can arrange a network capture of a non-SSL remote CLAWS
connection, try checking whether there's a hidden character (NULL,
.etc.) being sent.

It's also telling that it works for some accounts, and not for others.
Try rebuilding the user's index cache by removing it (save a copy!) and
see if that makes it work.  If it does, you can send the buggy caches
to the developer and see if they can figure it out.

Joseph Tam <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: STAT command failure

Andrew Charnley
On Tue, 24 Oct 2017 14:31:11 -0700 (PDT)
Joseph Tam <[hidden email]> wrote:

> Andrew Charnley <[hidden email]> writes:
>
> >>> Regarding STAT which appears to have an issue with Dovecot:-
> >>>
> >>> [23:50:46] POP< +OK Dovecot ready.
> >>> [23:50:46] POP> USER xxxxx
> >>> [23:50:46] POP< +OK
> >>> [23:50:46] POP> PASS ********
> >>> [23:50:46] POP< +OK Logged in.
> >>> [23:50:46] POP> STAT
> >>> [23:50:46] POP< -ERR Unknown command:  
> >>
> >> user xxxxx
> >> pass ***
> >> stat  
> >
> > I can confirm this works.  
>
> > 2. Likely an issue with CLAWS email.  
>
> If you can arrange a network capture of a non-SSL remote CLAWS
> connection, try checking whether there's a hidden character (NULL,
> .etc.) being sent.
>
> It's also telling that it works for some accounts, and not for others.
> Try rebuilding the user's index cache by removing it (save a copy!)
> and see if that makes it work.  If it does, you can send the buggy
> caches to the developer and see if they can figure it out.
>
> Joseph Tam <[hidden email]>

Hi Joseph,

Which user index file to you refer to?

Regards,

Andrew
Reply | Threaded
Open this post in threaded view
|

Re: STAT command failure

Joseph Tam-2
In reply to this post by Andrew Charnley
Andrew Charnley <[hidden email]> writes:

>> It's also telling that it works for some accounts, and not for others.
>> Try rebuilding the user's index cache by removing it (save a copy!)
>> and see if that makes it work.  If it does, you can send the buggy
>> caches to the developer and see if they can figure it out.
>
> Which user index file to you refer to?

If you're using INDEX= in your mail_location, that one.  I think it
suffices to remove the indices for the user's INBOX, since that's
the only mailbox POP3 is aware of.

I'm not sure where the default index location is if you don't specify
INDEX, so maybe look in your mail spool or personal mail folder for
$WHATEVER/.imap/INBOX.  Caches are regenerated if they go missing
(unless you use mdbox/sdbox formats: *don't* do this if you're using
them.)

Joseph Tam <[hidden email]>