Re: Mail Backup from IMAP to POP3

[Christopher via dovecot]

I'm looking for how to take the email and send it to an email client of choice ?
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

RE: Mail Backup from IMAP to POP3

[Christopher via dovecot]

My mistake.
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

RE: Mail Backup from IMAP to POP3

[Marc via dovecot]

> 
> It doesn't look as if IMAP is supported ?
> ___

Maybe try again later after a good night rest?
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Mail Backup from IMAP to POP3

[Christopher via dovecot]

I use the term POP3 very loose cause the email client in question which I want 
all my emails (IMAP) to be unloaded off and downloaded directed into an POP3 
client.
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Mail Backup from IMAP to POP3

[Christopher via dovecot]

It doesn't look as if IMAP is supported ?
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: [External] Mail Backup from IMAP to POP3

[Christopher via dovecot]

Compact in Thunderbird, can't I start up any email client; in this case a 
client on my NAS and have them unloaded off IMAP into this email client ?
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

RE: shared mailbox not visible, acl_shared_dict stays empty

[Marc via dovecot]

> 
> I am creating the mailbox like this:
> 
> doveadm -o mail_gid=testgroup2 mailbox create -u usertest
> shared/sharedtest1
> 
> I can set acl's (I think), at least the acl get produces the same.
> 
> doveadm acl set -u usertest shared/sharedtest1 user=usertest6 lookup read
> write write-seen insert post
> doveadm acl get -u usertest shared/sharedtest1
> 
> However this file stays empty, I have read somewhere it should
> automatically be updated?
> 
> acl_shared_dict = file:/tmp/shared-mailboxes.db
> 
> How should I add entries manually there with:
> 
> doveadm dict set file:/tmp/shared-mailboxes.db shared/sharedtest2
> kempotest6
> 
> or with this syntax still
> https://www.dovecot.org/list/dovecot/2009-April/038922.html


wtf is this username = mailbox ???

Debug: acl: initializing backend with data: vfile
Sep 22 22:12:28 doveadm(usertest): Debug: acl: acl username = sharedtest9
Sep 22 22:12:28 doveadm(usertest): Debug: acl: owner = 1
Sep 22 22:12:28 doveadm(usertest): Debug: acl vfile: Global ACLs disabled
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

RE: public mailbox filesystem layout + permission best practice

[Marc via dovecot]

> 
> I have some issues testing public mailboxes with linux users and groups
> 
> creating mailboxes for users for the first group is not really a problem:
> 
> doveadm -o mail_gid=testgroup2 mailbox create -u usertest
> public/publictest1
> doveadm -o mail_gid=testgroup2 mailbox create -u usertest6
> public/publictest2
> doveadm -o mail_gid=testgroup2 mailbox create -u usertest2
> public/publictest3
> 
> If I remove usertest6 from testgroup2 roundcube instantly stops showing
> these mailboxes. 
> 

correction. When I chmod o+rwx on folders 'mdbox' 'storage' 'mailboxes' 
usertest6 is getting to see ALL mailboxes.
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Free ecards

[Aki Tuomi via dovecot]

> On 20/09/2024 14:16 EEST Serhii via dovecot  wrote:
> 
>  
> 2024-09-20T11:15:02Z Benny Pedersen via dovecot :
> 
> > you write on public free maillist, so why ?, google photos can also create 
> > "cards" :)
> > 
> > in case of language problem please be more verbose on how to help with 
> > dovecot solve, need to chat ?, take irc :)
> 
> Please do not reply to spam.

In this regards, I've made some changes to the mailing list settings. 
Unfortunately spammers have evolved ability to actually subscribe to mailing 
lists, so this might happen more often than before. Lets see if we can keep it 
under control though.

Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Free ecards

[Benny Pedersen via dovecot]

Marc via dovecot skrev den 2024-09-20 13:21:

Hi Benny, if you have time to engage in spam, is there any chance you 
can help me with some sieve issue ;)


no logs no problem

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

RE: Free ecards

[Marc via dovecot]

> Amelia Marie via dovecot skrev den 2024-09-20 08:44:
> > Free ecards from Sendwishonline.com are designed to create memorable
> > and engaging experiences. Many cards feature interactive elements, such
> > as animations and music, that enhance the recipient's experience. This
> > level of creativity and engagement sets Sendwishonline.com apart,
> > making their free ecards not just a message but a delightful
> > experience.
> 
> you write on public free maillist, so why ?, google photos can also
> create "cards" :)
> 
> in case of language problem please be more verbose on how to help with
> dovecot solve, need to chat ?, take irc :)
> 

Hi Benny, if you have time to engage in spam, is there any chance you can help 
me with some sieve issue ;)
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Free ecards

[Serhii via dovecot]

2024-09-20T11:15:02Z Benny Pedersen via dovecot :

> you write on public free maillist, so why ?, google photos can also create 
> "cards" :)
> 
> in case of language problem please be more verbose on how to help with 
> dovecot solve, need to chat ?, take irc :)

Please do not reply to spam.
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Free ecards

[Benny Pedersen via dovecot]

Amelia Marie via dovecot skrev den 2024-09-20 08:44:
Free ecards from Sendwishonline.com are designed to create memorable 
and engaging experiences. Many cards feature interactive elements, such 
as animations and music, that enhance the recipient's experience. This 
level of creativity and engagement sets Sendwishonline.com apart, 
making their free ecards not just a message but a delightful 
experience.


you write on public free maillist, so why ?, google photos can also 
create "cards" :)


in case of language problem please be more verbose on how to help with 
dovecot solve, need to chat ?, take irc :)


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: User is missing UID

[Aki Tuomi via dovecot]

> On 19/09/2024 12:34 EEST Marc via dovecot  wrote:
> 
>  
> sieve-test(1164123): Fatal: Couldn't drop privileges: User is missing UID 
> (see mail_uid setting)
> 
> I don't get what this is about. Users are not missing an UID and how is it 
> related with testing sieve scripts?
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org

It means that userdb lookup did not return an uid, you can use

sieve-test -o mail_uid=$UID ... 

to workaround this.

Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

RE: sieve: Terminated with non-zero exit code 2

[Marc via dovecot]

> 
> What could this be, I am not even having an exit code 2 in my sieve
> plugin. If I cat a message via cli I am getting exit code 0.
> 
> ps where are stderr messages logged of the plugin?
>

script is ok
Debug: sieve: Finished running script  (status=ok, resource usage: no usage 
recorded)
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Pay Someone to Take My Online Course?

[michaelhaydon55--- via dovecot]

I’ve been following this thread with great interest. It’s insightful to see the 
community’s engagement on this topic. As a student-focused service, 
Myassignmenthelp.com is committed to delivering exceptional assignment 
assistance. Our team of experts is dedicated to providing detailed, 
well-researched solutions to help students excel in their studies. If you’re 
struggling with complex assignments or need expert guidance, our platform 
offers tailored support to meet your needs. Feel free to explore our services 
at Myassignmenthelp for reliable solutions 
(https://myassignmenthelp.com/do_my_assignment.html). We’re here to help you 
achieve your academic goals.
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Dovecot v2.3.21.1 released

[Aki Tuomi via dovecot]

> On 17/09/2024 11:52 EEST Aleksandr Mezin via dovecot  
> wrote:
> 
>  
> Hello.
> 
> https://www.dovecot.org/download/ still points to v2.3.21 as the
> latest stable release (not 2.3.21.1)

Thank you for pointing this out, links have been updated.

Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: [External] Mail Backup from IMAP to POP3

[Kevin A. McGrail via dovecot]

On 9/15/2024 10:54 PM, Reprobus via dovecot wrote:
RAPTOR REMARK: Alert! Please be careful! This email is from an 
EXTERNAL sender. Be aware of impersonation and credential theft.


Hi, I'm in a situation whereas I need to backup my email from an IMAP 
server to a POP3 email client of my choosing. I'm hoping Dovecot can 
do such a task and is there a container to which I can run to set this 
up from ?


My IMAP email server is maxed and I need to dump all the emails off 
the IMAP to POP3 as to clear it up.


Hi, so your question is a bit confusing because IMAP and POP3 are 
different protocols.  So let's focus on what you need to do which I 
gather is to clear some space on the server.


You can do this with either IMAP or POP3.

For example, if you use Thunderbird, you can create a local folder and 
drag emails from folders on IMAP to that local folder. Then compact the 
folder on the IMAP server to make sure they are actually deleted.


Most hosts support both IMAP and POP3 and you'll get access with POP3 to 
your Inbox.  You can do the same thing where you download all the email 
from the server Inbox via POP3 and it will clear up space.


However, you might want to look into your IMAP folders and A) make sure 
you need them all and B) make sure they are compacted. Most IMAP servers 
don't delete things until you actually compact the folders.  It's 
possible you've been deleting things but not compacting so you have some 
space available.


I hope this helps,

KAM

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Dovecot v2.3.21.1 released

[Aleksandr Mezin via dovecot]

Hello.

https://www.dovecot.org/download/ still points to v2.3.21 as the
latest stable release (not 2.3.21.1)
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Mail Backup from IMAP to POP3

[Ralph Seichter via dovecot]

* Vladislav Kurz via dovecot:

> How about just moving the emails to the local folders of your
> favourite mail client?

Certainly a pragmatic approach. However, one might paint oneself into a
corner, if the mail client in question uses a proprietory storage
format.

Personally, I like the classic "Maildir" format storage, which can be
accessed with a variety of MUAs, has been around for more than 25 years,
and is not expected to disapper together with some discontinued mail
client or other.

-Ralph
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Correct permissions for global sieve scripts

[Richard via dovecot]

On 16.09.24 13:07, Sirius wrote:

On mån, 2024/09/16 at 11:41:24 +0200, Richard via dovecot wrote:

On 16.09.24 09:50, Sirius wrote:

On sön, 2024/09/15 at 14:30:19 +0200, Richard via dovecot wrote:

[snip]

I do the same as you.

Not exactly. I'm on rspamd 3.9.1-1~82f43560f~bookworm. From rspamd's repo.

Ah, that may be the source of your problems.



Parts of my problem, but not in this case actually. My solution is now in the thread with 
Aki Tuomi. Seems to have been an unlucky combination of outdated rspamc handling and 
using bash's "exec" where it seems to not belong.


I only have sieve_global_extensions enabled. As user scripts aren't supposed to 
be able to access external programs I don't see any benefit configuring that 
setting

I did it in case I want to have stricter personal settings than the rest
of my family. The default global sieve cuts spam off at a score of 10.
Personally, I may end up lowering that to 8.0-8.5 somewhere.


Good to know


[snip]

sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.environment

I only had +vnd.dovecot.pipe in here. Let's the if adding 
+vnd.dovecot.environment changes anything.


sieve_spamtest_status_type = score
sieve_spamtest_status_header = X-Spam_score: (-?[[:digit:]]+\.[[:digit:]])
sieve_spamtest_max_value = 6
sieve_before = /etc/dovecot/sieve/global-spam.sieve

I never configured these. What are their use? I've just set up another sieve 
script (which seems to be working just fine) to sort out all messages marked as 
spam into the users junk directory. Is this just to do that?

This comes from https://github.com/darix/dovecot-sieve-antispam-rspamd/
which is what I ended up adapting as it was not an exact match for my
environment.

First two lines does the spam testing based on the score rspamd have
assigned the incoming message (hence the last three sieve extensions in
the section above).



Interesting solution. Didn't know dovecot could do that. I have a larger sieve 
script that will match all messages containing a spam flag in the header - our 
spam filter is actually a secondary one, because while the primary is a 
commercial one, it's pretty bad so it misses a lot - and some typical keywords 
from the subject you won't ever find in a legit mail and move them to junk. 
Also, I have some logic to help keep ham out of the junk directory if rspamd is 
falsely categorizing mail as spam from known trustworthy senders, as rspamd's 
whitelisting is quite flaky.


The only other thing was to get the password out of
/etc/rspamd/worker-controller.inc and put it in
/etc/dovecot/rspamd-controller.password (or whatever file your
learn-{sp,h}am script points at to get the password). It needed to be
pointed at 127.0.0.1:11334 for the socket.

What is the password needed for? Because manually executing rspamc doesn't ask 
for some password either. The worker-controller.inc does point at 127.0.0.1 and 
::1, but no port seems to be configured.

When you connect to rspamd controller (port 11334), it is authenticated.
Presumably so that not just anyone can report spam/ham and mess up the
scoring. If it runs only on loopback and there is no port-forwarding,
authentication is perhaps unnecessary, but it makes sense to have it
enabled anyway if someone else can log into the system as a regular user.



Good to know, but I think it may be safer to use worker-normal instead with 
setting allow_learn to true in its config. That way you don't need the higher 
privileges the controller has. And you shouldn't need the worker-controller's 
password. At least as far as I understand 
https://rspamd.com/doc/workers/normal.html. But I in my trials, sending mail to 
the port of worker-normal still requires the password of worker-controller.  So 
that's only theoretical. Also, as all of this has no permissions for normal 
user to access it, it's a bit redundant.


Worth checking how rspamc calls into rspamd (maybe you use a socket in
/run or similar) and see if they have defaulted to authentication on for
the sockets. Or roll rspamd back to previous version for the time being.



Thankfully that's all resolved now adding the port to use (and currently the 
password, maybe that can be dropped somehow). So I guess rspamd changed its 
behavior at some point I didn't notice and deprecated the old ways.


But thanks for the details.

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Correct permissions for global sieve scripts

[Richard via dovecot]

