I have ActivityMonitor replicants showing CPU usage and network traffic on the desktop. Recently I noticed that the send&receive numbers kept showing continuous slow traffic, like 5 KiB/s.
At the same time, no mail arrived when it should…
So I stopped the mail_daemon (launch_roster stop x-vnd.Be-POST) and started it from Terminal. The output was a never ending stream of:
C: A0000020 UID STORE 30747 FLAGS (\Deleted)
S: A0000020 OK Store completed (0.001 + 0.000 secs).
C: A0000021 UID STORE 30766 FLAGS (\Deleted)
S: A0000021 OK Store completed (0.001 + 0.000 secs).
C: A0000022 UID STORE 30767 FLAGS (\Deleted)
S: A0000022 OK Store completed (0.001 + 0.000 secs).
C: A0000023 UID STORE 30768 FLAGS (\Deleted)
.
.
.
Does anyone know what the issue might be?
I assume “S” is the server, acknowledging commands from “C” (the client == mail_daemon) to set “deleted” flags on emails. But why now when I haven’t noticed it any time before? And why on seemingly all my mails (I’ve let it run for an hour before)?
I’ve quit and restarted mail_daemon twice, before it stopped the above behaviour and actually fetched my mail, as a good daemon should.
I’ve only just started monitoring the mail_daemon output. Haven’t seen the described delete-flagging yet. Of course…
Anyway, it took me a minute to figure out how not to auto-start the mail_daemon. It’s a setting in the file ~/config/settings/Mail/new_mail_daemon. I used Kottan to open that flattened BMessage. DaemonAutoStarts has to be set to “false”.
Yeah, but I didn’t want to have the daemon start on boot-up in the first place. I guess I could also put that line after a “waitfor” in the UserBootscript. No matter. Now let’s hope I don’t forget that setting when I want to revert it…
There’s also a setting in mail preferences to whether it should remove mail from the server when deleted locally. But that still doesn’t explain why it thought there were suddenly a bunch of them to update.
It might be useful to find out what flags have already been set on those messages. I mean, if you abort one of those deleting sessions, and the last one is 30349, then get the flags for 30350. If your email is like mine, you’ll need a text line SSL client, connected to port 993. I set mine up to take lines from the command line, prepend an incremented serial number and append \r\n. So, like
$ cmd mail.myhost.net 'login me@hostor.not p.ssw.rd' 'select inbox' 'fetch 28642
(flags body.peek[header.fields (subject)])' 'logout'
> * OK [CAPABILITY IMAP4rev1 LOGIN-REFERRALS ID ENABLE IDLE SASL-IR LITERAL+ AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
< login ...
X1 OK [CAPABILITY IMAP4rev1 ... blah blah ...] Logged in
< select inbox
> * FLAGS (\Answered \Flagged \Deleted \Seen \Draft NonJunk $Forwarded)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft NonJunk $Forwarded \*)] Flags permitted.
* 1686 EXISTS
* 0 RECENT
* OK [UNSEEN 734] First unseen.
* OK [UIDVALIDITY 1664953607] UIDs valid
* OK [UIDNEXT 29375] Predicted next UID
* OK [HIGHESTMODSEQ 59046] Highest
X2 OK [READ-WRITE] Select completed (0.001 + 0.000 secs).
< uid fetch 28642 (flags body.peek[header.fields (subject)])"
* 1650 FETCH (UID 28642 FLAGS (\Answered \Seen) BODY[HEADER.FIELDS (SUBJECT)] {68}
Subject: Introduction to nonsensical subject lines from nowhere.
)
X3 OK Fetch completed (0.001 + 0.000 secs).
< logout
> * BYE Logging out
X4 OK Logout completed (0.001 + 0.000 secs).
Since these responses will fit in one reasonably dimensioned read, you can treat this as simple back and forth I/Os. More generally, the response will end with line tagged with your serial number, instead of ‘*’.
About UIDs - ideally, an email’s UID is a permanent attribute, but it’s possible for a folder to be rebuilt with new UIDs, under various exceptional circumstances. The server announces a UIDVALIDITY value, and if that is no longer the same as the one you saved from previous sessions, then it’s time to rebuild your whole local picture with the new UIDs. If this happened and mailserver has been using UIDs but not paying attention to UIDVALIDITY, things could get very weird.
IIRC, from the time I spent a few months ago looking at IMAP add-on for mail_daemon, it will sync the \Deleted flag only if you’ve enable it in your settings. Maybe you did without notice, or something get wrong in the settings file or in the laoding code of this settings file, or we’ve a corner case here.
Please open a ticket with a full mail_daemon log output from it’s start (but edit the private info part like your email address and, more importantly, the password which is visible in clear there), maybe it’s due to some weird sequence.
Sure! Also OK to do it concurrently with IMAP access from other clients.
Concurrent client access creates an interesting problem for deletion. In the simplest case, clients set this \Delete flag, and then at the end of a session, there’s an EXPUNGE command that causes them all to be actually deleted. Except if there’s another client on the line at the time. In this case, the messages change to another flag, something about “pending” if I remember right, and the server stops reporting them, but they’re still there. That’s how the UW server worked, but I assume this is implementation dependent. The problem isn’t though, so it’s just a question of what your server does in this case.
Something like your imap daemon is a corner case here. It might be worth a look at the source to see if and when it actually issues an EXPUNGE command. Any normal client connection probably will, at the end of a client session. Some clients seem to feel a need to physically delete the message, which I suppose they do with the UID EXPUNGEcommand.
I assume you mean a log of when the issue occurs, not a normally working session. Guess we’ll have to wait some more for that. Everything is running annoyingly smooth right now…
I meant what command to use to contact the mail server. There’s ssltap coming with the nns package, apparently, but I haven’t figured out its usage yet. Or is there something else to install?
If your IMAP provider enforce the STARTTLS mode (aka starting in plain TCP and switch to TLS on same established TCP to TLS after login) you can add the -starttls imap option.
Otherwise, socat openssl:xxxx stdio (or readline, even better) and ncat --ssl xxxx are other alternatives, but I dunno if are they available on Haiku (yet?).
