Re: Emails Ending up in Junk
Hello Łukasz, This happens when the user is logged in on the computer. The user has to check for important emails in Junk regularly. We're trying to turn off adaptive Junk filters in Thunderbird right now, but I'm not sure if it's a TB issue or something with the server side filtering. Also, Spamassassin isn't marking these emails as spam either, so we're kind of stumped right now. On 4/2/2021 1:34 PM, Łukasz Szczepański wrote: Thunderbird has built in spam control feature and can move message to junk on it self. When message is moved to Junk? Only when user is connected to mailbox or even when nobody is logon? W dniu 2 kwi 2021, o 20:26, użytkownik Asai mailto:a...@globalchangemusic.org>> napisał: Greetings, I'm trying to debug an issue with a user who is finding emails (user uses Thunderbird as client) ending up in Junk folder, and constantly marks email as Not Junk, but important email ends up in Junk folder. I have sieve set up, but am unable to determine if this is the result of a sieve problem (sieve will automatically move certain emails into Junk if certain headers are present, but these headers are not present on these emails.) I'm looking in Dovecot debug logs to try to figure this out, but all I can find is sometimes this, and I don't know if this is relevant. Can anyone point us in the right direction for solving this issue? Apr 01 11:51:05 imap(u...@domain.tld)<102535><+kTsYd6+f83AqEbH>: Debug: Mailbox Junk: Mailbox opened because: UID move Apr 01 11:57:08 imap(u...@domain.tld)<102735>: Debug: Mailbox Junk: UID 565: Opened mail because: prefetch Apr 01 11:57:08 imap(u...@domain.tld)<102735>: Debug: Mailbox Junk: UID 565: Opened mail because: access Apr 01 11:57:08 imap(u...@domain.tld)<102735>: Debug: Mailbox Junk: UID 565: Opened mail because: full mail Apr 01 12:00:20 imap(u...@domain.tld)<71333>: Debug: Mailbox Junk: Mailbox opened because: STATUS Apr 01 18:52:10 imap(u...@domain.tld)<114066>: Debug: Mailbox Junk: Mailbox opened because: SELECT -- Asai 520.260.6887
.IMAP locations
I have this account, /usr/home/me To be able to admin websites, I created a folder /usr/home/me/www , containing my siteroot /usr/home/me/www/mysite.com My dovecot.config: mail_location = mbox:/home/%u:INBOX=/var/mail/%u the actual mailfolder is /usr/home/me/mail , which I defined in my mailclient as 'mail/' The issue now is that Dovecot is indexing my whole /usr/home/me/ folder, including the www folder, in which it also idexes every folder that is in /usr/home/me/www/mysite.com . It puts in these folders an .imap folder that is containing the exact content of the folder it is put in. So my site takes double space by this Dovecot indexing. To solve this issue, I defined my mail_location line as mail_location = mbox:/home/%u/mail:INBOX=/var/mail/%u and removed the 'mail/' directive from my mail client. For some reason this does not prevent Dovecot to index the subfolders of /usr/home/me/www/ - Do I have to remove all Dovecot related indexing files by hand to solve this and restart Dovecot service afterwards? - Can you tell me how I can define the Dovecot index files location so that there will be no .imap folder created anymore in my /usr/home/me/www/ subfolder(s)? Thanks for you help! Elise #CSSis {beautiful};
failed: Cached message size smaller than expected
Every few days, my mailbox seizes up. No mail come in to my imap clients. I'm getting these errors over and over with my mailbox: Error: Mailbox INBOX: Deleting corrupted cache record uid=371208: UID 371208: Broken physical size in mailbox INBOX: read(/var/mail/mgrant) failed: Cached message size smaller than expected (17212 < 17222, box=INBOX, UID=371208) Error: Mailbox INBOX: UID=371208: read(/var/mail/mgrant) failed: Cached message size smaller than expected (17212 < 17222, box=INBOX, UID=371208) (FETCH BODY[]) Error: Mailbox INBOX: Deleting corrupted cache record uid=371203: UID 371203: Broken physical size in mailbox INBOX: read(/var/mail/mgrant) failed: Cached message size smaller than expected (3904 < 3914, box=INBOX, UID=371203) Error: Mailbox INBOX: UID=371203: read(/var/mail/mgrant) failed: Cached message size smaller than expected (3904 < 3914, box=INBOX, UID=371203) (FETCH BODY[]) My inbox is an mbox file. I'm running dovecot installed on Debian Bullseye, the dovecot packages are all: 1:2.3.13+dfsg1-1 I am running sendmail and using procmail for local delivery. I suspect, but am not certain, that this may be some locking issue between procmail and dovecot but I have never been able to prove that. The final procmail rule which appends messages to my mailbox looks like this, the trailing ':' causes procmail to use a lockfile: :0: /var/mail/mgrant The locking config lines in 10-mail.conf are commented, but I have also tried uncommenting them, did not help: #mbox_read_locks = fcntl #mbox_write_locks = fcntl dotlock Though sometimes it seems to fix itself after a few hours, the only way I have found to fix this quickly is to manually remove the cache files and restart dovecot: rm ~/mail/.imap/INBOX/* systemctl restart dovecot I am not even sure this is a locking issue. Something definitely gets corrupted though. I do have several IMAP clients hitting the same mailbox (phone, laptop, desktop). On the phone, I run K9 and also the gmail client which talks imap. Also using thunderbird, outlook, and w10 mail, though typically not all at the same time. You could definitely say I am stress testing this setup a bit! Any ideas on how to resolve this? Michael Grant signature.asc Description: PGP signature
Re: Emails Ending up in Junk
Thunderbird has built in spam control feature and can move message to junk on it self. When message is moved to Junk? Only when user is connected to mailbox or even when nobody is logon? W dniu 2 kwi 2021, 20:26, o 20:26, użytkownik Asai napisał: >Greetings, > >I'm trying to debug an issue with a user who is finding emails (user >uses Thunderbird as client) ending up in Junk folder, and constantly >marks email as Not Junk, but important email ends up in Junk folder. > >I have sieve set up, but am unable to determine if this is the result >of >a sieve problem (sieve will automatically move certain emails into Junk > >if certain headers are present, but these headers are not present on >these emails.) > >I'm looking in Dovecot debug logs to try to figure this out, but all I >can find is sometimes this, and I don't know if this is relevant. Can >anyone point us in the right direction for solving this issue? > >Apr 01 11:51:05 imap(u...@domain.tld)<102535><+kTsYd6+f83AqEbH>: Debug: >Mailbox Junk: Mailbox opened because: UID move >Apr 01 11:57:08 imap(u...@domain.tld)<102735>: Debug: >Mailbox Junk: UID 565: Opened mail because: prefetch >Apr 01 11:57:08 imap(u...@domain.tld)<102735>: Debug: >Mailbox Junk: UID 565: Opened mail because: access >Apr 01 11:57:08 imap(u...@domain.tld)<102735>: Debug: >Mailbox Junk: UID 565: Opened mail because: full mail >Apr 01 12:00:20 imap(u...@domain.tld)<71333>: Debug: >Mailbox Junk: Mailbox opened because: STATUS >Apr 01 18:52:10 imap(u...@domain.tld)<114066>: Debug: >Mailbox Junk: Mailbox opened because: SELECT
Emails Ending up in Junk
Greetings, I'm trying to debug an issue with a user who is finding emails (user uses Thunderbird as client) ending up in Junk folder, and constantly marks email as Not Junk, but important email ends up in Junk folder. I have sieve set up, but am unable to determine if this is the result of a sieve problem (sieve will automatically move certain emails into Junk if certain headers are present, but these headers are not present on these emails.) I'm looking in Dovecot debug logs to try to figure this out, but all I can find is sometimes this, and I don't know if this is relevant. Can anyone point us in the right direction for solving this issue? Apr 01 11:51:05 imap(u...@domain.tld)<102535><+kTsYd6+f83AqEbH>: Debug: Mailbox Junk: Mailbox opened because: UID move Apr 01 11:57:08 imap(u...@domain.tld)<102735>: Debug: Mailbox Junk: UID 565: Opened mail because: prefetch Apr 01 11:57:08 imap(u...@domain.tld)<102735>: Debug: Mailbox Junk: UID 565: Opened mail because: access Apr 01 11:57:08 imap(u...@domain.tld)<102735>: Debug: Mailbox Junk: UID 565: Opened mail because: full mail Apr 01 12:00:20 imap(u...@domain.tld)<71333>: Debug: Mailbox Junk: Mailbox opened because: STATUS Apr 01 18:52:10 imap(u...@domain.tld)<114066>: Debug: Mailbox Junk: Mailbox opened because: SELECT
Re: Virtual folders and mailbox_list_get_root_forced
Hello Anyone on this ? Thank you On 2021-03-28 20:55, Joan Moreau wrote: yes, this is getting to a mess Details can be seen here : https://github.com/grosjo/fts-xapian/issues/72 It shows that sometimes mailbox_list_get_root_forced return the generic INDEX value, sometimes the namespace value thank you for your help On 2021-03-28 12:03, Aki Tuomi wrote: Hi! mail_location = maildir:/var/vmail/%d/%n:LAYOUT=fs:INDEX=/var/mailindex This is going to put everyone's indexes under /var/mailindex, without separating them properly. Might cause fun issues. Can you give an concrete example of what your issue is? Aki On 28/03/2021 13:35 Joan Moreau wrote: Hi Anyone on that ? Thank you so much On 2021-03-22 18:16, Joan Moreau wrote: Hi The function mailbox_list_get_root_forcedreturns sometimes the first or the second value of the INDEX param for the same mailbox. How to make sure this returns only the correct one of the corresponding mailbox ? mail_location = maildir:/var/vmail/%d/%n:LAYOUT=fs:INDEX=/var/mailindex namespace { location = virtual:/nix/store/toto-virtual:INDEX=/var/vmail/%d/%n/virtual prefix = virtual/ separator = / subscriptions = no } Thank you
Re: Virtual folders and mailbox_list_get_root_forced
Ah, no. I tried very much to look into the details you provided but it's still not making much sense. Can you maybe try providing answers to: 1. What you did? 2. What did you expect? 3. What happened instead? because right now that's not really very clear here. Aki > On 02/04/2021 16:23 Joan Moreau wrote: > > > Hello > Anyone on this ? > Thank you > > > On 2021-03-28 20:55, Joan Moreau wrote: > > yes, this is getting to a mess > > Details can be seen here : https://github.com/grosjo/fts-xapian/issues/72 > > It shows that sometimes mailbox_list_get_root_forced return the generic > > INDEX value, sometimes the namespace value > > thank you for your help > > > > > > On 2021-03-28 12:03, Aki Tuomi wrote: > > > Hi! > > > > > > mail_location = maildir:/var/vmail/%d/%n:LAYOUT=fs:INDEX=/var/mailindex > > > > > > This is going to put everyone's indexes under /var/mailindex, without > > > separating them properly. Might cause fun issues. > > > > > > Can you give an concrete example of what your issue is? > > > > > > Aki > > > > > > > > > > On 28/03/2021 13:35 Joan Moreau wrote: > > > > > > > > > > > > Hi > > > > Anyone on that ? > > > > Thank you so much > > > > > > > > > > > > On 2021-03-22 18:16, Joan Moreau wrote: > > > > > Hi > > > > > The function mailbox_list_get_root_forcedreturns sometimes the first > > > > > or the second value of the INDEX param for the same mailbox. > > > > > > > > > > How to make sure this returns only the correct one of the > > > > > corresponding mailbox ? > > > > > > > > > > mail_location = > > > > > maildir:/var/vmail/%d/%n:LAYOUT=fs:INDEX=/var/mailindex > > > > > namespace { > > > > > location = > > > > > virtual:/nix/store/toto-virtual:INDEX=/var/vmail/%d/%n/virtual > > > > > prefix = virtual/ > > > > > separator = / > > > > > subscriptions = no > > > > > } > > > > > > > > > > Thank you > > > > >
Incorrect value sent to solr
Hello, I've recently stumbled upon an error in fts-solr plugin. Dovecot sends "rows" parameter to solr when someone is searching in mailbox, but value of rows can be bigger than int in java. If I understand correctly, rows is equal to the last message id on current imap folder. I have mailbox where last uid value is 2206267083 and when I tried to search in this mailbox I got error 400 - Bad Request. On a Solr side I got an error: java.lang.NumberFormatException: For input string: "2206267083" NumberFormat expect an int which max value is 2147483647. Quick test reviles that rows parameter isn't required for correct response from solr. I think that dovecot should check if the value of rows is a correct int, and if not, just skip this argument. Dovecot version: 2.3.11.3 (502c39af9) Solr version: 8.7.0 -- Łukasz Szczepański +48 58 3509284 www.webd.pl [1] Globtel Internet Links: -- [1] http://www.webd.pl