So, there was actually one piece missing to fully solve this puzzle. For whatever reason, 
the guide I used back when I set up the scripts put "exec" in front of the 
actual command. Not sure what it does, but it's garbage in this scenario. As far as I 
read it somehow replaces bash with whatever you execute. Executing the command from 
rspamd-learn-spam.sh with the exec infront on a remote machine will terminate the remote 
session. So just removing that seems to have fixed all error messages (the IO error due 
to EOF can still happen, but it won't happen every time anymore). So it wasn't a 
permission issue or any issue with dovecot, just a bad command inside the script.

Thanks all for chiming in.


On 16.09.24 13:12, Richard wrote:

This actually helped.

So I'm not entirely sure when my method stopped working, but for all I can tell 
it used to work. Now this has changed. I've changed rspamd-learn-spam.sh to 
this:


#!/bin/sh
exec /usr/bin/rspamc -h localhost:11333 -P  learn_spam


Manually testing this now works better, so I'll just have to wait for the spam 
mail to be missed to test if this actually solves the issue. Can't be that long.


PS: rspamd for my config doesn't use socket files. But the needed port is the same that's 
written in /etc/rspamd/local.d/worker-normal.inc (and in /etc/rspamd/rspamd.conf in the 
worker "normal"{} section).

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Correct permissions for global sieve scripts

[Richard via dovecot]

This actually helped.

So I'm not entirely sure when my method stopped working, but for all I can tell 
it used to work. Now this has changed. I've changed rspamd-learn-spam.sh to 
this:


#!/bin/sh
exec /usr/bin/rspamc -h localhost:11333 -P  learn_spam


Manually testing this now works better, so I'll just have to wait for the spam 
mail to be missed to test if this actually solves the issue. Can't be that long.


PS: rspamd for my config doesn't use socket files. But the needed port is the same that's 
written in /etc/rspamd/local.d/worker-normal.inc (and in /etc/rspamd/rspamd.conf in the 
worker "normal"{} section).

On 16.09.24 11:21, Aki Tuomi wrote:

Also to double-check, can you compare your setup against 
https://doc.dovecot.org/2.3/configuration_manual/howto/antispam_with_sieve/#for-rspamd
 ?

Aki

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Correct permissions for global sieve scripts

[Sirius via dovecot]

On mån, 2024/09/16 at 11:41:24 +0200, Richard via dovecot wrote:
> 
> On 16.09.24 09:50, Sirius wrote:
> > On sön, 2024/09/15 at 14:30:19 +0200, Richard via dovecot wrote:
[snip]
> > I do the same as you.
> 
> Not exactly. I'm on rspamd 3.9.1-1~82f43560f~bookworm. From rspamd's repo.

Ah, that may be the source of your problems.

> > I have this in the plugin {} section of dovecot.conf:
> > 
> ># This will automatically move spam into Junk/ and when you move a 
> > message
> ># into Junk, it will tell rspamd that it is spam for Bayes learning. 
> > Moving
> ># false positives out of Junk/ will teach rspamd that it is ham.
> >sieve_plugins = sieve_imapsieve sieve_extprograms
> >sieve_extensions = +editheader +imapflags +mboxmetadata +notify 
> > +servermetadata +spamtest +spamtestplus +virustest
> 
> I only have sieve_global_extensions enabled. As user scripts aren't supposed 
> to be able to access external programs I don't see any benefit configuring 
> that setting

I did it in case I want to have stricter personal settings than the rest
of my family. The default global sieve cuts spam off at a score of 10.
Personally, I may end up lowering that to 8.0-8.5 somewhere.

[snip]
> >sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.environment
> 
> I only had +vnd.dovecot.pipe in here. Let's the if adding 
> +vnd.dovecot.environment changes anything.
> 
> >sieve_spamtest_status_type = score
> >sieve_spamtest_status_header = X-Spam_score: 
> > (-?[[:digit:]]+\.[[:digit:]])
> >sieve_spamtest_max_value = 6
> >sieve_before = /etc/dovecot/sieve/global-spam.sieve
> 
> I never configured these. What are their use? I've just set up another sieve 
> script (which seems to be working just fine) to sort out all messages marked 
> as spam into the users junk directory. Is this just to do that?

This comes from https://github.com/darix/dovecot-sieve-antispam-rspamd/
which is what I ended up adapting as it was not an exact match for my
environment.

First two lines does the spam testing based on the score rspamd have
assigned the incoming message (hence the last three sieve extensions in
the section above).

> > The only other thing was to get the password out of
> > /etc/rspamd/worker-controller.inc and put it in
> > /etc/dovecot/rspamd-controller.password (or whatever file your
> > learn-{sp,h}am script points at to get the password). It needed to be
> > pointed at 127.0.0.1:11334 for the socket.
> 
> What is the password needed for? Because manually executing rspamc doesn't 
> ask for some password either. The worker-controller.inc does point at 
> 127.0.0.1 and ::1, but no port seems to be configured.

When you connect to rspamd controller (port 11334), it is authenticated.
Presumably so that not just anyone can report spam/ham and mess up the
scoring. If it runs only on loopback and there is no port-forwarding,
authentication is perhaps unnecessary, but it makes sense to have it
enabled anyway if someone else can log into the system as a regular user.

> 
> > root@debian:~# cat /etc/dovecot/rspamd-controller.conf.sh
> > # Path to file containing the controller password
> > # (Or, if it doesn't start with '/' or '.', the password itself.
> > # But it might leak the password through ps to other users)
> > RSPAMD_CONTROLLER_PASSWORD=/etc/dovecot/rspamd-controller.password
> > # passed to rspamc with the -h option (host and port)
> > RSPAMD_CONTROLLER_SOCKET=127.0.0.1:11334
> > # if set uses curl instead of rspamc; should start with http: or https:
> > RSPAMD_CONTROLLER_HOST=
> > # classifier to learn for (default by rspamc: bayes), e.g. `bayes_user`
> > RSPAMD_CLASSIFIER=bayes
> > 
> > 
> >  From what I remember, it was somewhat fiddly to get this working as I was
> > not intimately familiar with rspamd, nor dovecot or sieve, but this works
> > and it works well. Relatively low incident rate of false positives after a
> > some weeks.
> 
> We used to have the same for quite a while now, without needing any of that. 
> I guess the last rspamd update was just borked that much that it won't work 
> for the time being. Some messages aren't even processed at all...

Worth checking how rspamc calls into rspamd (maybe you use a socket in
/run or similar) and see if they have defaulted to authentication on for
the sockets. Or roll rspamd back to previous version for the time being.

-- 
Kind regards,

/S
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Correct permissions for global sieve scripts

[Richard via dovecot]

On 16.09.24 09:50, Sirius wrote:

On sön, 2024/09/15 at 14:30:19 +0200, Richard via dovecot wrote:

I've set up dovecot via global sieve scripts to send mails that a user
manually moved to their junk directory to rspamd to learn them as spam
(and learn messages as ham if they are moved out of it). I thought I had
it all properly set up, but I'm now again seeing log messages like this:

root@debian:~# dpkg -l | egrep '^ii.*(rspam|dovecot-core)'
ii  dovecot-core 1:2.3.21.1+dfsg1-1~bpo12+1  
amd64secure POP3/IMAP server - core files
ii  rspamd   3.4-1   
amd64Rapid spam filtering system

I do the same as you.



Not exactly. I'm on rspamd 3.9.1-1~82f43560f~bookworm. From rspamd's repo.


root@debian:~# ls -l /etc/dovecot/sieve
total 32
-rw-r- 1 vmail dovecot  188 Sep  4 13:41 global-spam.sieve
-rw-r- 1 vmail vmail330 Sep  4 14:01 global-spam.svbin
-rwxr-x--- 2 vmail dovecot 2579 Sep  4 13:44 learn-ham.rspamd.script
-rw-r- 1 vmail dovecot  256 Sep  4 13:42 learn-ham.sieve
-rw-r- 1 vmail dovecot  442 Sep  5 03:55 learn-ham.svbin
-rwxr-x--- 2 vmail dovecot 2579 Sep  4 13:44 learn-spam.rspamd.script
-rw-r- 1 vmail dovecot  151 Sep  4 13:43 learn-spam.sieve
-rw-r- 1 vmail dovecot  341 Sep  5 03:56 learn-spam.svbin

The scripts need to be executable.



Yes, I forgot to mention that both shell scripts have 770 permissions.


I have this in the plugin {} section of dovecot.conf:

   # This will automatically move spam into Junk/ and when you move a message
   # into Junk, it will tell rspamd that it is spam for Bayes learning. Moving
   # false positives out of Junk/ will teach rspamd that it is ham.
   sieve_plugins = sieve_imapsieve sieve_extprograms
   sieve_extensions = +editheader +imapflags +mboxmetadata +notify 
+servermetadata +spamtest +spamtestplus +virustest



I only have sieve_global_extensions enabled. As user scripts aren't supposed to 
be able to access external programs I don't see any benefit configuring that 
setting



   imapsieve_mailbox1_before =file:/etc/dovecot/sieve/learn-spam.sieve
   imapsieve_mailbox1_causes = COPY APPEND FLAG
   imapsieve_mailbox1_name = Junk
   imapsieve_mailbox2_before =file:/etc/dovecot/sieve/learn-ham.sieve
   imapsieve_mailbox2_causes = COPY APPEND FLAG
   imapsieve_mailbox2_from = Junk
   imapsieve_mailbox2_name = *
   sieve_pipe_bin_dir = /etc/dovecot/sieve
   sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.environment



I only had +vnd.dovecot.pipe in here. Let's the if adding 
+vnd.dovecot.environment changes anything.


   sieve_spamtest_status_type = score
   sieve_spamtest_status_header = X-Spam_score: (-?[[:digit:]]+\.[[:digit:]])
   sieve_spamtest_max_value = 6
   sieve_before = /etc/dovecot/sieve/global-spam.sieve



I never configured these. What are their use? I've just set up another sieve 
script (which seems to be working just fine) to sort out all messages marked as 
spam into the users junk directory. Is this just to do that?



The only other thing was to get the password out of
/etc/rspamd/worker-controller.inc and put it in
/etc/dovecot/rspamd-controller.password (or whatever file your
learn-{sp,h}am script points at to get the password). It needed to be
pointed at 127.0.0.1:11334 for the socket.



What is the password needed for? Because manually executing rspamc doesn't ask 
for some password either. The worker-controller.inc does point at 127.0.0.1 and 
::1, but no port seems to be configured.



root@debian:~# cat /etc/dovecot/rspamd-controller.conf.sh
# Path to file containing the controller password
# (Or, if it doesn't start with '/' or '.', the password itself.
# But it might leak the password through ps to other users)
RSPAMD_CONTROLLER_PASSWORD=/etc/dovecot/rspamd-controller.password
# passed to rspamc with the -h option (host and port)
RSPAMD_CONTROLLER_SOCKET=127.0.0.1:11334
# if set uses curl instead of rspamc; should start with http: or https:
RSPAMD_CONTROLLER_HOST=
# classifier to learn for (default by rspamc: bayes), e.g. `bayes_user`
RSPAMD_CLASSIFIER=bayes


 From what I remember, it was somewhat fiddly to get this working as I was
not intimately familiar with rspamd, nor dovecot or sieve, but this works
and it works well. Relatively low incident rate of false positives after a
some weeks.



We used to have the same for quite a while now, without needing any of that. I 
guess the last rspamd update was just borked that much that it won't work for 
the time being. Some messages aren't even processed at all...
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Correct permissions for global sieve scripts

[Aki Tuomi via dovecot]

Also to double-check, can you compare your setup against 
https://doc.dovecot.org/2.3/configuration_manual/howto/antispam_with_sieve/#for-rspamd
 ?

Aki

> On 16/09/2024 12:18 EEST Richard via dovecot  wrote:
> 
>  
> I did forget to mention both shell scripts have rwx, rwx, - permissions. 
> manually executing rspamc does result in a "IO read error: unexpected EOF". 
> So yet another issue to add to the list I guess...
> 
> 
> Richard
> 
> On 16.09.24 09:07, Aki Tuomi wrote:
> > Did you remember to set +x on the rspamd-learn-spam.sh script?
> >
> > Does it work if you invoke it by hand?
> >
> > Aki
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Correct permissions for global sieve scripts

[Richard via dovecot]

I did forget to mention both shell scripts have rwx, rwx, - permissions. manually 
executing rspamc does result in a "IO read error: unexpected EOF". So yet 
another issue to add to the list I guess...


Richard

On 16.09.24 09:07, Aki Tuomi wrote:

Did you remember to set +x on the rspamd-learn-spam.sh script?

Does it work if you invoke it by hand?

Aki

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Correct permissions for global sieve scripts

[Richard via dovecot]

Good question. There isn't any entry in journal, the only additional message I 
get is from dovecot


Sep 15 13:01:00 dovecot[523226]: imap(rrosner)<823661><4+8RXyYi2L9/AAAB>: 
program exec:/etc/dovecot/sieve/global/rspamd-learn-spam.sh (823662): Terminated with 
non-zero exit code 1


right before the other error messages. But it's not impossible that rspamc 
doesn't successfully execute, as rspamd currently has some weird issues where I 
have to wait for the developer to respond.

On 15.09.24 23:05, Tom Hendrikx via dovecot wrote:

Does the rspamc program log any errors? Is actually executed?


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Mail Backup from IMAP to POP3

[Vladislav Kurz via dovecot]

Dne 16. 09. 24 v 4:54 Reprobus via dovecot napsal(a):
Hi, I'm in a situation whereas I need to backup my email from an IMAP 
server to a POP3 email client of my choosing. I'm hoping Dovecot can do 
such a task and is there a container to which I can run to set this up 
from ?


My IMAP email server is maxed and I need to dump all the emails off the 
IMAP to POP3 as to clear it up.


How about just moving the emails to the local folders of your favourite 
mail client?


--
Best Regards
Vladislav Kurz
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Correct permissions for global sieve scripts

[Sirius via dovecot]

On sön, 2024/09/15 at 14:30:19 +0200, Richard via dovecot wrote:
> I've set up dovecot via global sieve scripts to send mails that a user
> manually moved to their junk directory to rspamd to learn them as spam
> (and learn messages as ham if they are moved out of it). I thought I had
> it all properly set up, but I'm now again seeing log messages like this:

root@debian:~# dpkg -l | egrep '^ii.*(rspam|dovecot-core)'
ii  dovecot-core 1:2.3.21.1+dfsg1-1~bpo12+1  
amd64secure POP3/IMAP server - core files
ii  rspamd   3.4-1   
amd64Rapid spam filtering system

I do the same as you.

> Sep 15 13:01:00 dovecot[523226]:
> imap(username)<823661><4+8RXyYi2L9/AAAB>: Error: sieve: failed to
> execute to program `rspamd-learn-spam.sh': refer to server log for more
> information. [2024-09-15 13:01:00] Sep 15 13:01:00 dovecot[523226]:
> imap(username)<823661><4+8RXyYi2L9/AAAB>: Error: sieve: Execution of
> script /etc/dovecot/sieve/global/learn-spam.sieve failed
> 
> 
> The content of learn-spam.sieve is this:
> 
> 
> require ["vnd.dovecot.pipe", "copy", "imapsieve"]; pipe :copy
> "rspamd-learn-spam.sh";
> 
> 
> And the content of rspamd-learn-spam.sh is this:
> 
> 
> #!/bin/sh exec /usr/bin/rspamc learn_spam
> 
> 
> All the necessary files are located in /etc/dovecot/sieve/global and are
> owned by dovecot:dovecot with rw, r, r permissions. Also, I have
> compiled the .sieve files with sievec, the resulting .svbin files have
> the same permissions and ownership. What am I doing wrong? I don't see
> any further "server log" that will tell me more information.
> 
> 
> I'm using dovecot 2.3.19.1 (9b53102964) on Debian 12.7

root@debian:~# ls -l /etc/dovecot/sieve
total 32
-rw-r- 1 vmail dovecot  188 Sep  4 13:41 global-spam.sieve
-rw-r- 1 vmail vmail330 Sep  4 14:01 global-spam.svbin
-rwxr-x--- 2 vmail dovecot 2579 Sep  4 13:44 learn-ham.rspamd.script
-rw-r- 1 vmail dovecot  256 Sep  4 13:42 learn-ham.sieve
-rw-r- 1 vmail dovecot  442 Sep  5 03:55 learn-ham.svbin
-rwxr-x--- 2 vmail dovecot 2579 Sep  4 13:44 learn-spam.rspamd.script
-rw-r- 1 vmail dovecot  151 Sep  4 13:43 learn-spam.sieve
-rw-r- 1 vmail dovecot  341 Sep  5 03:56 learn-spam.svbin

The scripts need to be executable.

I have this in the plugin {} section of dovecot.conf:

  # This will automatically move spam into Junk/ and when you move a message
  # into Junk, it will tell rspamd that it is spam for Bayes learning. Moving
  # false positives out of Junk/ will teach rspamd that it is ham.
  sieve_plugins = sieve_imapsieve sieve_extprograms
  sieve_extensions = +editheader +imapflags +mboxmetadata +notify 
+servermetadata +spamtest +spamtestplus +virustest
  imapsieve_mailbox1_before = file:/etc/dovecot/sieve/learn-spam.sieve
  imapsieve_mailbox1_causes = COPY APPEND FLAG
  imapsieve_mailbox1_name = Junk
  imapsieve_mailbox2_before = file:/etc/dovecot/sieve/learn-ham.sieve
  imapsieve_mailbox2_causes = COPY APPEND FLAG
  imapsieve_mailbox2_from = Junk
  imapsieve_mailbox2_name = *
  sieve_pipe_bin_dir = /etc/dovecot/sieve
  sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.environment
  sieve_spamtest_status_type = score
  sieve_spamtest_status_header = X-Spam_score: (-?[[:digit:]]+\.[[:digit:]])
  sieve_spamtest_max_value = 6
  sieve_before = /etc/dovecot/sieve/global-spam.sieve

The only other thing was to get the password out of
/etc/rspamd/worker-controller.inc and put it in
/etc/dovecot/rspamd-controller.password (or whatever file your
learn-{sp,h}am script points at to get the password). It needed to be
pointed at 127.0.0.1:11334 for the socket.

root@debian:~# cat /etc/dovecot/rspamd-controller.conf.sh
# Path to file containing the controller password
# (Or, if it doesn't start with '/' or '.', the password itself.
# But it might leak the password through ps to other users)
RSPAMD_CONTROLLER_PASSWORD=/etc/dovecot/rspamd-controller.password
# passed to rspamc with the -h option (host and port)
RSPAMD_CONTROLLER_SOCKET=127.0.0.1:11334
# if set uses curl instead of rspamc; should start with http: or https:
RSPAMD_CONTROLLER_HOST=
# classifier to learn for (default by rspamc: bayes), e.g. `bayes_user`
RSPAMD_CLASSIFIER=bayes


>From what I remember, it was somewhat fiddly to get this working as I was
not intimately familiar with rspamd, nor dovecot or sieve, but this works
and it works well. Relatively low incident rate of false positives after a
some weeks.

-- 
Kind regards,

/S
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Correct permissions for global sieve scripts

[Aki Tuomi via dovecot]

> On 15/09/2024 15:30 EEST Richard via dovecot  wrote:
> 
>  
> Hi there,
> 
> I've set up dovecot via global sieve scripts to send mails that a user 
> manually moved to their junk directory to rspamd to learn them as spam (and 
> learn messages as ham if they are moved out of it). I thought I had it all 
> properly set up, but I'm now again seeing log messages like this:
> 
> 
> Sep 15 13:01:00 dovecot[523226]: imap(username)<823661><4+8RXyYi2L9/AAAB>: 
> Error: sieve: failed to execute to program `rspamd-learn-spam.sh': refer to 
> server log for more information. [2024-09-15 13:01:00]
> Sep 15 13:01:00 dovecot[523226]: imap(username)<823661><4+8RXyYi2L9/AAAB>: 
> Error: sieve: Execution of script /etc/dovecot/sieve/global/learn-spam.sieve 
> failed
> 
> 
> The content of learn-spam.sieve is this:
> 
> 
> require ["vnd.dovecot.pipe", "copy", "imapsieve"];
> pipe :copy "rspamd-learn-spam.sh";
> 
> 
> And the content of rspamd-learn-spam.sh is this:
> 
> 
> #!/bin/sh
> exec /usr/bin/rspamc learn_spam
> 
> 
> All the necessary files are located in /etc/dovecot/sieve/global and are 
> owned by dovecot:dovecot with rw, r, r permissions. Also, I have compiled the 
> .sieve files with sievec, the resulting .svbin files have the same 
> permissions and ownership. What am I doing wrong? I don't see any further 
> "server log" that will tell me more information.
> 
> 
> I'm using dovecot 2.3.19.1 (9b53102964) on Debian 12.7
> 
> 
> Best
> 
> Richard
> 

Did you remember to set +x on the rspamd-learn-spam.sh script?

Does it work if you invoke it by hand?

Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Allowing parallel read-only requests via doveadm http api

[Aki Tuomi via dovecot]

> On 09/09/2024 18:47 EEST Kevin Kelker via dovecot  wrote:
> 
>  
> Hi,
> 
> 
> is there any chance to open the doveadm http api to handle more than one 
> client at a time if the requests are read-only commands that have
> no risk of breaking something when they run simultaneously?
> We have a scenario of using it only for getQuota to visualize a live-status 
> of the mailbox usage but every once in a while, there are more than one
> parallel requests for that that are then getting tcp connection resets.
> As far as I've seen it in 
> https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/PYMMJDGODLRD73CQDGLLREW57JRMMJNT/
> spawning another doveadm http api service with another port wouldn't do the 
> trick.
> 
> If that's not possible, wouldn't be a failure code as a response a more clean 
> approach than just refusing the connection at all?
> Right now, it's getting logged on the dovecot backend as "doveadm server can 
> handle only a single client" but the requesting client gets
> a connection reset instead of a json-type response with a failure code.
> 
> 
> Best
> 
> Kevin

You can have it handle more clients by launching multiple processes. Having 
same process handle multiple clients will just not work.

Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Mail Backup from IMAP to POP3

[basti via dovecot]

Am 16.09.24 um 04:54 schrieb Reprobus via dovecot:
Hi, I'm in a situation whereas I need to backup my email from an IMAP 
server to a POP3 email client of my choosing. I'm hoping Dovecot can do 
such a task and is there a container to which I can run to set this up 
from ?


My IMAP email server is maxed and I need to dump all the emails off the 
IMAP to POP3 as to clear it up.


Thank You

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org


I use mpop (https://marlam.de/mpop/) to get the one POP3 Account I have.

Best Reagrds,
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Mail Backup from IMAP to POP3

[Ralph Seichter via dovecot]

* Reprobus via dovecot:

> I'm in a situation whereas I need to backup my email from an IMAP
> server to a POP3 email client of my choosing.

Since ancient times (cough), people have been using Fetchmail [1] for
related tasks. The author may be considered a controversial figure, but
that does not take anything away from the software itself.

[1] https://www.fetchmail.info/

-Ralph
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Correct permissions for global sieve scripts

[Tom Hendrikx via dovecot]

On 15-09-2024 14:30, Richard via dovecot wrote:

Hi there,

I've set up dovecot via global sieve scripts to send mails that a user 
manually moved to their junk directory to rspamd to learn them as spam 
(and learn messages as ham if they are moved out of it). I thought I had 
it all properly set up, but I'm now again seeing log messages like this:



Sep 15 13:01:00 dovecot[523226]: 
imap(username)<823661><4+8RXyYi2L9/AAAB>: Error: sieve: failed to 
execute to program `rspamd-learn-spam.sh': refer to server log for more 
information. [2024-09-15 13:01:00]
Sep 15 13:01:00 dovecot[523226]: 
imap(username)<823661><4+8RXyYi2L9/AAAB>: Error: sieve: Execution of 
script /etc/dovecot/sieve/global/learn-spam.sieve failed



The content of learn-spam.sieve is this:


require ["vnd.dovecot.pipe", "copy", "imapsieve"];
pipe :copy "rspamd-learn-spam.sh";


And the content of rspamd-learn-spam.sh is this:


#!/bin/sh
exec /usr/bin/rspamc learn_spam




Does the rspamc program log any errors? Is actually executed?


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Selectively query folders for new emails

[Oscar del Rio via dovecot]

On 2024-09-11 4:29 p.m., Christian Eichert via dovecot wrote:


I want to know how I can exclude folders from being selected from 
query by the client.




I've never tried it, but you can check with hidden or unlisted namespaces
https://doc.dovecot.org/2.3/configuration_manual/namespace/

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Selectively query folders for new emails

[Christian Eichert via dovecot]

Thank you very much,

But I noticed that for example some types Folders are not offered to 
select for query.
I want to know how I can exclude folders from being selected from query 
by the client.


Am 2024-09-11 um 18:45 schrieb Oscar del Rio via dovecot:

On 2024-09-10 7:34 p.m., Habakuk Tibatong via dovecot wrote:

- Is it possible to exclude folders from being queried for new emails?


That is a mail client setting. For Thunderbird, check Account Settings 
- Synchronization & Storage.


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Selectively query folders for new emails

[Oscar del Rio via dovecot]

On 2024-09-10 7:34 p.m., Habakuk Tibatong via dovecot wrote:

- Is it possible to exclude folders from being queried for new emails?


That is a mail client setting. For Thunderbird, check Account Settings - 
Synchronization & Storage.


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

RE: Dovecot v2.3.21.1 released

[Marc via dovecot]

> >> Tests failing when attempting to build for both EL8 and 9:
> >
> > When is 2.4 for el9 expected?
> 
> GhettoForge will release it after the general availablility of 2.4.
> Others from Dovecot have stated that it will be available directly from
> the dovecot ce repos once 2.4 is released.
> 

But there is nothing like a date known yet?
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Dovecot v2.3.21.1 released

[Timo Sirainen via dovecot]

On 2. Sep 2024, at 15.44, Guilhem Moulin via dovecot  
wrote:
> 
> Hi Aki,
> 
>> we are releasing a CVE patch release 2.3.21.1.
> 
> Your message to the oss-security list [0] says both 2.2 and 2.3 versions
> are vulnerable to CVE-2024-23184.  Using the following test message as
> reproducer
> 
>From: f...@example.net
>To: b...@example.net
>  , b...@example.net
>  […]
>  , bar$n...@example.net
>Bcc: b...@example.net
>[…]
>Bcc: baz$n...@example.net
>Date: $(LC_TIME=C.UTF-8 date -R)
>Subject: boom
>Message-Id: $(cat /proc/sys/kernel/random/uuid)@example.net
> 
>boom
> 
> I could reproduce the issue back to 2.3.10 but not with earlier
> versions.  I used `doveadm fetch imap.envelope all` to measure the
> (non-cached) IMAP ENVELOPE command.
> 
> For n=100k, it takes ~20s with 2.3.19 vs. ~0.5s with early 2.3.x and
> 2.2.x.  For n=500k, I measured ~2s with early 2.3.x and 2.2.x, so for
> these versions it doesn't look like parsing is O(n²) in the number of
> addresses.
> 
> I didn't try to bisect to pinpoint the exact commit, but AFAICT the main
> problem you described
> 
> | each header line's address is added to the end of a linked list. This
> | is done by walking the whole linked list, which becomes more inefficient
> | the more addresses there are.
> 
> was introduced in 2.3.10 by
> https://github.com/dovecot/core/commit/469fcd3bdd7df40bb8f4d131121f3bfbceade02a
>  .
> 
> Is my reproducer/analysis incorrect, or are versions before 2.3.10
> immune to CVE-2024-23184?  (AFAICT they are affected by CVE-2024-23185;
> only talking about -23184 here.)

Yes, looks like this is all correct. I guess we didn't really verify the oldest 
version this affects.

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Dovecot v2.3.21.1 released

[Peter via dovecot]

On 7/09/24 00:55, Marc via dovecot wrote:

On 14/08/24 23:25, Aki Tuomi via dovecot wrote:

Hi all,

we are releasing a CVE patch release 2.3.21.1.

https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz
https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz.sig
Binary packages in https://repo.dovecot.org/
Docker images in https://hub.docker.com/r/dovecot/dovecot


Tests failing when attempting to build for both EL8 and 9:


When is 2.4 for el9 expected?


GhettoForge will release it after the general availablility of 2.4. 
Others from Dovecot have stated that it will be available directly from 
the dovecot ce repos once 2.4 is released.



Peter
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

RE: Dovecot v2.3.21.1 released

[Marc via dovecot]

> On 14/08/24 23:25, Aki Tuomi via dovecot wrote:
> > Hi all,
> >
> > we are releasing a CVE patch release 2.3.21.1.
> >
> > https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz
> > https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz.sig
> > Binary packages in https://repo.dovecot.org/
> > Docker images in https://hub.docker.com/r/dovecot/dovecot
> 
> Tests failing when attempting to build for both EL8 and 9:
> 

When is 2.4 for el9 expected?
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Dovecot v2.3.21.1 released

[Peter via dovecot]

On 14/08/24 23:25, Aki Tuomi via dovecot wrote:

Hi all,

we are releasing a CVE patch release 2.3.21.1.

https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz
https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz.sig
Binary packages in https://repo.dovecot.org/
Docker images in https://hub.docker.com/r/dovecot/dovecot


Tests failing when attempting to build for both EL8 and 9:

test-failures.c:152: Assert failed: internal_line_match(line, 
long_log_prefix, TEXT128)
test-failures.c:152: Assert failed: internal_line_match(line, 
long_log_prefix, TEXT128)
test-failures.c:152: Assert failed: internal_line_match(line, 
long_log_prefix, TEXT128)


...this test did not fail in 2.3.21


Peter
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Dovecot v2.3.21.1 released

[Peter via dovecot]

On 15/08/24 00:07, Marc via dovecot via dovecot wrote:


we are releasing a CVE patch release 2.3.21.1.

https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz
https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz.sig
Binary packages in https://repo.dovecot.org/
Docker images in https://hub.docker.com/r/dovecot/dovecot


I know about these issues with openssl 3 and if I remember correctly this is 
solved in 2.4. But when do you expect packages for el9 to be available?


El9 packages are in GhettoForge:
http://ghettoforge.org/

2.3.21.1 is being built now and will hopefully be released in a couple 
of hours.



Peter
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Dovecot v2.3.21.1 released

[Guilhem Moulin via dovecot]

Hi Aki,

> we are releasing a CVE patch release 2.3.21.1.

Your message to the oss-security list [0] says both 2.2 and 2.3 versions
are vulnerable to CVE-2024-23184.  Using the following test message as
reproducer

From: f...@example.net
To: b...@example.net
  , b...@example.net
  […]
  , bar$n...@example.net
Bcc: b...@example.net
[…]
Bcc: baz$n...@example.net
Date: $(LC_TIME=C.UTF-8 date -R)
Subject: boom
Message-Id: $(cat /proc/sys/kernel/random/uuid)@example.net

boom

I could reproduce the issue back to 2.3.10 but not with earlier
versions.  I used `doveadm fetch imap.envelope all` to measure the
(non-cached) IMAP ENVELOPE command.

For n=100k, it takes ~20s with 2.3.19 vs. ~0.5s with early 2.3.x and
2.2.x.  For n=500k, I measured ~2s with early 2.3.x and 2.2.x, so for
these versions it doesn't look like parsing is O(n²) in the number of
addresses.

I didn't try to bisect to pinpoint the exact commit, but AFAICT the main
problem you described

| each header line's address is added to the end of a linked list. This
| is done by walking the whole linked list, which becomes more inefficient
| the more addresses there are.

was introduced in 2.3.10 by
https://github.com/dovecot/core/commit/469fcd3bdd7df40bb8f4d131121f3bfbceade02a 
.

Is my reproducer/analysis incorrect, or are versions before 2.3.10
immune to CVE-2024-23184?  (AFAICT they are affected by CVE-2024-23185;
only talking about -23184 here.)

Thanks,
-- 
Guilhem.

https://www.openwall.com/lists/oss-security/2024/08/15/3
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Frequency Control for IMAP connection

[Wesley via dovecot via dovecot]

On 2024-08-16 08:26, Joseph Tam via dovecot wrote:

> 
> Is this a MacOSX client?  

No, that client is using the programming method to access us.
But he should use imap IDLE function rather than a crazy loop.


> You might have to resort to firewall or other general network controls
> to actually rate limit
> connections.
> 

I have communicated with the customer to improve their imap connections.
before that I just drop their connections by iptables.

Thanks.

-- 
https://wespeng.pages.dev/
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
.-- Mail processed by antivirus 
-->
| Known viruses: 8697350
| Engine version: 1.0.5
| Scanned directories: 0
| Scanned files: 1
| Infected files: 0
| Data scanned: 0.01 MB
| Data read: 0.01 MB (ratio 1.00:1)
| Time: 34.340 sec (0 m 34 s)
| Start Date: 2024:08:16 11:16:30
| End Date:   2024:08:16 11:17:04
| SPAM hints: []
| SPAM hints: []
| Message not from DMARC.
'-- Paxsudos IT / Security Screening 
-->

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Dovecot authentication hangs when ldap_start_tls_s() fails for invalid certificate

[sebastiano.degan--- via dovecot]

Hi!
I've tried again ad at this moment the only way to avoid this issue is to add 
"tls_require_cert = allow" to either passdb or userdb config.
It still hangs otherwise.

Now I'm running on debian 12 and dovecot 2.3.19.1 (9b53102964).
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: What are all the /var/spool/smtpd/offline/1689525601.XXXXlJ85yQ

[Steve Litt via dovecot]

Cristiano Deana via dovecot said on Mon, 2 Sep 2024 17:23:07 +0200

>Hi,
>
>first, you should ask to opensmptd's ML, this is not a dovecot related 
>issue.

I didn't know that. Thanks,

>What opensmtpd version? what OS?

I didn't know I was using opensmtpd, but to answer your question,
version opensmtpd-7.5.0p0_1 on Void Linux.  

>
>Take a look here:
>https://github.com/OpenSMTPD/OpenSMTPD/issues/1012

Thanks!

I thought /var/spool/smtpd belonged to Dovecot, and never knew about
the smtpd package, which was pulled in by procmail.

Thanks everyone, and sorry for the misdirection.

SteveT

Steve Litt 

http://444domains.com
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: What are all the /var/spool/smtpd/offline/1689525601.XXXXlJ85yQ

[Cristiano Deana via dovecot]

Hi,

first, you should ask to opensmptd's ML, this is not a dovecot related 
issue.

What opensmtpd version? what OS?

Take a look here:
https://github.com/OpenSMTPD/OpenSMTPD/issues/1012

Il 31/08/2024 16:02, Steve Litt via dovecot ha scritto:

Hi all,

I just filled up my whole /var with zillions of files
/var/spool/smtpd/offline , dating back to 2018. What are these files
and is it safe for me to delete the ones more than a week old?

Thanks,

SteveT

Steve Litt
http://444domains.com
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org


--

###
# Cristiano Deana #
# #
# Senior Network Engineer #
# Digital Response Team #
# CittaStudi S.p.a. #
# off. +39 015 855 1172 #
# cell +39 328 310 6392 #
###
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Inconsistency in map index with dovecot v2.3.21

[Nikolaos Pyrgiotis via dovecot]

Hello Timo,

We had been running version 2.3.20 previously, not 2.3.19. We will upgrade to 
version 2.3.22 when it is out and monitor if these errors stop.

Thank you,
Nikos
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: What are all the /var/spool/smtpd/offline/1689525601.XXXXlJ85yQ [SOLVED]

[Rob Sterenborg (Lists) via dovecot]

On 2024-09-02 05:59, Steve Litt via dovecot wrote:

I stopped Dovecot, backed up the tens of thousands of files in
/var/spool/smtpd/offline/, then deleted them, then started Dovecot
again. Everything runs fine, so I guess those files weren't important,
at least not to Dovecot.

I also found the major problem consuming so much /var space was Void
Linux' package cache files, so I deleted all of those more than 3
months old. Soon I'll make a daemon or a cron job that deletes old
files in these two directories, and probably a lot more.


I'm not an expert on Dovecot, but I've run it for quite a number of 
years, and cannot remember having seen that directory on any of my 
installations.


So I guessed the easiest way to find out about it, is to Google for 
"/var/spool/smtpd" (including quotes).  The results seem to indicate 
that the directory is related to OpenSMTPD.  E.g.:


https://manpages.debian.org/stretch/opensmtpd/smtpd.conf.5.en.html

FILES
[...]
/var/spool/smtpd/
Spool directories for mail during processing.

So if you have OpenSMTPD installed, you probably deleted spool files 
from undeliverable email (or so; I'm unfamiliar with OpenSMTPD).  Maybe 
you should check what is in those files (Postfix queue files are 
readable when using `postcat`, maybe OpenSMTPD spool files are also 
readable).



--
Rob

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: What are all the /var/spool/smtpd/offline/1689525601.XXXXlJ85yQ [SOLVED]

[Steve Litt via dovecot]

I stopped Dovecot, backed up the tens of thousands of files in
/var/spool/smtpd/offline/, then deleted them, then started Dovecot
again. Everything runs fine, so I guess those files weren't important,
at least not to Dovecot.

I also found the major problem consuming so much /var space was Void
Linux' package cache files, so I deleted all of those more than 3
months old. Soon I'll make a daemon or a cron job that deletes old
files in these two directories, and probably a lot more.

Thanks,

SteveT
Steve Litt 
http://444domains.com


Steve Litt via dovecot said on Sat, 31 Aug 2024 10:49:04 -0400

>OK, but will it hurt to delete the ones older than a week? A month? A
>year?
>
>SteveT
>
>Marc via dovecot said on Sat, 31 Aug 2024 14:40:02 +
>
>>start to worry when it is quattuordecillions
>>  
>>> 
>>> I just filled up my whole /var with zillions of files
>>> /var/spool/smtpd/offline , dating back to 2018. What are these files
>>> and is it safe for me to delete the ones more than a week old?
>>> 
>>___
>>dovecot mailing list -- dovecot@dovecot.org
>>To unsubscribe send an email to dovecot-le...@dovecot.org  
>___
>dovecot mailing list -- dovecot@dovecot.org
>To unsubscribe send an email to dovecot-le...@dovecot.org

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: What are all the /var/spool/smtpd/offline/1689525601.XXXXlJ85yQ

[Dawn Ryder via dovecot]

> OK, but will it hurt to delete the ones older than a week? A month? A
> year?

Based on the path alone, these files seem to be related to offline mail
held by some MUA or other. Possibly keeping track of which messages were
copied from server to client. Have you considered removing some of the
oldest files and check the effects on your MUA?
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: maintainer-feedback requested: [Bug 280929] mail/dovecot move bogus warning "Time moved forwards" to debug

[Larry Rosenman via dovecot]

I've added the patch to the FreeBSD port pending an official release.

On Sun, Sep 1, 2024 at 11:36 AM Larry Rosenman  wrote:

> that sounds promising Michael.  @Timo Sirainen   any chance
> of a release with this included?
>
> On Sun, Sep 1, 2024 at 9:32 AM Michael Grimm via dovecot <
> dovecot@dovecot.org> wrote:
>
>> Timo Sirainen via dovecot  wrote:
>> >
>> > On 30. Aug 2024, at 19.00, dco2024--- via dovecot 
>> wrote:
>>
>> >> This is not limited to FreeBSD. I'm seeing it on Gentoo Linux. Kernel
>> is 6.6.47-gentoo-x86_64, dovecot 2.3.21.1 (d492236fa0). The warning is
>> logged once every 12-15 hours.
>> >>
>> >> Syslog:
>> >> 2024-08-24 18:03:49 UTC myhost dovecot: master: Warning: Time moved
>> forwards by 0.100068 seconds - adjusting timeouts.
>> >> 2024-08-25 06:18:49 UTC myhost dovecot: master: Warning: Time moved
>> forwards by 0.100063 seconds - adjusting timeouts.
>> >> [snip]
>> >> Chrony ntp keeps the time in sync and the time has been in sync to
>> within 30us of UTC for many days. I noticed that it reports that the
>> unadjusted system clock is about 2.31 ppm fast of UTC. Doing the math for
>> dovecot's 12 hour warning interval:
>> >>  12 hours * 3600 secs/hour * 2.3/100 = 0.0998 seconds.
>> >> Could it be that dovecot is effectively measuring intervals of the
>> uncorrected system clock time instead of the longer term adjusted time, and
>> it complains when the accumulated NTP adjustments sum to 0.1 seconds.
>> >
>> > I don't see how that would be possible. The check is using only just
>> generated timestamps, not anything from a long time ago.
>> >
>> > I wonder if this kind of a simple patch would be good enough of a fix:
>> >
>> > [snip]
>>
>> I did apply your patch to dovecot-2.3.21.1 on 14.1-STABLE FreeBSD.
>>
>> Now, after 24 hours, dovecot doesn't complain about "Time moved forwards"
>> any longer.
>>
>> Before, I had had between 10 and 250 complaints every day.
>>
>> HTH and regards,
>> Michael
>>
>>
>>
>> ___
>> dovecot mailing list -- dovecot@dovecot.org
>> To unsubscribe send an email to dovecot-le...@dovecot.org
>>
>
>
> --
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org
> US Mail: 13425 Ranch Road 620 N, Apt 718, Austin, TX 78717-1010
>


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org
US Mail: 13425 Ranch Road 620 N, Apt 718, Austin, TX 78717-1010
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: maintainer-feedback requested: [Bug 280929] mail/dovecot move bogus warning "Time moved forwards" to debug

[Larry Rosenman via dovecot]

that sounds promising Michael.  @Timo Sirainen   any chance of
a release with this included?

On Sun, Sep 1, 2024 at 9:32 AM Michael Grimm via dovecot <
dovecot@dovecot.org> wrote:

> Timo Sirainen via dovecot  wrote:
> >
> > On 30. Aug 2024, at 19.00, dco2024--- via dovecot 
> wrote:
>
> >> This is not limited to FreeBSD. I'm seeing it on Gentoo Linux. Kernel
> is 6.6.47-gentoo-x86_64, dovecot 2.3.21.1 (d492236fa0). The warning is
> logged once every 12-15 hours.
> >>
> >> Syslog:
> >> 2024-08-24 18:03:49 UTC myhost dovecot: master: Warning: Time moved
> forwards by 0.100068 seconds - adjusting timeouts.
> >> 2024-08-25 06:18:49 UTC myhost dovecot: master: Warning: Time moved
> forwards by 0.100063 seconds - adjusting timeouts.
> >> [snip]
> >> Chrony ntp keeps the time in sync and the time has been in sync to
> within 30us of UTC for many days. I noticed that it reports that the
> unadjusted system clock is about 2.31 ppm fast of UTC. Doing the math for
> dovecot's 12 hour warning interval:
> >>  12 hours * 3600 secs/hour * 2.3/100 = 0.0998 seconds.
> >> Could it be that dovecot is effectively measuring intervals of the
> uncorrected system clock time instead of the longer term adjusted time, and
> it complains when the accumulated NTP adjustments sum to 0.1 seconds.
> >
> > I don't see how that would be possible. The check is using only just
> generated timestamps, not anything from a long time ago.
> >
> > I wonder if this kind of a simple patch would be good enough of a fix:
> >
> > [snip]
>
> I did apply your patch to dovecot-2.3.21.1 on 14.1-STABLE FreeBSD.
>
> Now, after 24 hours, dovecot doesn't complain about "Time moved forwards"
> any longer.
>
> Before, I had had between 10 and 250 complaints every day.
>
> HTH and regards,
> Michael
>
>
>
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org
>


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org
US Mail: 13425 Ranch Road 620 N, Apt 718, Austin, TX 78717-1010
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: maintainer-feedback requested: [Bug 280929] mail/dovecot move bogus warning "Time moved forwards" to debug

[Michael Grimm via dovecot]

Timo Sirainen via dovecot  wrote:
> 
> On 30. Aug 2024, at 19.00, dco2024--- via dovecot  wrote:

>> This is not limited to FreeBSD. I'm seeing it on Gentoo Linux. Kernel is 
>> 6.6.47-gentoo-x86_64, dovecot 2.3.21.1 (d492236fa0). The warning is logged 
>> once every 12-15 hours. 
>> 
>> Syslog:
>> 2024-08-24 18:03:49 UTC myhost dovecot: master: Warning: Time moved forwards 
>> by 0.100068 seconds - adjusting timeouts.
>> 2024-08-25 06:18:49 UTC myhost dovecot: master: Warning: Time moved forwards 
>> by 0.100063 seconds - adjusting timeouts.
>> [snip]
>> Chrony ntp keeps the time in sync and the time has been in sync to within 
>> 30us of UTC for many days. I noticed that it reports that the unadjusted 
>> system clock is about 2.31 ppm fast of UTC. Doing the math for dovecot's 12 
>> hour warning interval:
>>  12 hours * 3600 secs/hour * 2.3/100 = 0.0998 seconds.
>> Could it be that dovecot is effectively measuring intervals of the 
>> uncorrected system clock time instead of the longer term adjusted time, and 
>> it complains when the accumulated NTP adjustments sum to 0.1 seconds.
> 
> I don't see how that would be possible. The check is using only just 
> generated timestamps, not anything from a long time ago.
> 
> I wonder if this kind of a simple patch would be good enough of a fix:
> 
> [snip]

I did apply your patch to dovecot-2.3.21.1 on 14.1-STABLE FreeBSD.

Now, after 24 hours, dovecot doesn't complain about "Time moved forwards" any 
longer.

Before, I had had between 10 and 250 complaints every day.

HTH and regards,
Michael



___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

RE: What are all the /var/spool/smtpd/offline/1689525601.XXXXlJ85yQ

[Marc via dovecot]

start to worry when it is quattuordecillions

> 
> I just filled up my whole /var with zillions of files
> /var/spool/smtpd/offline , dating back to 2018. What are these files
> and is it safe for me to delete the ones more than a week old?
> 
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Debug: open(/proc/self/io) failed: Permission denied

[ljakku77--- via dovecot]

ok, so I can ignore it.. but I don't receive mails for some reason.. Here's my 
postfix config..

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 2
inet_interfaces = all
inet_protocols = ipv4
mailbox_size_limit = 0
mailbox_transport = lmtp:unix:private/dovecot-lmtp
message_size_limit = 204857600
milter_default_action = accept
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_type} 
{auth_authen}
milter_protocol = 2
mydestination =  localhost.localdomain localhost
mydomain = lja.fi
myhostname = mail.lja.fi
mynetworks = 127.0.0.0/8 192.168.1.0/24
myorigin = /etc/mailname
non_smtpd_milters = $smtpd_milters
recipient_delimiter = +
relayhost = 
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_ciphers = high
smtp_tls_security_level = encrypt
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_wrappermode = yes
smtp_use_tls = yes
smtpd_milters = inet:localhost:8895, inet:localhost:8892
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, 
reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /etc/letsencrypt/live/domain/chain.pem
smtpd_tls_cert_file = /etc/letsencrypt/live/domain/fullchain.pem
smtpd_tls_ciphers = high
smtpd_tls_key_file = /etc/letsencrypt/live/domain/privkey.pem
smtpd_tls_loglevel = 2
virtual_maps = hash:/etc/postfix/virtual
virtual_transport = lmtp:unix:private/dovecot-lmtp

.. could you please help me to get things working ? :)
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Debug: open(/proc/self/io) failed: Permission denied

[Aki Tuomi via dovecot]

If you mean the debug message, its just a debug message, not a problem.
 
If you need bytes_in/out metrics you can use
 
import_environment = $import_environment PR_SET_DUMPABLE=2
 
Aki
 On 31/08/2024 13:12 EEST ljakku77--- via dovecot
  wrote:
  
  
 Hi, I got same problem!
  
 # 2.3.21 (47349e2482): /etc/dovecot/dovecot.conf
 # Pigeonhole version 0.5.21 (f6cd4b8e)
 # OS: Linux 6.8.0-41-generic x86_64 Ubuntu 24.04.1 LTS
 auth_debug = yes
 auth_debug_passwords = yes
 auth_mechanisms = plain login
 auth_username_format = %Ln
 auth_verbose = yes
 auth_verbose_passwords = plain
 debug_log_path = /var/log/dovecot-debug.log
 info_log_path = /var/log/dovecot-info.log
 log_path = /var/log/dovecot.log
 mail_debug = yes
 mail_location = maildir:~/Maildir/
 mbox_write_locks = fcntl
 namespace inbox {
 inbox = yes
 location =
 mailbox Drafts {
 special_use = \Drafts
 }
 mailbox Junk {
 special_use = \Junk
 }
 mailbox Sent {
 special_use = \Sent
 }
 mailbox "Sent Messages" {
 special_use = \Sent
 }
 mailbox Trash {
 special_use = \Trash
 }
 prefix =
 }
 passdb {
 driver = pam
 }
 protocols = imap pop3 lmtp
 service auth {
 unix_listener /var/spool/postfix/private/auth {
 group = mail
 mode = 0660
 user = postfix
 }
 }
 service lmtp {
 unix_listener /var/spool/postfix/private/dovecot-lmtp {
 group = mail
 mode = 0660
 user = postfix
 }
 }
 ssl_cert = 

Re: Debug: open(/proc/self/io) failed: Permission denied

[ljakku77--- via dovecot]

Hi, I got same problem!

# 2.3.21 (47349e2482): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.21 (f6cd4b8e)
# OS: Linux 6.8.0-41-generic x86_64 Ubuntu 24.04.1 LTS 
auth_debug = yes
auth_debug_passwords = yes
auth_mechanisms = plain login
auth_username_format = %Ln
auth_verbose = yes
auth_verbose_passwords = plain
debug_log_path = /var/log/dovecot-debug.log
info_log_path = /var/log/dovecot-info.log
log_path = /var/log/dovecot.log
mail_debug = yes
mail_location = maildir:~/Maildir/
mbox_write_locks = fcntl
namespace inbox {
  inbox = yes
  location = 
  mailbox Drafts {
special_use = \Drafts
  }
  mailbox Junk {
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox "Sent Messages" {
special_use = \Sent
  }
  mailbox Trash {
special_use = \Trash
  }
  prefix = 
}
passdb {
  driver = pam
}
protocols = imap pop3 lmtp
service auth {
  unix_listener /var/spool/postfix/private/auth {
group = mail
mode = 0660
user = postfix
  }
}
service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = mail
mode = 0660
user = postfix
  }
}
ssl_cert = 

Re: maintainer-feedback requested: [Bug 280929] mail/dovecot move bogus warning "Time moved forwards" to debug

[Timo Sirainen via dovecot]

On 30. Aug 2024, at 19.00, dco2024--- via dovecot  wrote:
> 
> This is not limited to FreeBSD. I'm seeing it on Gentoo Linux. Kernel is 
> 6.6.47-gentoo-x86_64, dovecot 2.3.21.1 (d492236fa0). The warning is logged 
> once every 12-15 hours. 
> 
> Syslog:
> 2024-08-24 18:03:49 UTC myhost dovecot: master: Warning: Time moved forwards 
> by 0.100068 seconds - adjusting timeouts.
> 2024-08-25 06:18:49 UTC myhost dovecot: master: Warning: Time moved forwards 
> by 0.100063 seconds - adjusting timeouts.
> 2024-08-26 06:52:16 UTC myhost dovecot: master: Warning: Time moved forwards 
> by 0.100062 seconds - adjusting timeouts.
> 2024-08-26 18:57:54 UTC myhost dovecot: master: Warning: Time moved forwards 
> by 0.100068 seconds - adjusting timeouts.
> 2024-08-27 07:24:34 UTC myhost dovecot: master: Warning: Time moved forwards 
> by 0.100061 seconds - adjusting timeouts.
> 2024-08-27 19:38:48 UTC myhost dovecot: master: Warning: Time moved forwards 
> by 0.100060 seconds - adjusting timeouts.
> 2024-08-28 20:21:44 UTC myhost dovecot: master: Warning: Time moved forwards 
> by 0.100071 seconds - adjusting timeouts.
> 2024-08-29 08:41:44 UTC myhost dovecot: master: Warning: Time moved forwards 
> by 0.100070 seconds - adjusting timeouts.
> 2024-08-29 21:04:37 UTC myhost dovecot: master: Warning: Time moved forwards 
> by 0.100071 seconds - adjusting timeouts.
> 2024-08-30 09:30:36 UTC myhost dovecot: master: Warning: Time moved forwards 
> by 0.100066 seconds - adjusting timeouts.
> 
> Chrony ntp keeps the time in sync and the time has been in sync to within 
> 30us of UTC for many days. I noticed that it reports that the unadjusted 
> system clock is about 2.31 ppm fast of UTC. Doing the math for dovecot's 12 
> hour warning interval:
>   12 hours * 3600 secs/hour * 2.3/100 = 0.0998 seconds.
> Could it be that dovecot is effectively measuring intervals of the 
> uncorrected system clock time instead of the longer term adjusted time, and 
> it complains when the accumulated NTP adjustments sum to 0.1 seconds.

I don't see how that would be possible. The check is using only just generated 
timestamps, not anything from a long time ago.

I wonder if this kind of a simple patch would be good enough of a fix:

diff --git a/src/lib/ioloop.c b/src/lib/ioloop.c
index 98c2dc2bf4..a63f861330 100644
--- a/src/lib/ioloop.c
+++ b/src/lib/ioloop.c
@@ -18,6 +18,7 @@
Dovecot generally doesn't have very important short timeouts, so to avoid
logging many warnings about this, use a rather high value. */
 #define IOLOOP_TIME_MOVED_FORWARDS_MIN_USECS (10)
+#define IOLOOP_TIME_MOVED_FORWARDS_MIN_USECS_LARGE (100)
 
 time_t ioloop_time = 0;
 struct timeval ioloop_timeval;
@@ -654,9 +655,13 @@ static void io_loop_handle_timeouts_real(struct ioloop 
*ioloop)
/* the callback may have slept, so check the time again. */
i_gettimeofday(&ioloop_timeval);
} else {
+   int max_diff = diff_usecs < 
IOLOOP_TIME_MOVED_FORWARDS_MIN_USECS_LARGE ?
+   IOLOOP_TIME_MOVED_FORWARDS_MIN_USECS :
+   IOLOOP_TIME_MOVED_FORWARDS_MIN_USECS_LARGE;
+
diff_usecs = timeval_diff_usecs(&ioloop->next_max_time,
&ioloop_timeval);
-   if (unlikely(-diff_usecs >= 
IOLOOP_TIME_MOVED_FORWARDS_MIN_USECS)) {
+   if (unlikely(-diff_usecs >= max_diff)) {
io_loops_timeouts_update(-diff_usecs);
/* time moved forward */
ioloop->time_moved_callback(&ioloop->next_max_time,


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Inconsistency in map index with dovecot v2.3.21

[Timo Sirainen via dovecot]

On 30. Aug 2024, at 16.39, Nikolaos Pyrgiotis via dovecot  
wrote:
> 
> But is there a possible bug in dovecot 2.3.21 version linked with the mdbox 
> format that is causing the `inconsistency in map index` in the first place or 
> it is just a configuration error? Other users have also reported these error 
> messages on this older thread 
> https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/73CEPDRB7TWP6BJABZL6VBZZH66HQ6S6/#73CEPDRB7TWP6BJABZL6VBZZH66HQ6S6
>   .

What was the previous version you were running? 2.3.20? I don't think there are 
really much of any changes related to dbox or index file handling. We did do 
pretty large fixes to mdbox corruption handling, but looks like they're still 
waiting for v2.3.22 release. Maybe those would help with these inconsistency 
issues also, or at least fixing them.

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: maintainer-feedback requested: [Bug 280929] mail/dovecot move bogus warning "Time moved forwards" to debug

[dco2024--- via dovecot]

This is not limited to FreeBSD. I'm seeing it on Gentoo Linux. Kernel is 
6.6.47-gentoo-x86_64, dovecot 2.3.21.1 (d492236fa0). The warning is logged once 
every 12-15 hours. 

Syslog:
2024-08-24 18:03:49 UTC myhost dovecot: master: Warning: Time moved forwards by 
0.100068 seconds - adjusting timeouts.
2024-08-25 06:18:49 UTC myhost dovecot: master: Warning: Time moved forwards by 
0.100063 seconds - adjusting timeouts.
2024-08-26 06:52:16 UTC myhost dovecot: master: Warning: Time moved forwards by 
0.100062 seconds - adjusting timeouts.
2024-08-26 18:57:54 UTC myhost dovecot: master: Warning: Time moved forwards by 
0.100068 seconds - adjusting timeouts.
2024-08-27 07:24:34 UTC myhost dovecot: master: Warning: Time moved forwards by 
0.100061 seconds - adjusting timeouts.
2024-08-27 19:38:48 UTC myhost dovecot: master: Warning: Time moved forwards by 
0.100060 seconds - adjusting timeouts.
2024-08-28 20:21:44 UTC myhost dovecot: master: Warning: Time moved forwards by 
0.100071 seconds - adjusting timeouts.
2024-08-29 08:41:44 UTC myhost dovecot: master: Warning: Time moved forwards by 
0.100070 seconds - adjusting timeouts.
2024-08-29 21:04:37 UTC myhost dovecot: master: Warning: Time moved forwards by 
0.100071 seconds - adjusting timeouts.
2024-08-30 09:30:36 UTC myhost dovecot: master: Warning: Time moved forwards by 
0.100066 seconds - adjusting timeouts.

Chrony ntp keeps the time in sync and the time has been in sync to within 30us 
of UTC for many days. I noticed that it reports that the unadjusted system 
clock is about 2.31 ppm fast of UTC. Doing the math for dovecot's 12 hour 
warning interval:
   12 hours * 3600 secs/hour * 2.3/100 = 0.0998 seconds.
Could it be that dovecot is effectively measuring intervals of the uncorrected 
system clock time instead of the longer term adjusted time, and it complains 
when the accumulated NTP adjustments sum to 0.1 seconds.
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Inconsistency in map index with dovecot v2.3.21

[Nikolaos Pyrgiotis via dovecot]

Thank you for your recommendation. We will try to increase the vsz_limit for 
these services and see if it helps to mitigate the issue.

But is there a possible bug in dovecot 2.3.21 version linked with the mdbox 
format that is causing the `inconsistency in map index` in the first place or 
it is just a configuration error? Other users have also reported these error 
messages on this older thread 
https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/73CEPDRB7TWP6BJABZL6VBZZH66HQ6S6/#73CEPDRB7TWP6BJABZL6VBZZH66HQ6S6
  .

Is there anything i can do to assist in identifying the cause of these errors?

Thank you,
Nikos Pyrgiotis
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Inconsistency in map index with dovecot v2.3.21

[Aki Tuomi via dovecot]

> On 30/08/2024 16:11 EEST Nikolaos Pyrgiotis via dovecot  
> wrote:
> 
>  
> We are using the Shared Mailboxes in Dovecot Cluster architecture so the 
> user`s mailbox should only be accessed by a single backend. We have been 
> running with this architecture for about 2  years with dovecot version 2.3.19 
> and we had not seen any `Inconsistency in map index` messages in the logs.
> 
> We had already increased the default vsize_limit to 512M for the lmtp process 
> but maybe we have to increase it more if this error will be occurring 
> repeatedly.
> This is the relevant configuration stanza for the lmtp service for all 
> backends.
> service lmtp {
>   unix_listener lmtp {
> mode = 0666
>   }
> 
>   inet_listener lmtp-mod {
> port = 24
> ssl = no
> }
>   service_count = 0
> 
>   # Number of processes to always keep waiting for more connections.
>   process_min_avail = 0
>   process_limit = 0
> 
>   # If you set service_count=0, you probably need to grow this.
>   vsz_limit = 512M
>   client_limit = 1
> }
> But the question is what causes this inconsistency and if there is any change 
> on 2.3.21 version that might have introduced it, because we did not get any  
> similar logs on previous versions.
> When this does occur is there a chance that a mailbox might get corrupted? Is 
> the only way to safely mitigate this to wait for the index rebuild to finish?
> 
> Thank you,
> Nikos Pyrgiotis

You can try running force-resync on the affected mailbox.

Also I would recommend upping the limit to 2G for lmtp, indexer, 
indexer-worker,lmtp etc. because otherwise user's index cache might not fit 
into memory.

Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Inconsistency in map index with dovecot v2.3.21

[Nikolaos Pyrgiotis via dovecot]

We are using the Shared Mailboxes in Dovecot Cluster architecture so the user`s 
mailbox should only be accessed by a single backend. We have been running with 
this architecture for about 2  years with dovecot version 2.3.19 and we had not 
seen any `Inconsistency in map index` messages in the logs.

We had already increased the default vsize_limit to 512M for the lmtp process 
but maybe we have to increase it more if this error will be occurring 
repeatedly.
This is the relevant configuration stanza for the lmtp service for all backends.
service lmtp {
  unix_listener lmtp {
mode = 0666
  }

  inet_listener lmtp-mod {
port = 24
ssl = no
}
  service_count = 0

  # Number of processes to always keep waiting for more connections.
  process_min_avail = 0
  process_limit = 0

  # If you set service_count=0, you probably need to grow this.
  vsz_limit = 512M
  client_limit = 1
}
But the question is what causes this inconsistency and if there is any change 
on 2.3.21 version that might have introduced it, because we did not get any  
similar logs on previous versions.
When this does occur is there a chance that a mailbox might get corrupted? Is 
the only way to safely mitigate this to wait for the index rebuild to finish?

Thank you,
Nikos Pyrgiotis
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Inconsistency in map index with dovecot v2.3.21

[Aki Tuomi via dovecot]

> On 30/08/2024 15:32 EEST Nikolaos Pyrgiotis via dovecot  
> wrote:
> 
>  
> Hello,
> 
> We have been running dovecot version 2.3.21 since July on debian 
> bookworm system. After upgrading we have seen in the logs similar 
> messages to the following:
> 
> 2024-08-29T19:33:27.755399+03:00 server1 dovecot: 
> lmtp(us...@modulus.gr)<481240><7TMeHNei0GYpeTkA1g8ogQ:P1>: Warning: 
> mdbox /path/user1/mdbox/storage: Inconsistency in map index (2213,40 != 
> 2213,56).
> 2024-08-29T19:33:27.755399+03:00 server1 dovecot: 
> lmtp(us...@modulus.gr)<481240><7TMeHNei0GYpeTkA1g8ogQ:P1>: Warning: 
> mdbox /path/user1/mdbox/storage: Inconsistency in map index (2213,40 != 
> 2213,56)
> 2024-08-29T19:33:27.838990+03:00 server1 dovecot: 
> lmtp(us...@modulus.gr)<481240><7TMeHNei0GYpeTkA1g8ogQ:P1>: sieve: 
> msgid=<39f9c444-0c08-4bda-bfc9-512c34584...@modulus.gr>: fileinto 
> action: stored mail into mailbox 'Replies'
> 2024-08-29T19:33:27.840222+03:00 server1 dovecot: 
> lmtp(us...@modulus.gr)<481240><7TMeHNei0GYpeTkA1g8ogQ:P1>: Warning: 
> fscking index file /path/user1/mdbox/storage/dovecot.map.index
> 2024-08-29T19:33:27.953281+03:00 server1 dovecot: 
> lmtp(us...@modulus.gr)<481240><7TMeHNei0GYpeTkA1g8ogQ:P1>: Warning: 
> mdbox /path/user1/mdbox/storage: rebuilding indexes
> 2024-08-29T19:37:27.989792+03:00 server1 dovecot: 
> lmtp(us...@modulus.gr)<481249>: Error: 
> Timeout (180s)while waiting for lock for transaction log file 
> /path/user1/mdbox/storage/dovecot.map.index.log (WRITE lock held by pid 
> 481240)
> 2024-08-29T19:37:27.995913+03:00 server1 dovecot: 
> lmtp(us...@modulus.gr)<481249>: Error: sieve: 
> msgid=<39f9c444-0c08-4bda-bfc9-512c34584...@modulus.gr>: fileinto 
> action: failed to store into mailbox 'Mailbox': Timeout (180s) while 
> waiting for lock for transaction log file 
> /path/user1/mdbox/storage/dovecot.map.index.log (WRITE lock held by pid 
> 481240)
> 
> 
> This has happened a few times since we upgraded always by a lmtp 
> process. It seems to be happening randomly and we have not been able to 
> reproduce it.
> 
> The mailboxes are stored in a glusterfs server, and we use the dovecot 
> director with shared mailboxes architecture.
> 
> Usually this was mitigated automatically by dovecot index rebuilding, 
> but last time it happened on a mailbox with a lot of giga byte of mail 
> data the following logs were produced for more than an hour:
> 
> 2024-08-29T19:45:30.506694+03:00 server1 dovecot: 
> lmtp(us...@modulus.gr)<481240><7TMeHNei0GYpeTkA1g8ogQ:P1>: Error: 
> mmap_anon(/path/user/mdbox/mailboxes/Mailbox/dbox-Mails/dovecot.index.cache, 
> 74076160) failed: Cannot allocate memory
> 
> During that period segfaults starting being generated for the imap 
> processes accessing that mailbox probably caused by timeouts from imap 
> processes attempting to fetch emails from the affected mailbox:
> 
> [3912187.557029] imap[481783]: segfault at 38 ip 7fb03248abf8 sp 
> 7ffc88b264f0 error 4 in 
> libdovecot-storage.so.0.0.0[7fb0323c7000+d8000] likely on CPU 6 (core 3, 
> socket 0)

Are you by chance accessing user's mailbox from multiple different servers, 
like delivering via LMTP on one, and user accessing on another?

Also you probably want to hike up the vsize_limit, the default 256M is usually 
too little for mail processses. mmap'd files are counted against this limit.

Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Connection closed (user disabled)

[Roberto J. Bolivar Plenge via dovecot]

I found out that it is a bug in Immunify360.  Thank you for trying to help
me.

 resp: '{ "action": "I360_BLOCKED", "message": "[IM360_RBL] The IP
179.x.x.x has been locked due to Imunify RBL" }

and the result was:

Aug 27 23:57:32 cp-cl02 dovecot[1301487]: pop3-login: Disconnected:
Connection closed (user disabled)

-
Sorcier Networking
Roberto J. Bolivar Plenge
Celular: +51-979662159



El sáb, 24 ago 2024 a la(s) 12:29 a.m., Aki Tuomi (
aki.tu...@open-xchange.com) escribió:

> Ok, maybe try
>
> auth_debug=yes
>
> restart dovecot
>
> and see what's in logs?
>
> Aki
>
> > On 24/08/2024 03:07 EEST Roberto J. Bolivar Plenge via dovecot <
> dovecot@dovecot.org> wrote:
> >
> >
> > I got this:
> >
> > [root@cp-cl02 dovecot]# doveadm auth lookup lol...@romaseguro.pe
> > passdb: lol...@romaseguro.pe
> >   user  : lol...@romaseguro.pe
> >
> > -
> > Sorcier Networking
> > Roberto J. Bolivar Plenge
> > Celular: +51-979662159
> >
> >
> >
> > El vie, 23 ago 2024 a la(s) 1:32 p.m., Aki Tuomi (
> aki.tu...@open-xchange.com)
> > escribió:
> >
> > > try
> > >
> > > doveadm auth lookup lol...@romaseguro.pe
> > >
> > > Aki
> > >
> > > > On 23/08/2024 21:10 EEST Roberto J. Bolivar Plenge via dovecot <
> > > dovecot@dovecot.org> wrote:
> > > >
> > > >
> > > > Hello everyone
> > > >
> > > > Thank you in advance for your help.
> > > >
> > > > Why do I get the following error:
> > > >
> > > > Aug 23 10:37:51 cp-cl02 dovecot[2337577]: pop3-login: Disconnected:
> > > > Connection closed (user disabled): user=,
> > > > method=PLAIN, rip=x.x.x.x, lip=x.x.x.x, TLS: Connection closed,
> > > > session=<8na4jlsg3HK1Q1LE>.
> > > >
> > > > I never observed this before:   Connection closed (user disabled):
> > > >
> > > > I wish to know what is causing it and how can I fix it.
> > > >
> > > > Thank you.
> > > > ___
> > > > dovecot mailing list -- dovecot@dovecot.org
> > > > To unsubscribe send an email to dovecot-le...@dovecot.org
> > >
> > ___
> > dovecot mailing list -- dovecot@dovecot.org
> > To unsubscribe send an email to dovecot-le...@dovecot.org
>
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Dovecot with LDAP and Solr: Force Solr user key

[Michele Giacomoli via dovecot]

Nevermind, I'll answer my own question.

I simply have to normalize the username attribute to user's ldap 
userPrincipalName in user_attrs setting. So the resulting configuration 
in becomes:


user_attrs  = 
=user=%{ldap:userPrincipalName},=home=/data/mail/%Ld/%Ln/Maildir/,=mail=maildir:/data/mail/%Ld/%Ln/Maildir/


It was that simple. I hope it helps someone in the future.

Best regards


Logo Mynet

*Michele Giacomoli*

Reparto IT

32.000 km di fibra ottica
nel nord Italia al servizio delle aziende

*www.mynet.it*  - *www.vogliadifibra.it* 



Il 27/08/24 13:33, Michele Giacomoli via dovecot ha scritto:

Good morning everyone.
I am configuring dovecot with ldap and solr as fts plugins.
The LDAP configuration works correctly and users can log in both via 
the userPrincipalName attribute and via mail.
In this configuration the LDAP realm and the email domain differ, and 
on the server the LDAP realm domain is privileged. This means that the 
mail dir is located in ./ldap_realm/username and in the same way 
postfix delivers the emails to dovecot using username@ldap_realm as 
envelope recipient. Consequently the emails are indexed on solr using 
"username@ldap_realm" as user key. However if I log in in imap using 
the email address as username and try to do some searches dovecot 
sends a select to solr using the email address as key and not the ldap 
user, and consequently I do not get any results from the search. So my 
question is: is it possible to configure dovecot to force queries to 
solr so that "username@ldap_realm" is always used as the key even when 
logging in via email?


Dovecot version is: 2.3.7.2

Solr version: 7.2.1

Ldap configuration:

[...]
user_filter = 
(&(|(userPrincipalName=%u)(mail=%u))(objectClass=person)(!(userAccountControl=514))(memberOf=cn=Mail,ou=Groups,dc=example,dc=org))
pass_filter = 
(&(|(userPrincipalName=%u)(mail=%u))(objectClass=person)(!(userAccountControl=514))(memberOf=cn=Mail,ou=Groups,dc=example,dc=org))

pass_attrs  = userPassword=password
user_attrs  = 
=home=/data/mail/%Ld/%Ln/Maildir/,=mail=maildir:/data/mail/%Ld/%Ln/Maildir/


Solr configuration:

plugin {
  fts = solr
  fts_solr = url=http://solr_host:8983/solr/dovecot/
  fts_autoindex=yes
}

Best regards


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: maintainer-feedback requested: [Bug 280929] mail/dovecot move bogus warning "Time moved forwards" to debug

[Timo Sirainen via dovecot]

On 24. Aug 2024, at 5.06, Jochen Bern via dovecot  wrote:
> 
> On 21.08.24 11:35, Timo Sirainen wrote:
>>> [Lots and lots of "but my NTP sync is much more precise than that" in
>>> the FreeBSD thread]
>> The way Dovecot works is:
>>  - It finds the next timeout, sees that it happens in e.g. 5 milliseconds.
>>  - Then it calls kqueue() to wait for I/O for max 5 milliseconds
>>  - Then it notices that it actually returned more than 105 milliseconds
>>later, and then logs a warning about it.
> 
> I think that more information is needed to pinpoint possible causes, and one 
> of the open questions is: What clock does dovecot look at to determine how 
> long it *actually* stayed dormant? On Linux, software that has need of a 
> monotonously increasing "time" to derive guaranteed unique IDs from often 
> looks at the kernel uptime - which is essentially a count of ticks since 
> bootup, and *not* being corrected by NTP.

Dovecot is doing simply gettimeofday() calls before and after epoll/kqueue/etc. 
It would be possible to use e.g. clock_gettime(CLOCK_MONOTONIC) to see whether 
there really was a time change, but this seems a bit excessive since Dovecot 
needs the real time in any case, so the current checks are "free", while doing 
calls to get monotonic time would only be useful to handle issues with time 
changes.

Another possibility would be to start using timerfd API when it's supported. 
Looks like it exists also in FreeBSD. This might be a good idea, although some 
parts of Dovecot can create/update a lot of timeouts, so I wonder how efficient 
it is to have syscalls updating the timers all the time. But I guess it would 
be fine.

> Similarly, it should be determined whether the timeouts of I/O function 
> called (i.e., kqueue()) are or aren't influenced by NTP's corrections to 
> system time.

I doubt clock changes affect those calls, since they ask to wait for N 
microseconds, not until a specific time.

>> Also, this is kind of a problem when it does happen. Since Dovecot
>> thinks the time moved e.g. 100ms forward, it adjusts all timeouts to
>> happen 100ms backwards. If this wasn't a true time jump, then these
>> timeouts now happen 100ms earlier.
> 
> That is, of course, a dangerous approach if you do *not* have a guarantee 
> that the timeouts of the I/O function called are *otherwise* true to the 
> requested duration. But shouldn't those other concurrently-running timeouts 
> notice an actual discontinuity of the timescale just the same as the first 
> one did? Maybe some sort of "N 'nay's needed for a vote of nonconfidence" 
> mechanism would be safer ...

There's only one timeout concurrently running per process. In theory the 
processes could talk to each other to find out whether there is such a time 
jump in more processes, but that would be very complicated.
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: maintainer-feedback requested: [Bug 280929] mail/dovecot move bogus warning "Time moved forwards" to debug

[Harlan Stenn via dovecot]

On 8/24/2024 12:13 PM, Jochen Bern via dovecot wrote:

On 24.08.24 05:04, Harlan Stenn wrote:

On 8/23/2024 7:06 PM, Jochen Bern via dovecot wrote:

(As an example for why this is relevant: Several hundred deviations of
100 ms or more per day sum up to several 10+ seconds per day, if only
they all are in the same direction, or several 115+ ppm.


Forward step or slew adjustments should be no problem.


Well, define "problem". The OP has a problem with the many log messages 
that *say* that the timescale slipped 100+ ms into the future (whether 
those actually happen to the system's *clock*, and if so, are triggered 
by the system's NTP sync, is unlikely-but-still-unclear IMHO), and Timo 
said that dovecot should then also try to counteract the offset for 
other still-running timeouts, which sounds like a problem waiting to 
happen *there* to me ...


I have no info/opinion about this specific situation.

I will say that I prefer:

- learning about problems "sooner" rather than "later"
- identifying and fixing problems at the "right" place
- - not too soon (often causes over-reach)
- - not too late (more expensive and leaves places where
there is still a problem)


ntpd refuses to do *slews* correcting by more than 500 ppm;


This is news to me.


H. I checked that and a couple ntpd manpages, while the more current 
versions blame the 500 ppm limit on Unix kernels, the older ones say that


You're talking about frequency adjustments, not phase adjustments. 
Stepping and slewing address phase issues.



The maximum slew rate possible is limited to 500 parts-per-million (PPM)
as a consequence of the correctness principles on which the NTP protocol
and algorithm design are based.


I remember that *some* limit - not necessarily 500 ppm, but that was the 
value chosen - was a *necessary* requirement for the proof, and that 
ntpd used to be a stickler for protocol and limits as written. Did the 
latter change ... ?


No.  But "choose your poison".

It takes over 30 minutes to slew a 1s correction.  By default, that 
correction will be applied at 500ppm.


(Anyway, I once had to sysadmin hardware that would flip-flop between 
IIRC -450 and +550 ppm from one bootup to the next, so I *am* perfectly 
sure that that was beyond the back-then ntpd's capabilities to adjust 
for. Its offset *kept growing* when they asked me to "fix its clock 
problem".)


That means your system clock was running at the wrong rate, and the boot 
code did a poor job of understanding the base clock frequency.


Dave Mills chose 500ppm as the limit for reasons including:

- a bound is required to make sure the algorithms will converge
  to correct time within a usefully bounded period of time
- by observation, the worst "useful" clocks kept time to within
  200ppm.  Since two "worst useful" clocks could have one running at
  250ppm fast and the other at 250ppm slow, the net result is a 500ppm
  range for the correction.

Many years' ago I wrote the 'calc_tickadj' program, which lives in 
ntp/scripts/calc_tickadj/ .  It is a major piece of what you want to do. 
 It will tell you how much your "tick" needs to be adjusted to get your 
system clock running the best it can.


Please note:

- that script aims to produce a tick value requiring the smallest 
possible *positive* ongoing slew adjustment.  If an ongoing negative 
slew adjustment is required and that is not given, the system clock will 
be running faster than "correct" time and any step correction to fix 
that will break ACID.


- the script was written before tickless kernels showed up.  I haven't 
looked at this case, and I would hope/expect there is a way to address 
this for a tickless kernel, too.


- if the system time is still horrible (for example, a VM that gets 
"stunned" a lot, or any other case where the flow of time is more 
random) this approach will not help much.



If what we offer does not satisfy your requirements, please let me know
and we'll find a way to improve things.


(Just to be perfectly clear here: No complaints from *me*. I'm firmly in 
the "hardware outside the ±100 ppm corridor is defective" camp.)


Kind regards,


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: maintainer-feedback requested: [Bug 280929] mail/dovecot move bogus warning "Time moved forwards" to debug

[Jochen Bern via dovecot]

On 24.08.24 05:04, Harlan Stenn wrote:

On 8/23/2024 7:06 PM, Jochen Bern via dovecot wrote:

(As an example for why this is relevant: Several hundred deviations of
100 ms or more per day sum up to several 10+ seconds per day, if only
they all are in the same direction, or several 115+ ppm.


Forward step or slew adjustments should be no problem.


Well, define "problem". The OP has a problem with the many log messages 
that *say* that the timescale slipped 100+ ms into the future (whether 
those actually happen to the system's *clock*, and if so, are triggered 
by the system's NTP sync, is unlikely-but-still-unclear IMHO), and Timo 
said that dovecot should then also try to counteract the offset for 
other still-running timeouts, which sounds like a problem waiting to 
happen *there* to me ...



ntpd refuses to do *slews* correcting by more than 500 ppm;


This is news to me.


H. I checked that and a couple ntpd manpages, while the more current 
versions blame the 500 ppm limit on Unix kernels, the older ones say that



The maximum slew rate possible is limited to 500 parts-per-million (PPM)
as a consequence of the correctness principles on which the NTP protocol
and algorithm design are based.


I remember that *some* limit - not necessarily 500 ppm, but that was the 
value chosen - was a *necessary* requirement for the proof, and that 
ntpd used to be a stickler for protocol and limits as written. Did the 
latter change ... ?


(Anyway, I once had to sysadmin hardware that would flip-flop between 
IIRC -450 and +550 ppm from one bootup to the next, so I *am* perfectly 
sure that that was beyond the back-then ntpd's capabilities to adjust 
for. Its offset *kept growing* when they asked me to "fix its clock 
problem".)



If what we offer does not satisfy your requirements, please let me know
and we'll find a way to improve things.


(Just to be perfectly clear here: No complaints from *me*. I'm firmly in 
the "hardware outside the ±100 ppm corridor is defective" camp.)


Kind regards,
--
Jochen Bern
Systemingenieur

Binect GmbH
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Connection closed (user disabled)

[Aki Tuomi via dovecot]

Ok, maybe try

auth_debug=yes

restart dovecot

and see what's in logs?

Aki

> On 24/08/2024 03:07 EEST Roberto J. Bolivar Plenge via dovecot 
>  wrote:
> 
>  
> I got this:
> 
> [root@cp-cl02 dovecot]# doveadm auth lookup lol...@romaseguro.pe
> passdb: lol...@romaseguro.pe
>   user  : lol...@romaseguro.pe
> 
> -
> Sorcier Networking
> Roberto J. Bolivar Plenge
> Celular: +51-979662159
> 
> 
> 
> El vie, 23 ago 2024 a la(s) 1:32 p.m., Aki Tuomi (aki.tu...@open-xchange.com)
> escribió:
> 
> > try
> >
> > doveadm auth lookup lol...@romaseguro.pe
> >
> > Aki
> >
> > > On 23/08/2024 21:10 EEST Roberto J. Bolivar Plenge via dovecot <
> > dovecot@dovecot.org> wrote:
> > >
> > >
> > > Hello everyone
> > >
> > > Thank you in advance for your help.
> > >
> > > Why do I get the following error:
> > >
> > > Aug 23 10:37:51 cp-cl02 dovecot[2337577]: pop3-login: Disconnected:
> > > Connection closed (user disabled): user=,
> > > method=PLAIN, rip=x.x.x.x, lip=x.x.x.x, TLS: Connection closed,
> > > session=<8na4jlsg3HK1Q1LE>.
> > >
> > > I never observed this before:   Connection closed (user disabled):
> > >
> > > I wish to know what is causing it and how can I fix it.
> > >
> > > Thank you.
> > > ___
> > > dovecot mailing list -- dovecot@dovecot.org
> > > To unsubscribe send an email to dovecot-le...@dovecot.org
> >
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: maintainer-feedback requested: [Bug 280929] mail/dovecot move bogus warning "Time moved forwards" to debug

[Harlan Stenn via dovecot]

I'm speaking as st...@ntp.org here, but I'm not subscribed to this list 
via that email address.


On 8/23/2024 7:06 PM, Jochen Bern via dovecot wrote:

On 21.08.24 11:35, Timo Sirainen wrote:

[Lots and lots of "but my NTP sync is much more precise than that" in
the FreeBSD thread]


The way Dovecot works is:
  - It finds the next timeout, sees that it happens in e.g. 5 
milliseconds.

  - Then it calls kqueue() to wait for I/O for max 5 milliseconds
  - Then it notices that it actually returned more than 105 milliseconds
    later, and then logs a warning about it.


I think that more information is needed to pinpoint possible causes, and 
one of the open questions is: What clock does dovecot look at to 
determine how long it *actually* stayed dormant? On Linux, software that 
has need of a monotonously increasing "time" to derive guaranteed unique 
IDs from often looks at the kernel uptime - which is essentially a count 
of ticks since bootup, and *not* being corrected by NTP.


Similarly, it should be determined whether the timeouts of I/O function 
called (i.e., kqueue()) are or aren't influenced by NTP's corrections to 
system time.


The third information I'd like to have is what client software provides 
that NTP sync to the machine; ntpd, chronyd, something else?


(As an example for why this is relevant: Several hundred deviations of 
100 ms or more per day sum up to several 10+ seconds per day, if only 
they all are in the same direction, or several 115+ ppm.


Forward step or slew adjustments should be no problem.

Backward adjustments must be slewed, to keep time monotonic.

ntpd refuses to 
do *slews* correcting by more than 500 ppm;


This is news to me.

See 
https://www.ntp.org/documentation/4.2.8-series/ntpd/#command-line-options 
for more information.


See the docs for -g and -x, for example.

Also see https://www.ntp.org/documentation/4.2.8-series/ntp.conf/ and 
the 'panic', 'step', and 'stepback' options.


If what we offer does not satisfy your requirements, please let me know 
and we'll find a way to improve things.


if the OS clock's frequency 
error exceeds that, ntpd would need to do *steps* every now and then, 
and in a default configuration, an ntpd will refuse to do a *second* 
step and *die* instead.



That is not ntpd's default behavior, but it does happen if the -g option 
is present.  I have ideas on how to address this, probably in the 
upcoming ntp-4.4 release.


Again, forward steps should not be a problem for dovecot, and backward 
adjustments can be forced to be slewed.


Or, if the reference clock sways *back and 
forth*, ntpd should very likely complain about its sources' jitter in 
the logs. chronyd, however, is more ruthless in whacking the local clock 
into "sync" with the external sources, and much more inclined to define 
"sync" as "low difference", rather than also taking frequency stability 
into account like ntpd.)


My understanding of what Miroslav told me is that chronyd picks a source 
of time and tracks it as best and quickly as it can, and at some point 
may pick a new source.


Ntpd identifies "correct time" as best it can, from a useful number of 
qualified sources.  It does this *well*, and ntpd will take its time to 
make sure this happens in a stable and predictable way.  Ntpd drives to 
"correct time", which may be in the "middle" of the set of qualified 
targets.



Also, this is kind of a problem when it does happen. Since Dovecot
thinks the time moved e.g. 100ms forward, it adjusts all timeouts to
happen 100ms backwards. If this wasn't a true time jump, then these
timeouts now happen 100ms earlier.


That is, of course, a dangerous approach if you do *not* have a 
guarantee that the timeouts of the I/O function called are *otherwise* 
true to the requested duration. But shouldn't those other concurrently- 
running timeouts notice an actual discontinuity of the timescale just 
the same as the first one did? Maybe some sort of "N 'nay's needed for a 
vote of nonconfidence" mechanism would be safer ...


Important stuff, and Difficult to do with current APIs.


Kind regards,


H
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: maintainer-feedback requested: [Bug 280929] mail/dovecot move bogus warning "Time moved forwards" to debug

[Jochen Bern via dovecot]

On 21.08.24 11:35, Timo Sirainen wrote:

[Lots and lots of "but my NTP sync is much more precise than that" in
the FreeBSD thread]


The way Dovecot works is:
  - It finds the next timeout, sees that it happens in e.g. 5 milliseconds.
  - Then it calls kqueue() to wait for I/O for max 5 milliseconds
  - Then it notices that it actually returned more than 105 milliseconds
later, and then logs a warning about it.


I think that more information is needed to pinpoint possible causes, and 
one of the open questions is: What clock does dovecot look at to 
determine how long it *actually* stayed dormant? On Linux, software that 
has need of a monotonously increasing "time" to derive guaranteed unique 
IDs from often looks at the kernel uptime - which is essentially a count 
of ticks since bootup, and *not* being corrected by NTP.


Similarly, it should be determined whether the timeouts of I/O function 
called (i.e., kqueue()) are or aren't influenced by NTP's corrections to 
system time.


The third information I'd like to have is what client software provides 
that NTP sync to the machine; ntpd, chronyd, something else?


(As an example for why this is relevant: Several hundred deviations of 
100 ms or more per day sum up to several 10+ seconds per day, if only 
they all are in the same direction, or several 115+ ppm. ntpd refuses to 
do *slews* correcting by more than 500 ppm; if the OS clock's frequency 
error exceeds that, ntpd would need to do *steps* every now and then, 
and in a default configuration, an ntpd will refuse to do a *second* 
step and *die* instead. Or, if the reference clock sways *back and 
forth*, ntpd should very likely complain about its sources' jitter in 
the logs. chronyd, however, is more ruthless in whacking the local clock 
into "sync" with the external sources, and much more inclined to define 
"sync" as "low difference", rather than also taking frequency stability 
into account like ntpd.)



Also, this is kind of a problem when it does happen. Since Dovecot
thinks the time moved e.g. 100ms forward, it adjusts all timeouts to
happen 100ms backwards. If this wasn't a true time jump, then these
timeouts now happen 100ms earlier.


That is, of course, a dangerous approach if you do *not* have a 
guarantee that the timeouts of the I/O function called are *otherwise* 
true to the requested duration. But shouldn't those other 
concurrently-running timeouts notice an actual discontinuity of the 
timescale just the same as the first one did? Maybe some sort of "N 
'nay's needed for a vote of nonconfidence" mechanism would be safer ...


Kind regards,
--
Jochen Bern
Systemingenieur

Binect GmbH
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Connection closed (user disabled)

[Roberto J. Bolivar Plenge via dovecot]

I got this:

[root@cp-cl02 dovecot]# doveadm auth lookup lol...@romaseguro.pe
passdb: lol...@romaseguro.pe
  user  : lol...@romaseguro.pe

-
Sorcier Networking
Roberto J. Bolivar Plenge
Celular: +51-979662159



El vie, 23 ago 2024 a la(s) 1:32 p.m., Aki Tuomi (aki.tu...@open-xchange.com)
escribió:

> try
>
> doveadm auth lookup lol...@romaseguro.pe
>
> Aki
>
> > On 23/08/2024 21:10 EEST Roberto J. Bolivar Plenge via dovecot <
> dovecot@dovecot.org> wrote:
> >
> >
> > Hello everyone
> >
> > Thank you in advance for your help.
> >
> > Why do I get the following error:
> >
> > Aug 23 10:37:51 cp-cl02 dovecot[2337577]: pop3-login: Disconnected:
> > Connection closed (user disabled): user=,
> > method=PLAIN, rip=x.x.x.x, lip=x.x.x.x, TLS: Connection closed,
> > session=<8na4jlsg3HK1Q1LE>.
> >
> > I never observed this before:   Connection closed (user disabled):
> >
> > I wish to know what is causing it and how can I fix it.
> >
> > Thank you.
> > ___
> > dovecot mailing list -- dovecot@dovecot.org
> > To unsubscribe send an email to dovecot-le...@dovecot.org
>
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Connection closed (user disabled)

[Aki Tuomi via dovecot]

try

doveadm auth lookup lol...@romaseguro.pe

Aki

> On 23/08/2024 21:10 EEST Roberto J. Bolivar Plenge via dovecot 
>  wrote:
> 
>  
> Hello everyone
> 
> Thank you in advance for your help.
> 
> Why do I get the following error:
> 
> Aug 23 10:37:51 cp-cl02 dovecot[2337577]: pop3-login: Disconnected:
> Connection closed (user disabled): user=,
> method=PLAIN, rip=x.x.x.x, lip=x.x.x.x, TLS: Connection closed,
> session=<8na4jlsg3HK1Q1LE>.
> 
> I never observed this before:   Connection closed (user disabled):
> 
> I wish to know what is causing it and how can I fix it.
> 
> Thank you.
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: 2.3.21(.1) build error on aarch64 (using slackware ARM -current)

[shawn.kubik--- via dovecot]

So, it turns out the problem is likely due to my hardware being old and 
unreliable. Upon encountering the same error message, I simply ran 'make' again 
to make it continue, and usually after a short period it was able to continue 
going, until it happened again. I just continued doing this until it finished 
building. I've since been able to install and run it and it seems to be working 
fine.
Sorry for bothering you with something so trivial. Thanks tho
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: maintainer-feedback requested: [Bug 280929] mail/dovecot move bogus warning "Time moved forwards" to debug

[Timo Sirainen via dovecot]

On 21. Aug 2024, at 12.35, Timo Sirainen  wrote:
> 
> The way Dovecot works is:
> - It finds the next timeout, sees that it happens in e.g. 5 milliseconds.
> - Then it calls kqueue() to wait for I/O for max 5 milliseconds
> - Then it notices that it actually returned more than 105 milliseconds later, 
> and then logs a warning about it.
> 
> So kqueue() apparently isn't very accurate in its timeout handling.

Actually another guess: Some people were saying it happens mainly on idle 
hours. Maybe kqueue() is accurate with low timeout values, but not accurate on 
high timeout values? So if Dovecot asked kqueue() to wait for <100ms, it would 
be very accurate. But if it asks to wait for 1ms, kqueue() would think it's 
okay to return after 10100ms. If that's the case, this check could be changed 
to allow higher time jumps only on higher timeout waits.

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: maintainer-feedback requested: [Bug 280929] mail/dovecot move bogus warning "Time moved forwards" to debug

[Timo Sirainen via dovecot]

The way Dovecot works is:
 - It finds the next timeout, sees that it happens in e.g. 5 milliseconds.
 - Then it calls kqueue() to wait for I/O for max 5 milliseconds
 - Then it notices that it actually returned more than 105 milliseconds later, 
and then logs a warning about it.

So kqueue() apparently isn't very accurate in its timeout handling.

With some googling I found 
https://lists.freebsd.org/pipermail/freebsd-arch/2012-March/012416.html which 
suggests this could happen at least if kern.hz is set to 20 or less. Could that 
be the case?

I guess we could increase IOLOOP_TIME_MOVED_FORWARDS_MIN_USECS higher than 100 
ms, but that might start hiding problems. Nowadays some people use rather short 
timeouts in e.g. some HTTP requests (auth, push-notifications). It could be 
difficult to understand why 100ms timeout happens only at 200ms without this 
warning message. Although if it happens only rarely, I guess it's not much of a 
problem.

Anyway, would be good to understand first why this happens in FreeBSD before 
growing the warning time.

Also, this is kind of a problem when it does happen. Since Dovecot thinks the 
time moved e.g. 100ms forward, it adjusts all timeouts to happen 100ms 
backwards. If this wasn't a true time jump, then these timeouts now happen 
100ms earlier. So e.g. a HTTP request with <100ms timeout can actually trigger 
an immediate timeout. Hiding the log message makes debugging this also more 
difficult. So I don't think it's a good solution to simply hide it or change it 
to debug level, as it may mask real problems.

> On 19. Aug 2024, at 19.11, Larry Rosenman via dovecot  
> wrote:
> 
> Comments from the dovecot community?
> 
> Aug 19, 2024 11:07:30 AM bugzilla-nore...@freebsd.org:
> 
> 
> Bugzilla Automation  has asked Larry Rosenman
>  for maintainer-feedback:
> Bug 280929: mail/dovecot move bogus warning "Time moved forwards" to debug
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280929
> 
> 
> 
> --- Description ---
> Dovecot complains about time moving forward, which seems to be due to a broken
> mechanism (on FreeBSD) used to measure timeouts. This warning spams the 
> maillog
> up to several hundred times per day.
> 
> There's an ongoing thread about this issue in the freebsd forums:
> https://forums.freebsd.org/threads/dovecot-time-moved-forwards.82886
> 
> In post #33 RypPn points out the offending line in main.c and in post #34
> msplsh suggests instead of completely removing/commenting out the line, it
> would be more sensible to move it from 'warning' to 'debug'.
> This is what this patch does: change the log facility to 'debug' to mute that
> bogus message for standard configurations, but keep it in 'debug' for anyone
> who might want to debug that issue in the future.
> 
> I tested the patch as a local patch in poudriere and it builds fine on
> 13.3-RELEASE with the quarterly and latest branch.
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: 2.3.21.1 and oauth

[Aki Tuomi via dovecot]

> On 21/08/2024 11:53 EEST v--- via dovecot  wrote:
> 
>  
> Hello! I'm using dovecot with keycloak for oauth authentication. My 
> config is:
> 
> client_id = dovecot
> client_secret = MY_SECRET
> introspection_url = 
> https://MY_KEYCLOAK/realms/master/protocol/openid-connect/token/introspect
> introspection_mode = post
> pass_attrs = pass=%{oauth2:access_token}
> 
> Everything worked great on version 2.3.20. After upgrading to version 
> 2.3.21.1 oauth stopped working with errors:
> 
> auth: Debug: http-client: conn [::1]:443 [1]: Got 401 response for 
> request [Req1: POST 
> https://MY_KEYCLOAK/realms/master/protocol/openid-connect/token/introspect]: 
> Unauthorized (took 5 ms + >Aug 16 00:23:58
> auth: Error: oauth2(MY_EMAIL,127.0.0.1,): oauth2 
> failed: Introspection failed: No username returned
> 
> I tried all combination of configurations, debugging and versions of 
> keycloak. Seems something was broken in this version of dovecot.

Hi!

Release notes say

oauth2: Dovecot would send client_id and client_secret as POST parameters
  to introspection server. These need to be optionally in Basic auth
  instead as required by OIDC specification.

this is a slightly obscure way to say that you need to change your

introspection_url = https://client_id:client_secret@MY_KEYCLOAK/... 

(see 
https://github.com/dovecot/core/blob/d492236fa077cba1222695ca3267afb767235672/NEWS#L8)

Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: SQL Multiple passwords

[Aubry via dovecot]

Thank you for your answer.

I tried it and it works that way. 

Cheers

Aubry

On Wed, 2024-08-14 at 18:08 +1200, Peter via dovecot wrote:
> On 28/07/24 00:49, Jaco Kroon via dovecot wrote:
> > > >  From what I understood from the archive and from my tests, we
> > > > cannot
> > > > have multiple passwords for a given account. (I get the error:
> > > > Password
> > > > query returned multiple matches)
> > > > But it looks like it can be done via a PAM module.
> > > > Does anyone succeeded setup multiple password with PAM or any
> > > > other
> > > > method with a SQL backend ?
> > 
> > We don't do multiple passwords, but in theory you could by passing
> > the 
> > password to the query such that the query can determine which (if
> > any) 
> > password to return :).
> 
> Indeed using the method documented here you should be able to do
> exactly 
> that:
> 
> https://doc.dovecot.org/configuration_manual/authentication/sql/#password-verification-by-sql-server
> 
> This should work with password hashes as well so long as your SQL
> server 
> has an appropriate function to generate the hash from the passed 
> password (%w) and then compare it to the stored hash.
> 
> 
> Peter
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: dovecot-indexer writting as root

[Graham Eddy via dovecot]

i am seeing this too - the “iamglass” file has root ownership occasionally. i 
run a cronjob every 30 mins to find/report/change the ownership back to vmail. 
i am running latest debian repository dovecot 2.3.21 and latest debian 
repository dovecot-fts-xapian 1.6.0-1 - not building from source so limited 
debug capability

i acknowledge dovecot is not responsible for the fts-xapian driver. their 
website https://github.com/grosjo/fts-xapian has the following snippet:
Set detach=1 only if your mail storage in on a partition on which you can force 
the uid/gid. For some reasons, Devoct write as root instead so the filesystem 
must correct until dovecot team fixes the bug. detach=1 speeds up very much the 
process.
however, the mentioned option “detach” is not recognised in the driver.

looking forward to 2.4 CE and supported xapian driver…
cheers
⊣GE⊢

> On 20 Aug 2024, at 3:32 PM, Aki Tuomi via dovecot  wrote:
> 
> Nope, there is too little details available. We are not currently seeing this 
> with other FTS drivers. Can you try reproducing this issue and see if you can 
> figure out where the offending call is coming from?
> 
> Aki
> 
>> On 20/08/2024 02:10 EEST Joan Moreau via dovecot  wrote:
>> 
>> 
>> Hi
>> 
>> Anyone on this ?
>> 
>> 
>> On 11 August 2024 04:02:56 Joan Moreau via dovecot  
>> wrote:
>> 
>>> No, the change of uid comes at the end of the process (commit)
>>> 
>>> 
>>> On 2 August 2024 19:08:00 Aki Tuomi via dovecot  wrote:
>>> 
 You are probably doing file operations before setuid() call, do you
 initialize things too soon?
 
 Aki
 
> On 01/08/2024 12:59 EEST Joan Moreau via dovecot  
> wrote:
> 
> 
> Hi
> 
> Any idea on that ?
> 
> Thank you
> 
> On Sat, 2024-07-27 at 15:53 +0800, Joan Moreau via dovecot wrote:
>> Hi
>> 
>> I have that issue times to times
>> 
>> Full case described properly here :
>> 
>> https://github.com/grosjo/fts-xapian/issues/168
>> 
>> Can you help understand the root cause of that ?
>> 
>> THank you
>> ___
>> dovecot mailing list -- dovecot@dovecot.org
>> To unsubscribe send an email to dovecot-le...@dovecot.org
> 
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org
 ___
 dovecot mailing list -- dovecot@dovecot.org
 To unsubscribe send an email to dovecot-le...@dovecot.org
>>> 
>>> ___
>>> dovecot mailing list -- dovecot@dovecot.org
>>> To unsubscribe send an email to dovecot-le...@dovecot.org
>> 
>> ___
>> dovecot mailing list -- dovecot@dovecot.org
>> To unsubscribe send an email to dovecot-le...@dovecot.org
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: dovecot-indexer writting as root

[Aki Tuomi via dovecot]

Nope, there is too little details available. We are not currently seeing this 
with other FTS drivers. Can you try reproducing this issue and see if you can 
figure out where the offending call is coming from?

Aki

> On 20/08/2024 02:10 EEST Joan Moreau via dovecot  wrote:
> 
>  
> Hi
> 
> Anyone on this ?
> 
> 
> On 11 August 2024 04:02:56 Joan Moreau via dovecot  
> wrote:
> 
> > No, the change of uid comes at the end of the process (commit)
> >
> >
> > On 2 August 2024 19:08:00 Aki Tuomi via dovecot  wrote:
> >
> >> You are probably doing file operations before setuid() call, do you
> >> initialize things too soon?
> >>
> >> Aki
> >>
> >>> On 01/08/2024 12:59 EEST Joan Moreau via dovecot  
> >>> wrote:
> >>>
> >>>
> >>> Hi
> >>>
> >>> Any idea on that ?
> >>>
> >>> Thank you
> >>>
> >>> On Sat, 2024-07-27 at 15:53 +0800, Joan Moreau via dovecot wrote:
>  Hi
> 
>  I have that issue times to times
> 
>  Full case described properly here :
> 
>  https://github.com/grosjo/fts-xapian/issues/168
> 
>  Can you help understand the root cause of that ?
> 
>  THank you
>  ___
>  dovecot mailing list -- dovecot@dovecot.org
>  To unsubscribe send an email to dovecot-le...@dovecot.org
> >>>
> >>> ___
> >>> dovecot mailing list -- dovecot@dovecot.org
> >>> To unsubscribe send an email to dovecot-le...@dovecot.org
> >> ___
> >> dovecot mailing list -- dovecot@dovecot.org
> >> To unsubscribe send an email to dovecot-le...@dovecot.org
> >
> > ___
> > dovecot mailing list -- dovecot@dovecot.org
> > To unsubscribe send an email to dovecot-le...@dovecot.org
> 
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: dovecot-indexer writting as root

[Joan Moreau via dovecot]

Hi

Anyone on this ?


On 11 August 2024 04:02:56 Joan Moreau via dovecot  wrote:


No, the change of uid comes at the end of the process (commit)


On 2 August 2024 19:08:00 Aki Tuomi via dovecot  wrote:


You are probably doing file operations before setuid() call, do you
initialize things too soon?

Aki


On 01/08/2024 12:59 EEST Joan Moreau via dovecot  wrote:


Hi

Any idea on that ?

Thank you

On Sat, 2024-07-27 at 15:53 +0800, Joan Moreau via dovecot wrote:

Hi

I have that issue times to times

Full case described properly here :

https://github.com/grosjo/fts-xapian/issues/168

Can you help understand the root cause of that ?

THank you
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: 2.3.21(.1) build error on aarch64 (using slackware ARM -current)

[John Stoffel via dovecot]

> "shawn" == shawn kubik--- via dovecot  writes:

> I've spent the last week trying to rebuild Dovecot on my Raspberry
> Pi 3 (aarch64; running Slackware ARM -current) and am running into
> the following build error. I suspected it may be my recent update to
> Slackware but I've been able to build the same source tarball on an
> x86 system running slackware64-current without any problems, so it
> *seems* specific to aarch64.  I've tried both building from the
> 2.3.21 (and 2.3.21.1) tarball(s) as well as pulling the latest code
> from github and they all fail similarly, though in different spots
> it appears.

So it looks like you're compiling with gcc 14.2, have you tried an
older version of GCC if possible?  What about if you compile with
clang instead?  

From looking at the error message, it's not really clear if that's a
gcc error or not, but it sure looks like one.  

> I am building from source instead of using the available Slackware
> packages bc those packages don't have support for postgresql built
> in, but has mysql/mariadb support, which I am not using and is not
> installed on my systems. While it does run, when I try to connect to
> it, it fails citing a missing mariadb.so file.

Did you try updating the package build instructions for the mariadb
version to swap in postgresql instead?  

And what configure command did you use to setup dovecot?  Can you try
to compile that file by hand, and removing some of the options like
the -D__FORTIFY__ or other stuff like that.  Get it down to a simple
test case if at all possible.  

John


> gcc -v output:
> Reading specs from /usr/lib64/gcc/aarch64-slackware-linux-gnu/14.2.0/specs
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-slackware-linux-gnu/14.2.0/lto-wrapper
> Target: aarch64-slackware-linux-gnu
> Configured with: ../configure --with-arch=armv8-a --verbose --prefix=/usr 
> --mandir=/usr/man --infodir=/usr/info --libdir=/usr/lib64 --enable-bootstrap 
> --enable-checking=release --enable-libstdcxx-dual-abi --enable-shared 
> --enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust 
> --enable-objc-gc --enable-threads=posix --enable-__cxa_atexit 
> --enable-gnu-unique-object --enable-clocale=gnu --enable-plugin --enable-lto 
> --with-arch-directory= --with-system-zlib --with-gnu-ld --with-isl 
> --with-default-libstdcxx-abi=new --disable-libunwind-exceptions 
> --disable-libstdcxx-pch --disable-libssp --disable-werror --disable-gtktest 
> --disable-install-libiberty --host=aarch64-slackware-linux-gnu 
> --build=aarch64-slackware-linux-gnu --target=aarch64-slackware-linux-gnu
> Thread model: posix
> Supported LTO compression algorithms: zlib zstd
> gcc version 14.2.0 (GCC) 

> ldd --version output:
> ldd (GNU libc) 2.40
> Copyright (C) 2024 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> Written by Roland McGrath and Ulrich Drepper.

> Configure is: 
> ./configure \
> --with-pgsql \
> --localstatedir=/var \
> --with-lucene \
> --with-libcap \
> --with-inotify=inotify \
> --disable-static \
> --build=$ARCH-slackware-linux || exit 1

> And the output at the point of failure is:

> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../../.. 
> -I../../../../src/lib -I../../../../src/lib-test 
> -I../../../../src/lib-settings -I../../../../src/lib-mail 
> -I../../../../src/lib-imap -I../../../../src/lib-imap-client 
> -I../../../../src/lib-index -I../../../../src/lib-storage 
> -I../../../../src/lib-storage/list -I../../../../src/lib-storage/index 
> -I../../../../src/lib-ssl-iostream -std=gnu99 -g -O2 -fstack-protector-strong 
> -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -W -Wmissing-prototypes 
> -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 
> -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -MT 
> imapc-sync.lo -MD -MP -MF .deps/imapc-sync.Tpo -c imapc-sync.c  -fPIC -DPIC 
> -o .libs/imapc-sync.o
> free(): double free detected in tcache 2
> during GIMPLE pass: slp
> imapc-sync.c: In function ‘imapc_initial_sync_check’:
> imapc-sync.c:294:1: internal compiler error: Aborted
>   294 | imapc_initial_sync_check(struct imapc_sync_context *ctx, bool nooped)
>   | ^~~~
> 0x1b4a3df internal_error(char const*, ...)
> ???:0
> 0x7f80a139fc pthread_kill@@GLIBC_2.34
> ???:0
> 0x7f809c419b gsignal
> ???:0
> 0x7f809abfa7 abort
> ???:0
> 0x7f80a06943 __libc_message_impl
> ???:0
> 0x7f80a1e2c7 malloc_printerr
> ???:0
> 0x7f80a2053b _int_free
> ???:0
> 0x7f80a22b7f __free
> ???:0
> 0xfa35d7 _slp_tree::~_slp_tree()
> ???:0
> 0xfa3aa7 vect_free_slp_instance(_slp_instance*)
> ???:0
> 0xfb9a7f vect_slp_analyze_operations(vec_info*)
> ???:0
> 0xfc06a7 vect_slp_function(function*)
> ???:0
> Pleas

Re: Panic with FTS_BACKEND_FLAG_TOKENIZED_INPUT and virtual mailboxes: file index-search-result.c: line 132

[markus-dovecot--- via dovecot]

Just to be complete here is a second backtrace with a similar error (if it 
needs to be fixed at multiple places):

```
Panic: file index-search-result.c: line 174 
(index_search_result_update_appends): assertion failed: 
(result->search_args->args == &search_arg)
Error: Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(backtrace_append+0x46) 
[0x791235dfa846] ->
 /usr/lib/dovecot/libdovecot.so.0(backtrace_get+0x22) [0x791235dfa962] ->
 /usr/lib/dovecot/libdovecot.so.0(+0x10d81b) [0x791235e0781b] ->
 /usr/lib/dovecot/libdovecot.so.0(+0x10d8b7) [0x791235e078b7] ->
 /usr/lib/dovecot/libdovecot.so.0(+0x5e2e2) [0x791235d582e2] ->
 /usr/lib/dovecot/libdovecot-storage.so.0(+0x518f0) [0x791235f2b8f0] ->
 
/usr/lib/dovecot/modules/lib20_virtual_plugin.so(virtual_storage_sync_init+0x276a)
 [0x791235c58aba] ->
 /usr/lib/dovecot/libdovecot-storage.so.0(mailbox_sync_init+0x5c) 
[0x791235f47f9c] ->
 /usr/lib/dovecot/libdovecot-storage.so.0(mailbox_sync+0x39) [0x791235f48039] ->
 /usr/lib/dovecot/libdovecot-storage.so.0(index_storage_get_status+0x37) 
[0x791235fc5467] ->
 /usr/lib/dovecot/modules/lib20_virtual_plugin.so(+0xc6c5) [0x791235c536c5] ->
 /usr/lib/dovecot/modules/lib20_fts_plugin.so(+0x145e2) [0x791235c9a5e2] ->
 /usr/lib/dovecot/modules/lib01_acl_plugin.so(+0x10cb9) [0x791235ce5cb9] ->
 /usr/lib/dovecot/libdovecot-storage.so.0(mailbox_get_status+0x64) 
[0x791235f485a4] ->
 dovecot/imap(imap_status_get+0x98) [0x623756c8c748] ->
 dovecot/imap(cmd_status+0x19e) [0x623756c7ca7e] ->
 dovecot/imap(command_exec+0xa4) [0x623756c83444] ->
 dovecot/imap(+0x22392) [0x623756c81392] ->
 dovecot/imap(+0x22444) [0x623756c81444] ->
 dovecot/imap(client_handle_input+0x1bd) [0x623756c8189d] ->
 dovecot/imap(client_input+0x74) [0x623756c81e64] ->
 /usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x6d) [0x791235e1e03d] ->
 /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x13a) 
