On 8/18/23 10:39, Phil Dibowitz wrote:
On 8/18/23 06:00, cyrus@xxxxxxxxxxx wrote:
It should be the log subdirectory of configdirectory, so in the above
case: /var/lib/cyrus/log/phil should work yes.
Make sure it's owned by cyrus:cyrus, or whichever user and group the
imapd process runs as, and writeable by the owner. You do need to
restart the client, to make sure it starts a new session. A refresh
won't necessarily do the job. After that, it should just start loggin
- at least it did for me.
Here's the doc page:
https://www.cyrusimap.org/dev/imap/reference/faqs/o-telemetry.html
Doh! Perms, of course.
Yes, that works. This is EXCELLENT! Thank you!
It's currently not repro'ing, but as soon as it comes back, this should
make it all much clearer.
Thanks!
- Phil
I'm finally coming back to this.
When it happens, I don't even get an imaps-<pid> file in the logdir (I
do for successful ones though).
Based on the tcpdump, the most common issue is my cyrus server failing
during the handshake and sending a tls decode error like this:
EXAMPLE 1: server sends FIN - TLS alert mesage!
* 3wayhandshake
* server client hello
* server ack
* server server hellow
* server psh/ack
* server ack/psh/fin - cert/server key exchange, cert req, server hello done
* client rst
* client rst
* client rst
* client fun/ack
* server ack
In this one, that last server packet has a TLS Alert layer that says
"Description: Decode Error (50)"
The journal shows related errors:
Dec 09 04:43:04 virt.ipom.com cyrus/imaps[3567050]: Set client CA list:
Client cert requested, not required
Dec 09 04:43:04 virt.ipom.com cyrus/imaps[3567050]: TLS Server Name
Indication (SNI) Extension: "mail.ipom.com"
Dec 09 04:43:04 virt.ipom.com cyrus/imaps[3567050]: unexpected eof while
reading in SSL_accept() -> fail
Dec 09 04:43:04 virt.ipom.com cyrus/imaps[3567050]: imaps TLS
negotiation failed: [172.58.88.178]
Dec 09 04:43:04 virt.ipom.com cyrus/imaps[3567050]: extractor_destroy((nil))
This seems to happen most often in the Gmail app on GSM, however it does
happen on wifi sometimes, and it does happen with other mail clients
(though much, much less often). I never see this on non-mobile platforms.
I also sometimes see this:
EXAMPLE 2: client sends random FIN
* 3wayhanshake
* client client hello
* server ack
* client tcp retrans of original ack from 3whs
* server dupe ack of client hello pkt
* client FIN/ACK # wut?
* server ack
Normally I'd suspect a bad cell provider, or a bad wifi connection, or
whatever, but I've now had this across two physical phones (pixel 6,
pixel 8 pro), two email clients (gmail, bluemail), three wifi (work,
home, gf), and GSM.
If anyone has other debugging options I might take, I'd be appreciative.
Thanks!
--
Phil Dibowitz phil@xxxxxxxx
Open Source software and tech docs Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"Be who you are and say what you feel, because those who mind don't
matter and those who matter don't mind."
- Dr. Seuss
------------------------------------------
Cyrus: Info
Permalink: https://cyrus.topicbox.com/groups/info/T2fd4469ccc514f5a-M44f31e518ff710f1e089601c
Delivery options: https://cyrus.topicbox.com/groups/info/subscription
