Re: STAT command failure
Andrew Charnleywrites: 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
Re: STAT command failure
On Tue, 24 Oct 2017 14:31:11 -0700 (PDT) Joseph Tamwrote: > Andrew Charnley writes: > > >>> Regarding STAT which appears to have an issue with Dovecot:- > >>> > >>> [23:50:46] POP< +OK Dovecot ready. > >>> [23:50:46] POP> USER x > >>> [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 x > >> 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 Hi Joseph, Which user index file to you refer to? Regards, Andrew
Re: STAT command failure
Andrew Charnleywrites: Regarding STAT which appears to have an issue with Dovecot:- [23:50:46] POP< +OK Dovecot ready. [23:50:46] POP> USER x [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 x 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
Re: STAT command failure
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 Kaiserwrote: > -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 x > > [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 x > 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-
Re: STAT command failure
-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 x [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 x 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-
STAT command failure
Hi, Regarding STAT which appears to have an issue with Dovecot:- [23:50:46] POP< +OK Dovecot ready. [23:50:46] POP> USER x [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