[0x791235e1f7aa] ->
 /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x54) [0x791235e1e0e4] ->
 /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x40) [0x791235e1e2a0] ->
 /usr/lib/dovecot/libdovecot.so.0(master_service_run+0x17) [0x791235d8ead7] ->
 dovecot/imap(main+0x570) [0x623756c72d20] ->
 /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x791235a29d90] ->
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x791235a29e40] ->
 dovecot/imap(_start+0x25) [0x623756c72de5]
```
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: dovecot-2.3.2.1 and dovecot-pigeonhole-0.5.2 bug?

[skraw--- via dovecot]

Ok, it seems the version I am having here is older than the cited patch allows. 
It is likely pigeonhole-0.4.21 from 2017 where the lib-smtp does not exist at 
all.
So I am a bit stuck ...
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: The future of SIS

[Mingye Wang via dovecot]

Pedro Ribeiro wrote:
Ooops, we are using SIS, guess the solution for a similar optimization 
will be a native deduplicated filesystem.


A non-deduplicated filesystem is fine considering the current hash-based 
folder structure.  Just:


1. Switch to a hash with no known collision method (i.e. not sha1)
2. Run a crontab that causes all files with the same hash in filename to 
be hard linked together.


This kind of "skip byte-by-byte" thinking was there since the initial 
implementation of SIS[1], but was never added for some reason.


[1]: https://www.dovecot.org/list/dovecot/2010-August/052175.html

I currently do a much, much reduced version of that: I just run a 
crontab to get `jdupes` to do its byte-by-byte comparison over the 
attachment directory, daily. Duplicates get hard linked.


PS: I swear the documentation for sis-queue is wrong.

Sincerely,
Mingye Wang
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: vacation is not using from in envelope

[Michael Tokarev via dovecot]

26.07.2024 14:37, Marc via dovecot wrote:

How to get dovecot use the from in sieve in the envelope?


One of the possible bugs with vacation is to tell it to use
envelope addresses instead of from addresses.

Don't do it.

/mjt
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: vacation is not using from in envelope

[leoniemeeyr--- via dovecot]

According to me for get  dovecot use the from in sieve in the envelope you can 
do this
First Check Sieve Capabilities
you can Use the envelope Test
Configuration in Dovecot
After configuring, test the setup by sending emails and observing whether they 
are processed correctly according to your Sieve rules
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Frequency Control for IMAP connection

[Joseph Tam via dovecot]

From: Corey H 

> $ sudo tail -1 /var/log/mail.log|grep **@**mail.com|wc -l
> 3544
>
> logs like this:
>
> Aug 15 19:54:10 mx dovecot: imap-login: Login: user=<**@**mail.com>,
> method=PLAIN, rip=**, lip=**, mpid=4151830, TLS,
> session=
>
> How can I implement a Frequency Control on client connections to slow
> down his requests?

Is this a MacOSX client?  I think they have a habit of doing this when
doing global
mailbox searches.  Instead of doing a sane serial march through
mailboxes, it opens
up as many mailboxes as it can, then closes them when the IMAP server denies
then when they hit the max.

If Aki doesn't can't offer a solution, neither can I, but maybe you
can play around
with mail_max_userip_connections to stop them from swamping all your
connections.
You might have to resort to firewall or other general network controls
to actually rate limit
connections.

Joseph Tam 
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: SQL Multiple passwords

[Rob Lister via dovecot]

I did this using SQL database (MySQL) as I wanted to have roundcube 
webmail
with 2FA, but use separate passwords for clients connecting to 
imap/submission
directly. Otherwise, 2FA on only roundcube is a bit pointless if the 
same

credentials can still be used via IMAP without 2FA.

I was inspired by the roundcube ap4rc plugin[1], but it requires a 
separate
username to be created for each device and was kinda awkward to use in 
practice.


I forked it and added some new username formats: "Format 2" is the email
address or same username everywhere.

The key part of it is the Dovecot Auth/SQL dict config:-

https://github.com/listerr/ap4rc/blob/main/README_DOVECOT.md#auth-config-example

The example under format 2 first tries the username/pw in a static 
passwd

file for use with roundcube only, then if this fails, try looking it up
in sql for the application specific passwords.

In reality I use SQL for both rather than static file, the SQL query is 
a bit

more complicated.


[1] https://github.com/openSUSE/ap4rc


On 2024-07-26 15:57, Aubry via dovecot wrote:

Hi,

From what I understood from the archive and from my tests, we cannot
have multiple passwords for a given account. (I get the error: Password
query returned multiple matches) 
But it looks like it can be done via a PAM module. 
Does anyone succeeded setup multiple password with PAM or any other
method with a SQL backend ?



--
Rob Lister
r...@lonap.net
+44 20 3137 8330
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Frequency Control for IMAP connection

[Aki Tuomi via dovecot]

There is no easy way to do this, I guess if you have way to return

delay_until= from your passdb, you can limit the speed a bit.

E.g. delay_until=1723723664

Aki

> On 15/08/2024 15:02 EEST Corey H via dovecot  wrote:
> 
>  
> Hello
> 
> one of our users makes too quick IMAP connections to the server.
> 
> $ sudo tail -1 /var/log/mail.log|grep **@**mail.com|wc -l
> 3544
> 
> logs like this:
> 
> Aug 15 19:54:10 mx dovecot: imap-login: Login: user=<**@**mail.com>, 
> method=PLAIN, rip=**, lip=**, mpid=4151830, TLS, 
> session=
> 
> How can I implement a Frequency Control on client connections to slow 
> down his requests?
> 
> Thank you.
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: 2.3.21.1 build failure on MacOS X 14.6.1

[Aki Tuomi via dovecot]

> On 15/08/2024 08:33 EEST Daniel J. Luke via dovecot  
> wrote:
> 
>  
> Hi - I get a build failure from dbox-storage.c because the stat struct 
> doesn't have st_atim/st_ctim
> 
> This simple patch fixes it (and should also work on linux/glibc hosts, but I 
> haven't tested it there).
> 
> --- src/lib-storage/index/dbox-common/dbox-storage.c.orig   2024-08-14 
> 14:59:57
> +++ src/lib-storage/index/dbox-common/dbox-storage.c2024-08-14 15:01:23
> @@ -293,8 +293,8 @@
>if the directory exists. In case, get also the ctime */
> struct stat stats;
> if (stat(path, &stats) == 0) {
> -   last_temp_file_scan = stats.st_atim.tv_sec;
> -   change_time = stats.st_ctim.tv_sec;
> +   last_temp_file_scan = stats.st_atime;
> +   change_time = stats.st_ctime;
> } else {
> if (errno != ENOENT)
> e_error(user->event, "stat(%s) failed: %m", 
> path);
> 
> -- 
> Daniel J. Luke
> 

Hi!

This has already been fixed in main with 
https://github.com/dovecot/core/pull/211

Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: v2.3.21 compile error

[Goetz Schultz via dovecot]

On 14/08/2024 19:47, Goetz Schultz via dovecot wrote:


On 14/08/2024 19:33, Aki Tuomi via dovecot wrote:


On 14/08/2024 20:30 EEST Herbert J. Skuhra via dovecot 
1. There is a port (and package) for dovecot in mail/dovecot. Why do 
you build from

source?
2. You probably need the below patch and maybe others from files:




Also there is fix for this in dovecot repo as well nowadays:

https://github.com/dovecot/core/commit/1a7b1f66fe4b86cb642dbcfe5a0192c1b77d0e17.patch

followed with

https://github.com/dovecot/core/commit/867a37fa7b74f798a931fb582214b5377f57610e.patch

Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org



Thanks, will try Herbert's patch and see - but good to know that there 
is one on Github as well.



Thanks both - works now.

>8--

 /"\
 \ /  ASCII Ribbon Campaign
  X   against HTML e-mail
 / \ 


  This message is transmitted on 100% recycled electrons.

>8--
Unsigned message - no responsibillity that content is not altered


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: v2.3.21 compile error

[Goetz Schultz via dovecot]

On 14/08/2024 19:33, Aki Tuomi via dovecot wrote:



On 14/08/2024 20:30 EEST Herbert J. Skuhra via dovecot  
wrote:

  
On Wed, Aug 14, 2024 at 07:17:25PM +0200, Goetz Schultz via dovecot wrote:

Hi,

I am trying to compile said version above under FreeBSD 14.1 .

Config setting is:

  ./configure --with-pgsql --with-sql

However, during compile the process halts with below errors:

test-mail-index-transaction-update.c:648:17: error: incompatible pointer to
integer conversion assigning to 'uint32_t' (aka 'unsigned int') from 'char
*(*)(int, int)' [-Wint-conversion]
   648 | hdr.day_stamp = tests[i].old_day_stamp + timezone;
   |   ^ ~
test-mail-index-transaction-update.c:650:49: warning: arithmetic on a
pointer to the function type 'char *(int, int)' is a GNU extension
[-Wgnu-pointer-arith]
   650 | mail_index_update_day_headers(t, tests[i].now +
timezone);
   |   ^

test-mail-index-transaction-update.c:650:36: error: incompatible pointer to
integer conversion passing 'char *(*)(int, int)' to parameter of type
'time_t' (aka 'long') [-Wint-conversion]
   650 | mail_index_update_day_headers(t, tests[i].now +
timezone);
   | ^~~


Other info:

gcc -v
FreeBSD clang version 18.1.5 (https://github.com/llvm/llvm-project.git
llvmorg-18.1.5-0-g617a15a9eac9)
Target: x86_64-unknown-freebsd14.1
Thread model: posix
InstalledDir: /usr/bin

Any clue or pointer (no pun intended) what's going wrong and how to fix it?


1. There is a port (and package) for dovecot in mail/dovecot. Why do you build 
from
source?
2. You probably need the below patch and maybe others from files:




Also there is fix for this in dovecot repo as well nowadays:

https://github.com/dovecot/core/commit/1a7b1f66fe4b86cb642dbcfe5a0192c1b77d0e17.patch

followed with

https://github.com/dovecot/core/commit/867a37fa7b74f798a931fb582214b5377f57610e.patch

Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org



Thanks, will try Herbert's patch and see - but good to know that there 
is one on Github as well.



Thanks and regards

  Goetz R Schultz

Quis custodiet ipsos custodes?
>8--
  /"\
  \ /  ASCII Ribbon Campaign
   X   against HTML e-mail
  / \
>8--

>8--

 /"\
 \ /  ASCII Ribbon Campaign
  X   against HTML e-mail
 / \ 


  This message is transmitted on 100% recycled electrons.

>8--
Unsigned message - no responsibillity that content is not altered


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: v2.3.21 compile error

[Goetz Schultz via dovecot]

On 14/08/2024 19:30, Herbert J. Skuhra via dovecot wrote:

>
> 1. There is a port (and package) for dovecot in mail/dovecot. Why do 
you build from

> source?

a) Ports are usually some versions behind.
b) I like to have it slim, so cutting out drivers and hooks for e.g. 
databases I don't have.

c) I compiled Dovecot for years now without any issues. So why not?
d) I am not saying "Because I can!"

> 2. You probably need the below patch and maybe others from files:
> 


> 

Thanks, will try.

>
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org
>



Thanks and regards

  Goetz R Schultz

Quis custodiet ipsos custodes?
>8--
  /"\
  \ /  ASCII Ribbon Campaign
   X   against HTML e-mail
  / \
>8--

>8--

 /"\
 \ /  ASCII Ribbon Campaign
  X   against HTML e-mail
 / \ 


  This message is transmitted on 100% recycled electrons.

>8--
Unsigned message - no responsibillity that content is not altered


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: v2.3.21 compile error

[Aki Tuomi via dovecot]

> On 14/08/2024 20:30 EEST Herbert J. Skuhra via dovecot  
> wrote:
> 
>  
> On Wed, Aug 14, 2024 at 07:17:25PM +0200, Goetz Schultz via dovecot wrote:
> > Hi,
> > 
> > I am trying to compile said version above under FreeBSD 14.1 .
> > 
> > Config setting is:
> > 
> >  ./configure --with-pgsql --with-sql
> > 
> > However, during compile the process halts with below errors:
> > 
> > test-mail-index-transaction-update.c:648:17: error: incompatible pointer to
> > integer conversion assigning to 'uint32_t' (aka 'unsigned int') from 'char
> > *(*)(int, int)' [-Wint-conversion]
> >   648 | hdr.day_stamp = tests[i].old_day_stamp + timezone;
> >   |   ^ ~
> > test-mail-index-transaction-update.c:650:49: warning: arithmetic on a
> > pointer to the function type 'char *(int, int)' is a GNU extension
> > [-Wgnu-pointer-arith]
> >   650 | mail_index_update_day_headers(t, tests[i].now +
> > timezone);
> >   |   ^
> > 
> > test-mail-index-transaction-update.c:650:36: error: incompatible pointer to
> > integer conversion passing 'char *(*)(int, int)' to parameter of type
> > 'time_t' (aka 'long') [-Wint-conversion]
> >   650 | mail_index_update_day_headers(t, tests[i].now +
> > timezone);
> >   | ^~~
> > 
> > 
> > Other info:
> > 
> > gcc -v
> > FreeBSD clang version 18.1.5 (https://github.com/llvm/llvm-project.git
> > llvmorg-18.1.5-0-g617a15a9eac9)
> > Target: x86_64-unknown-freebsd14.1
> > Thread model: posix
> > InstalledDir: /usr/bin
> > 
> > Any clue or pointer (no pun intended) what's going wrong and how to fix it?
> 
> 1. There is a port (and package) for dovecot in mail/dovecot. Why do you 
> build from
> source?
> 2. You probably need the below patch and maybe others from files:
> 
>  
> 

Also there is fix for this in dovecot repo as well nowadays:

https://github.com/dovecot/core/commit/1a7b1f66fe4b86cb642dbcfe5a0192c1b77d0e17.patch

followed with

https://github.com/dovecot/core/commit/867a37fa7b74f798a931fb582214b5377f57610e.patch

Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: v2.3.21 compile error

[Herbert J. Skuhra via dovecot]

On Wed, Aug 14, 2024 at 07:17:25PM +0200, Goetz Schultz via dovecot wrote:
> Hi,
> 
> I am trying to compile said version above under FreeBSD 14.1 .
> 
> Config setting is:
> 
>  ./configure --with-pgsql --with-sql
> 
> However, during compile the process halts with below errors:
> 
> test-mail-index-transaction-update.c:648:17: error: incompatible pointer to
> integer conversion assigning to 'uint32_t' (aka 'unsigned int') from 'char
> *(*)(int, int)' [-Wint-conversion]
>   648 | hdr.day_stamp = tests[i].old_day_stamp + timezone;
>   |   ^ ~
> test-mail-index-transaction-update.c:650:49: warning: arithmetic on a
> pointer to the function type 'char *(int, int)' is a GNU extension
> [-Wgnu-pointer-arith]
>   650 | mail_index_update_day_headers(t, tests[i].now +
> timezone);
>   |   ^
> 
> test-mail-index-transaction-update.c:650:36: error: incompatible pointer to
> integer conversion passing 'char *(*)(int, int)' to parameter of type
> 'time_t' (aka 'long') [-Wint-conversion]
>   650 | mail_index_update_day_headers(t, tests[i].now +
> timezone);
>   | ^~~
> 
> 
> Other info:
> 
> gcc -v
> FreeBSD clang version 18.1.5 (https://github.com/llvm/llvm-project.git
> llvmorg-18.1.5-0-g617a15a9eac9)
> Target: x86_64-unknown-freebsd14.1
> Thread model: posix
> InstalledDir: /usr/bin
> 
> Any clue or pointer (no pun intended) what's going wrong and how to fix it?

1. There is a port (and package) for dovecot in mail/dovecot. Why do you build 
from
source?
2. You probably need the below patch and maybe others from files:

 


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org