Nope. Haven’t seen it since starting the mail_daemon manually. If it won’t replicate like this, but reappears when auto-launched, that may play into it.
Using openssl s_client works fine. However, I haven’t managed to access an email yet. I tried with donn’s line above:
mail_daemon already has a logging window that appears for specific critical errors. It would be neat to be able to flip a switch so this comes up during normal operations and just puts the log there.
The “cmd” business is my own program. When I posted that comment I didn’t know about the openssl client. It isn’t just thatimap.mailbox.org isn’t needed, cmd itself isn’t what the IMAP server wants to hear about.
openssl will do the job, you just connect and then type in the IMAP commands, with serial number prefix. Or if this gets to be a regular thing, you could use a shell script to function like that cmd program.
#!/bin/sh
#
# IMAP access via openssl
#
case $# in
0) echo Usage: cmd host imapcommand1 [imapcommand2 ...] >&2
exit 1
;;
esac
host=$1
shift
i=0
# send IMAP commands from command line to server, with increasing serial no.
for a
do
sleep 1
echo >&2
echo -n 'continue: ' >&2
read spud
case $spud in
no) break;;
esac
((i = i + 1))
echo S$i $a >&2
echo S$i $a
done | openssl s_client -connect $host:993
After running the mail_daemon a week long from Terminal, so I can keep an eye on its output, I’ve never seen the described oddity. After that I went back to the usual auto-starting of the daemon for a week and didn’t see the tell-tale slow trickling of send/receive traffic that I did before either.
So, I suppose we can close this chapter and blame the usual, cosmic rays or ghosts etc.