Re: push-notification plugin and imap-metadata permissions
On 2016-04-22 09:07 PM, Timo Sirainen wrote: On 22 Apr 2016, at 15:17, Giovanni S. Fois wrote: In order to tell if a mailbox is enabled to send out the notification, the plugin looks out for the following mailbox metadata key: /private/vendor/vendor.dovecot/pvt/server/vendor/vendor.dovecot/http-notify If the key is set then everything is OK and the notification is sent, otherwise the action is skipped. If I try to setup the metadata key by hand (telnet as the user over the imap port): setmetadata INBOX (/private/vendor/vendor.dovecot/pvt/server/vendor/vendor.dovecot/http-notify "user=myu...@mydomain.com") I get the error message: "Internal mailbox attributes cannot be accessed" Server metadata is set with: a SETMETADATA "" (/private/vendor/vendor.dovecot/http-notify "user=myu...@mydomain.com") Which should internally map into the INBOX's /private/vendor/vendor.dovecot/pvt/server/vendor/vendor.dovecot/http-notify. I am sorry, but this is not working. As you suggested I have launched the imap commands: a setmetadata "" (/private/vendor/vendor.dovecot/http-notify "user=myu...@mydomain.com") b getmetadata "" "/private/vendor/vendor.dovecot/http-notify" c getmetadata "INBOX" "/private/vendor/vendor.dovecot/pvt/server/vendor/vendor.dovecot/http-notify" the 'b' command returns a sort of json with the correct result the 'c' command returns NIL By the way, hardcoding the key as "/private/vendor/vendor.dovecot/http-notify" and recompiling the plugin has the effect to bring the system on the expected course. Thank you again for your time and kind support. Have a good weekend, Giovanni
Maildir P flag?
Hi, I use Thunderbird with a mailredirect addon. It used to show me which emails were redirected. I believe it used the "P" Maildiir flag for this status. Now it seems that none of my email store has any file with a flag of P. Is this something that dovecot may have adjusted with my mail store? And if so, why? If not, any ideas where I might look for the next "culprit"? ;-) Thanks AndrewM signature.asc Description: OpenPGP digital signature
Redirect indicator issue in Maildir flag seems to be an issue [missing?]
Hi, I've got an issue with the latest Thunderbird, although I'm not sure this is when the problem started (version 45.0) it has an add-on "mailredirect (version 0.8.7)". In the past I've been able to redirect mail (bounce them) and I get a nice little green arrow like indicator (in TB) to show that I redirected the particular email. Now, that green arrow appears briefly, then it goes away and I can no longer tell by looking at my email list if the email has, in fact, been bounced or not. I suspect it is dovecot on the Debian server: dovecot-common 1:2.1.7-7+deb7u1 dovecot-core 1:2.1.7-7+deb7u1 dovecot-imapd 1:2.1.7-7+deb7u1 dovecot-pop3d 1:2.1.7-7+deb7u1 It isn't just Thunderbird though, as I just tried to redirect using a Squirrelmail plugin, and it gives me the same problem; so I don't think it is at the MUA end of the deal. It /may/ be that TB is setting the flag and resetting it or dovecot is resetting it Any ideas? Nobody else has seen this yet? Thanks AndrewM signature.asc Description: OpenPGP digital signature
Re: Redirect indicator issue in Maildir flag seems to be an issue [missing?]
On 23.04.2016 20:27, Andrew McGlashan wrote: > Hi, Hi Andrew, > I've got an issue with the latest Thunderbird, although I'm not sure > this is when the problem started (version 45.0) it has an add-on > "mailredirect (version 0.8.7)". > > In the past I've been able to redirect mail (bounce them) and I get a > nice little green arrow like indicator (in TB) to show that I > redirected the particular email. I use the redirect mail plugin as well, even though with currently with Thunderbird 38.6.0 on Linux (Ubuntu) together with Dovecot 2.2.23 and I don't see this problem. The only thing that I see is that with Squirrelmail I never get this little green arrow (or a 'b' at the end of the filename (using maildir)). So it's either the new Thunderbird, or the old Dovecot... Isn't much of a help, but a data point at least... Cheers, Juri
Re: expunging messages doesn't update maildirsize
On 04/19/2016 07:17 PM, WJCarpenter wrote: Is it by design that dovecot doesn't update maildirsize immediately when messages are expunged? If yes, why? Replying to my own question since I figured it out. Local config glitch, not a dovecot bug or design fault. I should have mentioned that I don't use dovecot's local delivery agent. Updates to maildirsize for newly arriving messages is done by exim. Boring details follow. They become interesting details if you are having the same problem. :-) I use the SQL backend for keeping track of user data, including quota values. Consequently, I have configured 3 very similar (but not identical) SQL queries for that user data. One is in my exim config, and two (password_query and user_query) are in my dovecot-sql.conf. Those of you familiar with dovecot's SQL queries will know that the password_query can also return values that would ordinarily be looked up via user_query, the motivation being that user_query can often be skipped completely. The dovecot 2.2.9 release broke that userdb prefetch feature (it was fixed soon after, but I am using my distribution's dovecot version [Ubuntu 14.04], which is stuck at 2.2.9). Even though userdb prefetch doesn't work and both passdb and userdb queries are both done every time, my user_query is just a clone of my password_query in anticipation of the day when I can get rid of user_query. It's the cloning of the query where things went wrong. In the password_query, the prefetched user quota value is returned as "userdb_quota". In the user_query, it's returned as "quota". When I cloned the query, I neglected to change "userdb_quota" to "quota" in my select list. (That's a bummer, because I did correctly change "userdb_home" to "home" in my select list, so I must've known I should do it.) The net is that dovecot did the password_query and got the correct value for the user quota. It then ignored that (due to the prefetch bug) and did the user_query. The user_query reported the user quota with the wrong field name, and dovecot figured there was no quota for that user (which means /every/ user). Once I fixed my 7-character configuration mistake, it started working correctly. For the sake of brevity, I've left out the parts where I went down a bunch of blind alleys before finding the correct solution. :-)
Strange search behavior
Hello, I experienced a strange behavior in the way dovecot is performing searches, I only experienced this exact issue with the flag "seen". If I perform this command: UID SORT (SIZE) UTF-8 FLAGGED SEEN Dovecot return every seen messages even if the message is not "flagged'. This is only happening when there is no unseen messages in the mailbox, if there is at least one, this is working properly. Any though ? Thanks.