buzz
buzz copied to clipboard
jonhoo
Outright not working :[
Starts and runs but even though I do get new email, it doesn't notify me about it.
How should I go about troubleshooting this?
No errors whatsoever.
Hmm, that's odd indeed. Buzz should notify you about emails that are in the IMAP NEW status, which means (from the spec):
Messages that have the
\Recentflag set but not the\Seenflag.
If you look at the emails in another IMAP client, can you check the flags on the messages in your inbox and see if that matches? What output do you get in the logs?
Even with a freshly recieved email Dovecot doesn't set the \Recent flag, only the \Seenone, at least that's what I can tell from the output of a doveadm fetch command. I'll look into that first.
I don't get any errors in stdout when its running, only some (I'm guessing) GTK errors about I don't even know what.
That's really weird, and sounds like a Dovecot bug if it's indeed the case :thinking:
It does seem like a Dovecot bug, but the flag actually exists, and isn't stored like all the other regular flags? I'm really not sure about what's going on. I'm now trying with only my Gmail account in the buzz.toml config file to see if it actually works, but I'm pretty sure that it doesn't either.
Nonetheless, thank you very much for responding to an issue on a project that is not that actively developed. :]
I have the means to modify and rebuild the code, how would I go about debugging this? I am really not sure about how to check email flags on Gmail because I've spent so much time in Dovecot and roundcube that I don't use Gmail that much :P
@maltalef101 Sorry for the late reply! Best way to go is to set the debug flag in imap to true, which will show you all the client-server interactions. Then you could use something like wireshark to inspect what happens when a "regular" email client connects to your Dovecot server, and compare the two. Hopefully it should be visible what the difference in the queries is!
I recently started investigating about this again and found out something interesting. The \Recent flag does not exist anymore, it's been deprecated since the release of RFC9051 in August of last year.
Take a look at Appendix E, item 12: (link)
RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS, and SEARCH NEW items are now deprecated.
This, obviously, was a surprise. I manually connected to my Dovecot instance and ran SEARCH NEW just seconds after receiving a message and the search came out empty. I have no idea how this type of functionality could be re-implemented not using the NEW status, now that it basically doesn't exist.
That's bizarre! Does the RFC outline why, and what the appropriate replacement is? Maybe we can look at what something like Thunderbird or K9 mail does?
Hey. Looking into this again.
I haven't checked Thunderbird's or K9's implementation of push notifications, but I suspect it's implemented with IMAP's NOTIFY extension.
For the new messages delivered to or appended to the selected mailbox, the NOTIFY command can be used to request that a set of attributes be sent to the client in an unsolicited FETCH response. This allows a client to be a passive recipient of events and new mail and to be able to maintain full synchronisation without having to issue any subsequent commands except to modify the state of the mailbox on the server.
Having a connection that constantly listens for unsolicited FETCH responses with a given SEARCH pattern could be a good idea.
If the new/appended message is in the selected mailbox, the server notifies the client by sending an unsolicited EXISTS response, followed by an unsolicited FETCH response containing the information requested by the client. A FETCH response SHOULD NOT be generated for a new message created by the client on this particular connection, for instance, as the result of an APPEND or COPY command to the selected mailbox performed by the client itself. The server MAY also send a RECENT response, if the server marks the message as \Recent. Section 5.2
This looks really nice! Much of the hard work is already done by the server's IMAP implementation. I see that this project uses your Rust IMAP crate, ¿does it implement this extension?
It doesn't unfortunately. https://github.com/jonhoo/rust-imap/issues/63 would be the thing to keep an eye out for!