Re: Pread error over smb3

[Aki Tuomi via dovecot]

Ok. But the error is coming from kernel, so not much Dovecot can do about it. 
Maybe try turning on some debugging in your server to see what is going on?

Aki

> On 02/07/2024 07:54 EEST Joan Moreau via dovecot  wrote:
> 
>  
> Permissions on the server are very fine
> 
> The problem occurs ONLY with dovecot
> 
> 
> On Tue, 2024-07-02 at 07:49 +0300, Aki Tuomi wrote:
> > 
> > > On 02/07/2024 02:05 EEST Joan Moreau via dovecot
> > >  wrote:
> > > 
> > >  
> > > Hi
> > > 
> > > I am trying to move my storage of email on a smb3 mounted volume.
> > > 
> > > I am getting the following error :
> > > Error: pread(/net/.../storage/dovecot.map.index.log) failed:
> > > Permission
> > > denied (euid=1004(mailusers) egid=12(mail) UNIX perms appear ok
> > > (ACL/MAC wrong?))
> > > 
> > > How to resolve that ?
> > > 
> > > Thank you
> > > 
> > 
> > This seems to be some kind of smb3 ACL problem, check permissions on
> > the server?
> > 
> > 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: Pread error over smb3

[Joan Moreau via dovecot]

Permissions on the server are very fine

The problem occurs ONLY with dovecot


On Tue, 2024-07-02 at 07:49 +0300, Aki Tuomi wrote:
> 
> > On 02/07/2024 02:05 EEST Joan Moreau via dovecot
> >  wrote:
> > 
> >  
> > Hi
> > 
> > I am trying to move my storage of email on a smb3 mounted volume.
> > 
> > I am getting the following error :
> > Error: pread(/net/.../storage/dovecot.map.index.log) failed:
> > Permission
> > denied (euid=1004(mailusers) egid=12(mail) UNIX perms appear ok
> > (ACL/MAC wrong?))
> > 
> > How to resolve that ?
> > 
> > Thank you
> > 
> 
> This seems to be some kind of smb3 ACL problem, check permissions on
> the server?
> 
> Aki

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

Re: Pread error over smb3

[Aki Tuomi via dovecot]

> On 02/07/2024 02:05 EEST Joan Moreau via dovecot  wrote:
> 
>  
> Hi
> 
> I am trying to move my storage of email on a smb3 mounted volume.
> 
> I am getting the following error :
> Error: pread(/net/.../storage/dovecot.map.index.log) failed: Permission
> denied (euid=1004(mailusers) egid=12(mail) UNIX perms appear ok
> (ACL/MAC wrong?))
> 
> How to resolve that ?
> 
> Thank you
> 

This seems to be some kind of smb3 ACL problem, check permissions on the server?

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

Pread error over smb3

[Joan Moreau via dovecot]

Hi

I am trying to move my storage of email on a smb3 mounted volume.

I am getting the following error :
Error: pread(/net/.../storage/dovecot.map.index.log) failed: Permission
denied (euid=1004(mailusers) egid=12(mail) UNIX perms appear ok
(ACL/MAC wrong?))

How to resolve that ?

Thank you

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

Re: AW: AW: AW: IMAPSieve plugin will not run rspamd script

[John Fawcett via dovecot]

On 01/07/2024 22:09, postfix_dovecot--- via dovecot wrote:

Hi John,

  


the prefix is ​​just a sign of my desperation - I tried all sorts of variations 
yesterday and now forgot to undo it.

  


There’s a very detailed tutorial available (German language) with Debian 10. 
Just the sieve scripts are little different. I spend the time to raise a Debian 
10 with this tutorial – and with exact the same result as with my up to date 
configuration.


So it would be interesting for me to know if there is anyone here who has 
managed to get this to work on Debian?

  


Jens



Hi Jens

changing random things is rarely a good way to solve these kinds of 
issues. My advice, if you don't need the inbox namespace prefix set for 
a specific reason, would be to go with the default prefix (ie. blank) 
and then set up the imapsieve rules as per your original post and repeat 
the test. If that does not work then post the debug logging and 
configuration from that test.


There could be multiple places where this is failing but the very first 
point is to have your sieve rules match. They will show something like 
the following in the logging. Notice the "Matched static mailbox rule" 
message. If that is not happening it's pointless to look further down 
the line into issues in the scripts themselves.


Jul 01 22:57:55 imola.site24.it dovecot[1145722]: 
imap(t...@site24.it)<1145777>: Debug: imapsieve: 
mailbox INBOX: MOVE event
Jul 01 22:57:55 imola.site24.it dovecot[1145722]: 
imap(t...@site24.it)<1145777>: Debug: Mailbox Spam: 
UID 2: Expunge requested
Jul 01 22:57:55 imola.site24.it dovecot[1145722]: 
imap(t...@site24.it)<1145777>: Debug: duplicate db: 
Initialize
Jul 01 22:57:55 imola.site24.it dovecot[1145722]: 
imap(t...@site24.it)<1145777>: Debug: sieve: 
Pigeonhole version 0.5.21 (f6cd4b8e) initializing
Jul 01 22:57:55 imola.site24.it dovecot[1145722]: 
imap(t...@site24.it)<1145777>: Debug: sieve: include: 
sieve_global is not set; it is currently not possible to include 
`:global' scripts.
Jul 01 22:57:55 imola.site24.it dovecot[1145722]: 
imap(t...@site24.it)<1145777>: Debug: sieve: Sieve 
imapsieve plugin for Pigeonhole version 0.5.21 (f6cd4b8e) loaded
Jul 01 22:57:55 imola.site24.it dovecot[1145722]: 
imap(t...@site24.it)<1145777>: Debug: sieve: Sieve 
Extprograms plugin for Pigeonhole version 0.5.21 (f6cd4b8e) loaded
Jul 01 22:57:55 imola.site24.it dovecot[1145722]: 
imap(t...@site24.it)<1145777>: Debug: imapsieve: 
Static mailbox rule [1]: mailbox=`Spam' from=`*' causes=(COPY) => 
before=`file:/usr/lib/dovecot/sieve/report-spam.sieve' after=(none)
Jul 01 22:57:55 imola.site24.it dovecot[1145722]: 
imap(t...@site24.it)<1145777>: Debug: imapsieve: 
Static mailbox rule [2]: mailbox=`*' from=`Spam' causes=(COPY APPEND) => 
before=`file:/usr/lib/dovecot/sieve/report-ham.sieve' after=(none)
Jul 01 22:57:55 imola.site24.it dovecot[1145722]: 
imap(t...@site24.it)<1145777>: Debug: imapsieve: 
Matched static mailbox rule [2]


As for Debian, sorry I can't help on that, I'm using Fedora :-)

John

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

AW: AW: AW: IMAPSieve plugin will not run rspamd script

[postfix_dovecot--- via dovecot]

Hi John,

 

the prefix is ​​just a sign of my desperation - I tried all sorts of variations 
yesterday and now forgot to undo it.

 

There’s a very detailed tutorial available (German language) with Debian 10. 
Just the sieve scripts are little different. I spend the time to raise a Debian 
10 with this tutorial – and with exact the same result as with my up to date 
configuration.


So it would be interesting for me to know if there is anyone here who has 
managed to get this to work on Debian?

 

Jens



Von: John Fawcett  
Gesendet: Montag, 1. Juli 2024 18:26
An: postfix_dove...@gmx.de
Betreff: Re: AW: AW: IMAPSieve plugin will not run rspamd script

 

 

On 01/07/2024 18:08, postfix_dove...@gmx.de   
wrote:

Hi John,
 
is there any other log than system?
 
Jens
 
 

Hi Jens

I meant the same type of logging you already posted (i.e. as below) for exactly 
the same test case, but where  the rules use the mailbox name that includes the 
prefix you set for the namespace (i.e.INBOX/Spam).

There is probably a good reason why you have configured a prefix for your 
namespace, but my suspicion is that the example imapsieve config you copied 
assumes no prefix set (it was not part of the example so we cannot see it). 

I personally tried the settings from the example and they work fine and I have 
no prefix. I also did the opposite test and I get the behaviour you reported 
when I have prefix set. In order to solve it (without changing the prefix) I 
had to state the full mailbox name including the prefix in the imapsieve rules. 
In that case it worked. What I'd like to check in your logging is if there is a 
clue why it didn't work for you when yu used INBOX/Spam in the rules.

John

imap(mail@test.example  )<1797>: 
Debug: Module loaded: /usr/lib/dovecot/modules/lib95_imap_sieve_plugin.so
 
imap(mail@test.example  )<1797>: 
Debug: imapsieve: mailbox INBOX/Spam: APPEND event
 
imap(mail@test.example  )<1797>: 
Debug: sieve: Pigeonhole version 0.5.19 (4eae2f79) initializing
 
imap(mail@test.example  )<1797>: 
Debug: sieve: include: sieve_global is not set; it is currently not possible to 
include `:global' scripts.
 
imap(mail@test.example  )<1797>: 
Debug: sieve: Sieve imapsieve plugin for Pigeonhole version 0.5.19 (4eae2f79) 
loaded
 
imap(mail@test.example  )<1797>: 
Debug: sieve: Sieve Extprograms plugin for Pigeonhole version 0.5.19 (4eae2f79) 
loaded
 
imap(mail@test.example  )<1797>: 
Debug: imapsieve: Static mailbox rule [1]: mailbox=`Spam' from=`*' causes=(COPY 
APPEND) => before=`file:/usr/lib/dovecot/sieve/report-spam.sieve' after=(none)
 
imap(mail@test.example  )<1797>: 
Debug: imapsieve: Static mailbox rule [2]: mailbox=`*' from=`Spam' causes=(COPY 
APPEND) => before=`file:/usr/lib/dovecot/sieve/report-ham.sieve' after=(none)
 
imap(mail@test.example  )<1795>: 
Debug: imapsieve: mailbox INBOX: FLAG event (changed flags: \Deleted)
 
imap(mail@test.example  )<1795>: 
Debug: sieve: Pigeonhole version 0.5.19 (4eae2f79) initializing
 
imap(mail@test.example  )<1795>: 
Debug: sieve: include: sieve_global is not set; it is currently not possible to 
include `:global' scripts.
 
imap(mail@test.example  )<1795>: 
Debug: sieve: Sieve imapsieve plugin for Pigeonhole version 0.5.19 (4eae2f79) 
loaded
 
imap(mail@test.example  )<1795>: 
Debug: sieve: Sieve Extprograms plugin for Pigeonhole version 0.5.19 (4eae2f79) 
loaded
 
imap(mail@test.example  )<1795>: 
Debug: imapsieve: Static mailbox rule [1]: mailbox=`Spam' from=`*' causes=(COPY 
APPEND) => before=`file:/usr/lib/dovecot/sieve/report-spam.sieve' after=(none)
 
imap(mail@test.example  )<1795>: 
Debug: imapsieve: Static mailbox rule [2]: mailbox=`*' from=`Spam' causes=(COPY 
APPEND) => before=`file:/usr/lib/dovecot/sieve/report-ham.sieve' after=(none)
 
imap(mail@test.example  )<1795>: 
Debug: imapsieve: mailbox INBOX: FLAG event (changed flags: \Seen)
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Oauth2 introspection mode bug(?)

[Scott Q. via dovecot]

Thank you once again for the explanation.

A somewhat side question if you don't mind. It seems that Outlook
intentionally doesn't want to do oauth2 for any server/service except
MS365/Gmail - does this sound about right ?



On Monday, 01/07/2024 at 13:14 Aki Tuomi wrote:



It was done slightly wrong before, we made it work more standard in
2.3.21

They were sent as URL parameters before, but it was changed into basic
auth instead.

Aki

> On 01/07/2024 20:06 EEST Scott Q. via dovecot  wrote:
> 
>  
> Ok, thanks, what also works is leaving tokeninfo_url empty and
> entering the introspection_url with the clientid/password in the url
> 
> aka, https://user:pass@keycloak.dev1:8443 ...
> 
> I assume this is a bug as well, I think I saw something about it
> breaking from 2.3.20 to 2.3.21
> 
> Thank you Aki!
> 
> 
> On Monday, 01/07/2024 at 13:00 Aki Tuomi via dovecot wrote:
> 
> 
> 
> I know this is bit different answer but I would suggest you use
> introspection_mode=local and provide dovecot the validation keys.
> 
> Alternatively
> 
> Set tokeninfo_url empty. 
> 
> and
> 
> introspection_mode = post
> introspection_url =
>
https://keycloak.dev1:8443/realms/myrealm/protocol/openid-connect/userinfo
> 
> Aki
> 
> > On 01/07/2024 19:49 EEST Scott Q. via dovecot  wrote:
> > 
> >  
> > I'm on 2.3.21
> > 
> > setting introspection_mode to auth causes tokeninfo url to have
the
> > token in both querystring & header.
> > 
> > I've tried removing the tokeninfo url as you suggested in a
previous
> > thread but then authorization fails altogether for me.
> > 
> > This is the info that dovecot sends in auth mode
> > 
> > 
> > 1719847604.669354 GET
> >
>
/realms/myrealm/protocol/openid-connect/userinfo?trash=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJOdy1zVFFFUEYzWkF4Uks3cl9Da1B2cGl3RVR1eXIyOUJfd09kY0FOX1lzIn0.eyJleHAiOjE3MTk4NDc4ODksImlhdCI6MTcxOTg0NzU4OSwianRpIjoiNzNjOWQ5ODgtYWFlZS00MTlmLWFlNTEtYjJhZTI4ZWExZTRkIiwiaXNzIjoiaHR0cHM6Ly9rZXljbG9hay5lbWFpbGFycmF5LmNvbTo4NDQzL3JlYWxtcy9Qb2xhcmlzTWFpbCIsImF1ZCI6ImFjY291bnQiLCJzdWIiOiI0NzdlM2UyNS04OGE2LTRkNWEtYjk5Ni1hZjk5MzhmY2Y4MDEiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJwb2xhcmlzbWFpbC1iYWNrZW5kIiwic2Vzc2lvbl9zdGF0ZSI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiLyoiXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIm9mZmxpbmVfYWNjZXNzIiwidW1hX2F1dGhvcml6YXRpb24iLCJkZWZhdWx0LXJvbGVzLXBvbGFyaXNtYWlsIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJvcGVuaWQgcHJvZmlsZSBlbWFpbCIsInNpZCI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ0dHQxQGFraW5kZXYuY29tIiwiZW1haWwiOiJ0dHQxQGFraW5kZXYuY29tIn0.KOB29-ssutpdLbE8U9yTs6GDXjriW8N1FObrjKUDKRaXYQwU-wk0Oe7kaZr1pqPrCVc9uBIllKDkHVcMWFEm0S5mIiC6J9tvr_UzkrTqKPyXGliM-TU0yjjGB36YGYuBTM2vfyWy93s8qzSJ7MJlnwMrPFaoxv-wYcu_Mvi2elCnkJL_VtpWT4g_yyVbSIzAJpWko4wvz8RBFc5f0ey-M8dLM00eq5h1EuUP02NUbaYzsfLkhejfBzMALGdQAvrEbrQ53RBcuiehVYNsOZ94ge9nhMLeNmMMRNpqYiUePLMYz-lmRqdFLKcx5OlvA3VM5pLctWsoHW7Gm0awckBzdw
> > HTTP/1.1
> > 1719847604.669354 Host: keycloak.dev1:8443
> > 1719847604.669354 Date: Mon, 01 Jul 2024 15:26:44 GMT
> > 1719847604.669354 User-Agent: dovecot-oauth2-passdb/2.3.21
> > 1719847604.669354 Connection: Keep-Alive
> > 1719847604.669385 Authorization: Bearer
> >
>
eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJOdy1zVFFFUEYzWkF4Uks3cl9Da1B2cGl3RVR1eXIyOUJfd09kY0FOX1lzIn0.eyJleHAiOjE3MTk4NDc4ODksImlhdCI6MTcxOTg0NzU4OSwianRpIjoiNzNjOWQ5ODgtYWFlZS00MTlmLWFlNTEtYjJhZTI4ZWExZTRkIiwiaXNzIjoiaHR0cHM6Ly9rZXljbG9hay5lbWFpbGFycmF5LmNvbTo4NDQzL3JlYWxtcy9Qb2xhcmlzTWFpbCIsImF1ZCI6ImFjY291bnQiLCJzdWIiOiI0NzdlM2UyNS04OGE2LTRkNWEtYjk5Ni1hZjk5MzhmY2Y4MDEiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJwb2xhcmlzbWFpbC1iYWNrZW5kIiwic2Vzc2lvbl9zdGF0ZSI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiLyoiXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIm9mZmxpbmVfYWNjZXNzIiwidW1hX2F1dGhvcml6YXRpb24iLCJkZWZhdWx0LXJvbGVzLXBvbGFyaXNtYWlsIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJvcGVuaWQgcHJvZmlsZSBlbWFpbCIsInNpZCI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ0dHQxQGFraW5kZXYuY29tIiwiZW1haWwiOiJ0dHQxQGFraW5kZXYuY29tIn0.KOB29-ssutpdLbE8U9yTs6GDXjriW8N1FObrjKUDKRaXYQwU-wk0Oe7kaZr1pqPrCVc9uBIllKDkHVcMWFEm0S5mIiC6J9tvr_UzkrTqKPyXGliM-TU0yjjGB36YGYuBTM2vfyWy93s8qzSJ7MJlnwMrPFaoxv-wYcu_Mvi2elCnkJL_VtpWT4g_yyVbSIzAJpWko4wvz8RBFc5f0ey-M8dLM00eq5h1EuUP02NUbaYzsfLkhejfBzMALGdQAvrEbrQ53RBcuiehVYNsOZ94ge9nhMLeNmMMRNpqYiUePLMYz-lmRqdFLKcx5OlvA3VM5pLctWsoHW7Gm0awckBzdw
> > 
> > Thanks,
> > Scott
> > On Monday, 01/07/2024 at 12:38 Aki Tuomi via dovecot wrote:
> > 
> > 
> > 
> > > On 01/07/2024 19:29 EEST Scott Q. via dovecot  wrote:
> > > 
> > >  
> > > Here goes another oauth2 question, hoping it won't be

Re: Oauth2 introspection mode bug(?)

[Aki Tuomi via dovecot]

It was done slightly wrong before, we made it work more standard in 2.3.21

They were sent as URL parameters before, but it was changed into basic auth 
instead.

Aki

> On 01/07/2024 20:06 EEST Scott Q. via dovecot  wrote:
> 
>  
> Ok, thanks, what also works is leaving tokeninfo_url empty and
> entering the introspection_url with the clientid/password in the url
> 
> aka, https://user:pass@keycloak.dev1:8443 ...
> 
> I assume this is a bug as well, I think I saw something about it
> breaking from 2.3.20 to 2.3.21
> 
> Thank you Aki!
> 
> 
> On Monday, 01/07/2024 at 13:00 Aki Tuomi via dovecot wrote:
> 
> 
> 
> I know this is bit different answer but I would suggest you use
> introspection_mode=local and provide dovecot the validation keys.
> 
> Alternatively
> 
> Set tokeninfo_url empty. 
> 
> and
> 
> introspection_mode = post
> introspection_url =
> https://keycloak.dev1:8443/realms/myrealm/protocol/openid-connect/userinfo
> 
> Aki
> 
> > On 01/07/2024 19:49 EEST Scott Q. via dovecot  wrote:
> > 
> >  
> > I'm on 2.3.21
> > 
> > setting introspection_mode to auth causes tokeninfo url to have the
> > token in both querystring & header.
> > 
> > I've tried removing the tokeninfo url as you suggested in a previous
> > thread but then authorization fails altogether for me.
> > 
> > This is the info that dovecot sends in auth mode
> > 
> > 
> > 1719847604.669354 GET
> >
> /realms/myrealm/protocol/openid-connect/userinfo?trash=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJOdy1zVFFFUEYzWkF4Uks3cl9Da1B2cGl3RVR1eXIyOUJfd09kY0FOX1lzIn0.eyJleHAiOjE3MTk4NDc4ODksImlhdCI6MTcxOTg0NzU4OSwianRpIjoiNzNjOWQ5ODgtYWFlZS00MTlmLWFlNTEtYjJhZTI4ZWExZTRkIiwiaXNzIjoiaHR0cHM6Ly9rZXljbG9hay5lbWFpbGFycmF5LmNvbTo4NDQzL3JlYWxtcy9Qb2xhcmlzTWFpbCIsImF1ZCI6ImFjY291bnQiLCJzdWIiOiI0NzdlM2UyNS04OGE2LTRkNWEtYjk5Ni1hZjk5MzhmY2Y4MDEiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJwb2xhcmlzbWFpbC1iYWNrZW5kIiwic2Vzc2lvbl9zdGF0ZSI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiLyoiXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIm9mZmxpbmVfYWNjZXNzIiwidW1hX2F1dGhvcml6YXRpb24iLCJkZWZhdWx0LXJvbGVzLXBvbGFyaXNtYWlsIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJvcGVuaWQgcHJvZmlsZSBlbWFpbCIsInNpZCI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ0dHQxQGFraW5kZXYuY29tIiwiZW1haWwiOiJ0dHQxQGFraW5kZXYuY29tIn0.KOB29-ssutpdLbE8U9yTs6GDXjriW8N1FObrjKUDKRaXYQwU-wk0Oe7kaZr1pqPrCVc9uBIllKDkHVcMWFEm0S5mIiC6J9tvr_UzkrTqKPyXGliM-TU0yjjGB36YGYuBTM2vfyWy93s8qzSJ7MJlnwMrPFaoxv-wYcu_Mvi2elCnkJL_VtpWT4g_yyVbSIzAJpWko4wvz8RBFc5f0ey-M8dLM00eq5h1EuUP02NUbaYzsfLkhejfBzMALGdQAvrEbrQ53RBcuiehVYNsOZ94ge9nhMLeNmMMRNpqYiUePLMYz-lmRqdFLKcx5OlvA3VM5pLctWsoHW7Gm0awckBzdw
> > HTTP/1.1
> > 1719847604.669354 Host: keycloak.dev1:8443
> > 1719847604.669354 Date: Mon, 01 Jul 2024 15:26:44 GMT
> > 1719847604.669354 User-Agent: dovecot-oauth2-passdb/2.3.21
> > 1719847604.669354 Connection: Keep-Alive
> > 1719847604.669385 Authorization: Bearer
> >
> eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJOdy1zVFFFUEYzWkF4Uks3cl9Da1B2cGl3RVR1eXIyOUJfd09kY0FOX1lzIn0.eyJleHAiOjE3MTk4NDc4ODksImlhdCI6MTcxOTg0NzU4OSwianRpIjoiNzNjOWQ5ODgtYWFlZS00MTlmLWFlNTEtYjJhZTI4ZWExZTRkIiwiaXNzIjoiaHR0cHM6Ly9rZXljbG9hay5lbWFpbGFycmF5LmNvbTo4NDQzL3JlYWxtcy9Qb2xhcmlzTWFpbCIsImF1ZCI6ImFjY291bnQiLCJzdWIiOiI0NzdlM2UyNS04OGE2LTRkNWEtYjk5Ni1hZjk5MzhmY2Y4MDEiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJwb2xhcmlzbWFpbC1iYWNrZW5kIiwic2Vzc2lvbl9zdGF0ZSI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiLyoiXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIm9mZmxpbmVfYWNjZXNzIiwidW1hX2F1dGhvcml6YXRpb24iLCJkZWZhdWx0LXJvbGVzLXBvbGFyaXNtYWlsIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJvcGVuaWQgcHJvZmlsZSBlbWFpbCIsInNpZCI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ0dHQxQGFraW5kZXYuY29tIiwiZW1haWwiOiJ0dHQxQGFraW5kZXYuY29tIn0.KOB29-ssutpdLbE8U9yTs6GDXjriW8N1FObrjKUDKRaXYQwU-wk0Oe7kaZr1pqPrCVc9uBIllKDkHVcMWFEm0S5mIiC6J9tvr_UzkrTqKPyXGliM-TU0yjjGB36YGYuBTM2vfyWy93s8qzSJ7MJlnwMrPFaoxv-wYcu_Mvi2elCnkJL_VtpWT4g_yyVbSIzAJpWko4wvz8RBFc5f0ey-M8dLM00eq5h1EuUP02NUbaYzsfLkhejfBzMALGdQAvrEbrQ53RBcuiehVYNsOZ94ge9nhMLeNmMMRNpqYiUePLMYz-lmRqdFLKcx5OlvA3VM5pLctWsoHW7Gm0awckBzdw
> > 
> > Thanks,
> > Scott
> > On Monday, 01/07/2024 at 12:38 Aki Tuomi via dovecot wrote:
> > 
> > 
> > 
> > > On 01/07/2024 19:29 EEST Scott Q. via dovecot  wrote:
> > > 
> > >  
> > > Here goes another oauth2 question, hoping it won't be ignored
> > > like all the others.
> > > 
> > > I want to use get/auth on tokeninfo_url but post on
> > introspection_url
> > > but dovecot doesn't let me. It doesn't add the auth header on
> > > tokeninfo_url whenever introspection_mode == post
> > > 
> > > so, if introspec

Re: Oauth2 introspection mode bug(?)

[Scott Q. via dovecot]

Ok, thanks, what also works is leaving tokeninfo_url empty and
entering the introspection_url with the clientid/password in the url

aka, https://user:pass@keycloak.dev1:8443 ...

I assume this is a bug as well, I think I saw something about it
breaking from 2.3.20 to 2.3.21

Thank you Aki!


On Monday, 01/07/2024 at 13:00 Aki Tuomi via dovecot wrote:



I know this is bit different answer but I would suggest you use
introspection_mode=local and provide dovecot the validation keys.

Alternatively

Set tokeninfo_url empty. 

and

introspection_mode = post
introspection_url =
https://keycloak.dev1:8443/realms/myrealm/protocol/openid-connect/userinfo

Aki

> On 01/07/2024 19:49 EEST Scott Q. via dovecot  wrote:
> 
>  
> I'm on 2.3.21
> 
> setting introspection_mode to auth causes tokeninfo url to have the
> token in both querystring & header.
> 
> I've tried removing the tokeninfo url as you suggested in a previous
> thread but then authorization fails altogether for me.
> 
> This is the info that dovecot sends in auth mode
> 
> 
> 1719847604.669354 GET
>
/realms/myrealm/protocol/openid-connect/userinfo?trash=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJOdy1zVFFFUEYzWkF4Uks3cl9Da1B2cGl3RVR1eXIyOUJfd09kY0FOX1lzIn0.eyJleHAiOjE3MTk4NDc4ODksImlhdCI6MTcxOTg0NzU4OSwianRpIjoiNzNjOWQ5ODgtYWFlZS00MTlmLWFlNTEtYjJhZTI4ZWExZTRkIiwiaXNzIjoiaHR0cHM6Ly9rZXljbG9hay5lbWFpbGFycmF5LmNvbTo4NDQzL3JlYWxtcy9Qb2xhcmlzTWFpbCIsImF1ZCI6ImFjY291bnQiLCJzdWIiOiI0NzdlM2UyNS04OGE2LTRkNWEtYjk5Ni1hZjk5MzhmY2Y4MDEiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJwb2xhcmlzbWFpbC1iYWNrZW5kIiwic2Vzc2lvbl9zdGF0ZSI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiLyoiXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIm9mZmxpbmVfYWNjZXNzIiwidW1hX2F1dGhvcml6YXRpb24iLCJkZWZhdWx0LXJvbGVzLXBvbGFyaXNtYWlsIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJvcGVuaWQgcHJvZmlsZSBlbWFpbCIsInNpZCI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ0dHQxQGFraW5kZXYuY29tIiwiZW1haWwiOiJ0dHQxQGFraW5kZXYuY29tIn0.KOB29-ssutpdLbE8U9yTs6GDXjriW8N1FObrjKUDKRaXYQwU-wk0Oe7kaZr1pqPrCVc9uBIllKDkHVcMWFEm0S5mIiC6J9tvr_UzkrTqKPyXGliM-TU0yjjGB36YGYuBTM2vfyWy93s8qzSJ7MJlnwMrPFaoxv-wYcu_Mvi2elCnkJL_VtpWT4g_yyVbSIzAJpWko4wvz8RBFc5f0ey-M8dLM00eq5h1EuUP02NUbaYzsfLkhejfBzMALGdQAvrEbrQ53RBcuiehVYNsOZ94ge9nhMLeNmMMRNpqYiUePLMYz-lmRqdFLKcx5OlvA3VM5pLctWsoHW7Gm0awckBzdw
> HTTP/1.1
> 1719847604.669354 Host: keycloak.dev1:8443
> 1719847604.669354 Date: Mon, 01 Jul 2024 15:26:44 GMT
> 1719847604.669354 User-Agent: dovecot-oauth2-passdb/2.3.21
> 1719847604.669354 Connection: Keep-Alive
> 1719847604.669385 Authorization: Bearer
>
eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJOdy1zVFFFUEYzWkF4Uks3cl9Da1B2cGl3RVR1eXIyOUJfd09kY0FOX1lzIn0.eyJleHAiOjE3MTk4NDc4ODksImlhdCI6MTcxOTg0NzU4OSwianRpIjoiNzNjOWQ5ODgtYWFlZS00MTlmLWFlNTEtYjJhZTI4ZWExZTRkIiwiaXNzIjoiaHR0cHM6Ly9rZXljbG9hay5lbWFpbGFycmF5LmNvbTo4NDQzL3JlYWxtcy9Qb2xhcmlzTWFpbCIsImF1ZCI6ImFjY291bnQiLCJzdWIiOiI0NzdlM2UyNS04OGE2LTRkNWEtYjk5Ni1hZjk5MzhmY2Y4MDEiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJwb2xhcmlzbWFpbC1iYWNrZW5kIiwic2Vzc2lvbl9zdGF0ZSI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiLyoiXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIm9mZmxpbmVfYWNjZXNzIiwidW1hX2F1dGhvcml6YXRpb24iLCJkZWZhdWx0LXJvbGVzLXBvbGFyaXNtYWlsIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJvcGVuaWQgcHJvZmlsZSBlbWFpbCIsInNpZCI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ0dHQxQGFraW5kZXYuY29tIiwiZW1haWwiOiJ0dHQxQGFraW5kZXYuY29tIn0.KOB29-ssutpdLbE8U9yTs6GDXjriW8N1FObrjKUDKRaXYQwU-wk0Oe7kaZr1pqPrCVc9uBIllKDkHVcMWFEm0S5mIiC6J9tvr_UzkrTqKPyXGliM-TU0yjjGB36YGYuBTM2vfyWy93s8qzSJ7MJlnwMrPFaoxv-wYcu_Mvi2elCnkJL_VtpWT4g_yyVbSIzAJpWko4wvz8RBFc5f0ey-M8dLM00eq5h1EuUP02NUbaYzsfLkhejfBzMALGdQAvrEbrQ53RBcuiehVYNsOZ94ge9nhMLeNmMMRNpqYiUePLMYz-lmRqdFLKcx5OlvA3VM5pLctWsoHW7Gm0awckBzdw
> 
> Thanks,
> Scott
> On Monday, 01/07/2024 at 12:38 Aki Tuomi via dovecot wrote:
> 
> 
> 
> > On 01/07/2024 19:29 EEST Scott Q. via dovecot  wrote:
> > 
> >  
> > Here goes another oauth2 question, hoping it won't be ignored
> > like all the others.
> > 
> > I want to use get/auth on tokeninfo_url but post on
> introspection_url
> > but dovecot doesn't let me. It doesn't add the auth header on
> > tokeninfo_url whenever introspection_mode == post
> > 
> > so, if introspection_mode = post, then dovecot no longer sends
auth
> > header to tokeninfo_url . Is this by design, is it a bug ?
> > 
> > as can be seen in
> > 
> > src/lib-oauth2/oauth2-request.c
> > 
> > 
> >         if (add_auth_bearer &&
> >            
http_client_request_get_origin_url(req->req)->user
> > == NULL &&
> >             set->introspection_mode ==
> > INTROSPECTION_MODE_GET

Re: Oauth2 introspection mode bug(?)

[Aki Tuomi via dovecot]

I know this is bit different answer but I would suggest you use 
introspection_mode=local and provide dovecot the validation keys.

Alternatively

Set tokeninfo_url empty. 

and

introspection_mode = post
introspection_url = 
https://keycloak.dev1:8443/realms/myrealm/protocol/openid-connect/userinfo

Aki

> On 01/07/2024 19:49 EEST Scott Q. via dovecot  wrote:
> 
>  
> I'm on 2.3.21
> 
> setting introspection_mode to auth causes tokeninfo url to have the
> token in both querystring & header.
> 
> I've tried removing the tokeninfo url as you suggested in a previous
> thread but then authorization fails altogether for me.
> 
> This is the info that dovecot sends in auth mode
> 
> 
> 1719847604.669354 GET
> /realms/myrealm/protocol/openid-connect/userinfo?trash=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJOdy1zVFFFUEYzWkF4Uks3cl9Da1B2cGl3RVR1eXIyOUJfd09kY0FOX1lzIn0.eyJleHAiOjE3MTk4NDc4ODksImlhdCI6MTcxOTg0NzU4OSwianRpIjoiNzNjOWQ5ODgtYWFlZS00MTlmLWFlNTEtYjJhZTI4ZWExZTRkIiwiaXNzIjoiaHR0cHM6Ly9rZXljbG9hay5lbWFpbGFycmF5LmNvbTo4NDQzL3JlYWxtcy9Qb2xhcmlzTWFpbCIsImF1ZCI6ImFjY291bnQiLCJzdWIiOiI0NzdlM2UyNS04OGE2LTRkNWEtYjk5Ni1hZjk5MzhmY2Y4MDEiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJwb2xhcmlzbWFpbC1iYWNrZW5kIiwic2Vzc2lvbl9zdGF0ZSI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiLyoiXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIm9mZmxpbmVfYWNjZXNzIiwidW1hX2F1dGhvcml6YXRpb24iLCJkZWZhdWx0LXJvbGVzLXBvbGFyaXNtYWlsIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJvcGVuaWQgcHJvZmlsZSBlbWFpbCIsInNpZCI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ0dHQxQGFraW5kZXYuY29tIiwiZW1haWwiOiJ0dHQxQGFraW5kZXYuY29tIn0.KOB29-ssutpdLbE8U9yTs6GDXjriW8N1FObrjKUDKRaXYQwU-wk0Oe7kaZr1pqPrCVc9uBIllKDkHVcMWFEm0S5mIiC6J9tvr_UzkrTqKPyXGliM-TU0yjjGB36YGYuBTM2vfyWy93s8qzSJ7MJlnwMrPFaoxv-wYcu_Mvi2elCnkJL_VtpWT4g_yyVbSIzAJpWko4wvz8RBFc5f0ey-M8dLM00eq5h1EuUP02NUbaYzsfLkhejfBzMALGdQAvrEbrQ53RBcuiehVYNsOZ94ge9nhMLeNmMMRNpqYiUePLMYz-lmRqdFLKcx5OlvA3VM5pLctWsoHW7Gm0awckBzdw
> HTTP/1.1
> 1719847604.669354 Host: keycloak.dev1:8443
> 1719847604.669354 Date: Mon, 01 Jul 2024 15:26:44 GMT
> 1719847604.669354 User-Agent: dovecot-oauth2-passdb/2.3.21
> 1719847604.669354 Connection: Keep-Alive
> 1719847604.669385 Authorization: Bearer
> eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJOdy1zVFFFUEYzWkF4Uks3cl9Da1B2cGl3RVR1eXIyOUJfd09kY0FOX1lzIn0.eyJleHAiOjE3MTk4NDc4ODksImlhdCI6MTcxOTg0NzU4OSwianRpIjoiNzNjOWQ5ODgtYWFlZS00MTlmLWFlNTEtYjJhZTI4ZWExZTRkIiwiaXNzIjoiaHR0cHM6Ly9rZXljbG9hay5lbWFpbGFycmF5LmNvbTo4NDQzL3JlYWxtcy9Qb2xhcmlzTWFpbCIsImF1ZCI6ImFjY291bnQiLCJzdWIiOiI0NzdlM2UyNS04OGE2LTRkNWEtYjk5Ni1hZjk5MzhmY2Y4MDEiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJwb2xhcmlzbWFpbC1iYWNrZW5kIiwic2Vzc2lvbl9zdGF0ZSI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiLyoiXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIm9mZmxpbmVfYWNjZXNzIiwidW1hX2F1dGhvcml6YXRpb24iLCJkZWZhdWx0LXJvbGVzLXBvbGFyaXNtYWlsIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJvcGVuaWQgcHJvZmlsZSBlbWFpbCIsInNpZCI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ0dHQxQGFraW5kZXYuY29tIiwiZW1haWwiOiJ0dHQxQGFraW5kZXYuY29tIn0.KOB29-ssutpdLbE8U9yTs6GDXjriW8N1FObrjKUDKRaXYQwU-wk0Oe7kaZr1pqPrCVc9uBIllKDkHVcMWFEm0S5mIiC6J9tvr_UzkrTqKPyXGliM-TU0yjjGB36YGYuBTM2vfyWy93s8qzSJ7MJlnwMrPFaoxv-wYcu_Mvi2elCnkJL_VtpWT4g_yyVbSIzAJpWko4wvz8RBFc5f0ey-M8dLM00eq5h1EuUP02NUbaYzsfLkhejfBzMALGdQAvrEbrQ53RBcuiehVYNsOZ94ge9nhMLeNmMMRNpqYiUePLMYz-lmRqdFLKcx5OlvA3VM5pLctWsoHW7Gm0awckBzdw
> 
> Thanks,
> Scott
> On Monday, 01/07/2024 at 12:38 Aki Tuomi via dovecot wrote:
> 
> 
> 
> > On 01/07/2024 19:29 EEST Scott Q. via dovecot  wrote:
> > 
> >  
> > Here goes another oauth2 question, hoping it won't be ignored
> > like all the others.
> > 
> > I want to use get/auth on tokeninfo_url but post on
> introspection_url
> > but dovecot doesn't let me. It doesn't add the auth header on
> > tokeninfo_url whenever introspection_mode == post
> > 
> > so, if introspection_mode = post, then dovecot no longer sends auth
> > header to tokeninfo_url . Is this by design, is it a bug ?
> > 
> > as can be seen in
> > 
> > src/lib-oauth2/oauth2-request.c
> > 
> > 
> >         if (add_auth_bearer &&
> >             http_client_request_get_origin_url(req->req)->user
> > == NULL &&
> >             set->introspection_mode ==
> > INTROSPECTION_MODE_GET_AUTH) {
> >                 http_client_request_add_header(req->req,
> >                                              
> >  "Authorization",
> >                                              
> >  t_strdup_printf("Bearer %s",
> >                                              
> >                  input->token));
> >         }
> 
> Not sure what version y

Re: Oauth2 introspection mode bug(?)

[Scott Q. via dovecot]

I'm on 2.3.21

setting introspection_mode to auth causes tokeninfo url to have the
token in both querystring & header.

I've tried removing the tokeninfo url as you suggested in a previous
thread but then authorization fails altogether for me.

This is the info that dovecot sends in auth mode


1719847604.669354 GET
/realms/myrealm/protocol/openid-connect/userinfo?trash=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJOdy1zVFFFUEYzWkF4Uks3cl9Da1B2cGl3RVR1eXIyOUJfd09kY0FOX1lzIn0.eyJleHAiOjE3MTk4NDc4ODksImlhdCI6MTcxOTg0NzU4OSwianRpIjoiNzNjOWQ5ODgtYWFlZS00MTlmLWFlNTEtYjJhZTI4ZWExZTRkIiwiaXNzIjoiaHR0cHM6Ly9rZXljbG9hay5lbWFpbGFycmF5LmNvbTo4NDQzL3JlYWxtcy9Qb2xhcmlzTWFpbCIsImF1ZCI6ImFjY291bnQiLCJzdWIiOiI0NzdlM2UyNS04OGE2LTRkNWEtYjk5Ni1hZjk5MzhmY2Y4MDEiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJwb2xhcmlzbWFpbC1iYWNrZW5kIiwic2Vzc2lvbl9zdGF0ZSI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiLyoiXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIm9mZmxpbmVfYWNjZXNzIiwidW1hX2F1dGhvcml6YXRpb24iLCJkZWZhdWx0LXJvbGVzLXBvbGFyaXNtYWlsIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJvcGVuaWQgcHJvZmlsZSBlbWFpbCIsInNpZCI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ0dHQxQGFraW5kZXYuY29tIiwiZW1haWwiOiJ0dHQxQGFraW5kZXYuY29tIn0.KOB29-ssutpdLbE8U9yTs6GDXjriW8N1FObrjKUDKRaXYQwU-wk0Oe7kaZr1pqPrCVc9uBIllKDkHVcMWFEm0S5mIiC6J9tvr_UzkrTqKPyXGliM-TU0yjjGB36YGYuBTM2vfyWy93s8qzSJ7MJlnwMrPFaoxv-wYcu_Mvi2elCnkJL_VtpWT4g_yyVbSIzAJpWko4wvz8RBFc5f0ey-M8dLM00eq5h1EuUP02NUbaYzsfLkhejfBzMALGdQAvrEbrQ53RBcuiehVYNsOZ94ge9nhMLeNmMMRNpqYiUePLMYz-lmRqdFLKcx5OlvA3VM5pLctWsoHW7Gm0awckBzdw
HTTP/1.1
1719847604.669354 Host: keycloak.dev1:8443
1719847604.669354 Date: Mon, 01 Jul 2024 15:26:44 GMT
1719847604.669354 User-Agent: dovecot-oauth2-passdb/2.3.21
1719847604.669354 Connection: Keep-Alive
1719847604.669385 Authorization: Bearer
eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJOdy1zVFFFUEYzWkF4Uks3cl9Da1B2cGl3RVR1eXIyOUJfd09kY0FOX1lzIn0.eyJleHAiOjE3MTk4NDc4ODksImlhdCI6MTcxOTg0NzU4OSwianRpIjoiNzNjOWQ5ODgtYWFlZS00MTlmLWFlNTEtYjJhZTI4ZWExZTRkIiwiaXNzIjoiaHR0cHM6Ly9rZXljbG9hay5lbWFpbGFycmF5LmNvbTo4NDQzL3JlYWxtcy9Qb2xhcmlzTWFpbCIsImF1ZCI6ImFjY291bnQiLCJzdWIiOiI0NzdlM2UyNS04OGE2LTRkNWEtYjk5Ni1hZjk5MzhmY2Y4MDEiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJwb2xhcmlzbWFpbC1iYWNrZW5kIiwic2Vzc2lvbl9zdGF0ZSI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImFjciI6IjEiLCJhbGxvd2VkLW9yaWdpbnMiOlsiLyoiXSwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbIm9mZmxpbmVfYWNjZXNzIiwidW1hX2F1dGhvcml6YXRpb24iLCJkZWZhdWx0LXJvbGVzLXBvbGFyaXNtYWlsIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJvcGVuaWQgcHJvZmlsZSBlbWFpbCIsInNpZCI6ImFiOTE5NjcxLTlkOWUtNGQwMC1hMWQ4LTY0N2EwZWUzNDBmMCIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ0dHQxQGFraW5kZXYuY29tIiwiZW1haWwiOiJ0dHQxQGFraW5kZXYuY29tIn0.KOB29-ssutpdLbE8U9yTs6GDXjriW8N1FObrjKUDKRaXYQwU-wk0Oe7kaZr1pqPrCVc9uBIllKDkHVcMWFEm0S5mIiC6J9tvr_UzkrTqKPyXGliM-TU0yjjGB36YGYuBTM2vfyWy93s8qzSJ7MJlnwMrPFaoxv-wYcu_Mvi2elCnkJL_VtpWT4g_yyVbSIzAJpWko4wvz8RBFc5f0ey-M8dLM00eq5h1EuUP02NUbaYzsfLkhejfBzMALGdQAvrEbrQ53RBcuiehVYNsOZ94ge9nhMLeNmMMRNpqYiUePLMYz-lmRqdFLKcx5OlvA3VM5pLctWsoHW7Gm0awckBzdw

Thanks,
Scott
On Monday, 01/07/2024 at 12:38 Aki Tuomi via dovecot wrote:



> On 01/07/2024 19:29 EEST Scott Q. via dovecot  wrote:
> 
>  
> Here goes another oauth2 question, hoping it won't be ignored
> like all the others.
> 
> I want to use get/auth on tokeninfo_url but post on
introspection_url
> but dovecot doesn't let me. It doesn't add the auth header on
> tokeninfo_url whenever introspection_mode == post
> 
> so, if introspection_mode = post, then dovecot no longer sends auth
> header to tokeninfo_url . Is this by design, is it a bug ?
> 
> as can be seen in
> 
> src/lib-oauth2/oauth2-request.c
> 
> 
>         if (add_auth_bearer &&
>             http_client_request_get_origin_url(req->req)->user
> == NULL &&
>             set->introspection_mode ==
> INTROSPECTION_MODE_GET_AUTH) {
>                 http_client_request_add_header(req->req,
>                                              
>  "Authorization",
>                                              
>  t_strdup_printf("Bearer %s",
>                                              
>                  input->token));
>         }

Not sure what version you are looking at.
https://github.com/dovecot/core/blob/release-2.3/src/lib-oauth2/oauth2-request.c#L304
adds token into payload.

tokeninfo always adds token to URL, not as header. See
https://github.com/dovecot/core/blob/release-2.3/src/lib-oauth2/oauth2-request.c#L331

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

Re: Oauth2 introspection mode bug(?)

[Aki Tuomi via dovecot]

> On 01/07/2024 19:29 EEST Scott Q. via dovecot  wrote:
> 
>  
> Here goes another oauth2 question, hoping it won't be ignored
> like all the others.
> 
> I want to use get/auth on tokeninfo_url but post on introspection_url
> but dovecot doesn't let me. It doesn't add the auth header on
> tokeninfo_url whenever introspection_mode == post
> 
> so, if introspection_mode = post, then dovecot no longer sends auth
> header to tokeninfo_url . Is this by design, is it a bug ?
> 
> as can be seen in
> 
> src/lib-oauth2/oauth2-request.c
> 
> 
>         if (add_auth_bearer &&
>             http_client_request_get_origin_url(req->req)->user
> == NULL &&
>             set->introspection_mode ==
> INTROSPECTION_MODE_GET_AUTH) {
>                 http_client_request_add_header(req->req,
>                                              
>  "Authorization",
>                                              
>  t_strdup_printf("Bearer %s",
>                                              
>                  input->token));
>         }

Not sure what version you are looking at. 
https://github.com/dovecot/core/blob/release-2.3/src/lib-oauth2/oauth2-request.c#L304
 adds token into payload.

tokeninfo always adds token to URL, not as header. See 
https://github.com/dovecot/core/blob/release-2.3/src/lib-oauth2/oauth2-request.c#L331

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

Oauth2 introspection mode bug(?)

[Scott Q. via dovecot]

Here goes another oauth2 question, hoping it won't be ignored
like all the others.

I want to use get/auth on tokeninfo_url but post on introspection_url
but dovecot doesn't let me. It doesn't add the auth header on
tokeninfo_url whenever introspection_mode == post

so, if introspection_mode = post, then dovecot no longer sends auth
header to tokeninfo_url . Is this by design, is it a bug ?

as can be seen in

src/lib-oauth2/oauth2-request.c


        if (add_auth_bearer &&
            http_client_request_get_origin_url(req->req)->user
== NULL &&
            set->introspection_mode ==
INTROSPECTION_MODE_GET_AUTH) {
                http_client_request_add_header(req->req,
                                             
 "Authorization",
                                             
 t_strdup_printf("Bearer %s",
                                             
                 input->token));
        }
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

AW: IMAPSieve plugin will not run rspamd script

[postfix_dovecot--- via dovecot]

Hi Christian,

yes, it's from the genuine Dovecot documentation. But I tried also a lot of 
other tutorials. They're almost the same except the external scrips for rspamd. 
The result was every time the same: Nothing noticeable in the log.

>Have you checked that your .sieve files have been compiled with sievec, eg 
>have a .svbin extension?
Yes, they are.

>Are the scripts being called executable?
Yes, they are 755

Here's my doveconf -n:

# 2.3.19.1 (9b53102964): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.19 (4eae2f79)
# OS: Linux 6.1.0-21-amd64 x86_64 Debian 12.5 
# Hostname: ServerIV-home.demo.example
auth_mechanisms = plain login
mail_debug = yes
mail_location = maildir:~/Maildir
mail_privileged_group = mail
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character 
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy 
include variables body enotify environment mailbox date index ihave duplicate 
mime foreverypart extracttext imapsieve vnd.dovecot.imapsieve
namespace inbox {
  hidden = no
  ignore_on_failure = no
  inbox = yes
  list = yes
  location = 
  mailbox Drafts {
auto = subscribe
special_use = \Drafts
  }
  mailbox Junk {
special_use = \Junk
  }
  mailbox Sent {
auto = subscribe
special_use = \Sent
  }
  mailbox "Sent Messages" {
special_use = \Sent
  }
  mailbox Spam {
auto = subscribe
special_use = \Junk
  }
  mailbox Trash {
auto = subscribe
special_use = \Trash
  }
  prefix = INBOX/
  separator = /
  subscriptions = yes
  type = private
}
passdb {
  driver = pam
}
passdb {
  args = scheme=CRYPT username_format=%u /etc/dovecot/users
  driver = passwd-file
}
plugin {
  imapsieve_mailbox1_before = file:/usr/lib/dovecot/sieve/report-spam.sieve
  imapsieve_mailbox1_causes = COPY APPEND FLAG
  imapsieve_mailbox1_name = Spam
  imapsieve_mailbox2_before = file:/usr/lib/dovecot/sieve/report-ham.sieve
  imapsieve_mailbox2_causes = COPY APPEND FLAG
  imapsieve_mailbox2_from = Spam
  imapsieve_mailbox2_name = *
  sieve = file:~/sieve;active=~/.dovecot.sieve
  sieve_after = /etc/dovecot/conf.d/custom-sieve/global_after.sieve
  sieve_before = /etc/dovecot/conf.d/custom-sieve/global_before.sieve
  sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.environment
  sieve_pipe_bin_dir = /usr/lib/dovecot/sieve
  sieve_plugins = sieve_imapsieve sieve_extprograms
}
protocols = imap lmtp sieve
service auth {
  unix_listener /var/spool/postfix/private/auth {
mode = 0666
  }
}
service lmtp {
  inet_listener lmtp {
address = 127.0.0.1 ::1
port = 24
  }
}
ssl_cert = : Debug: imapsieve: mailbox 
INBOX: FLAG event (changed flags: \Deleted)
imap(info@demo.example)<1518>: Debug: Module loaded: 
/usr/lib/dovecot/modules/lib95_imap_sieve_plugin.so
imap(info@demo.example)<1518>: Debug: imapsieve: mailbox 
INBOX/Spam: APPEND event
imap(info@demo.example)<1518>: Debug: sieve: Pigeonhole 
version 0.5.19 (4eae2f79) initializing
imap(info@demo.example)<1518>: Debug: sieve: include: 
sieve_global is not set; it is currently not possible to include `:global' 
scripts.
imap(info@demo.example)<1518>: Debug: sieve: Sieve imapsieve 
plugin for Pigeonhole version 0.5.19 (4eae2f79) loaded
imap(info@demo.example)<1518>: Debug: sieve: Sieve 
Extprograms plugin for Pigeonhole version 0.5.19 (4eae2f79) loaded
imap(info@demo.example)<1518>: Debug: imapsieve: Static 
mailbox rule [1]: mailbox=`Spam' from=`*' causes=(COPY APPEND FLAG) => 
before=`file:/usr/lib/dovecot/sieve/report-spam.sieve' after=(none)
imap(info@demo.example)<1518>: Debug: imapsieve: Static 
mailbox rule [2]: mailbox=`*' from=`Spam' causes=(COPY APPEND FLAG) => 
before=`file:/usr/lib/dovecot/sieve/report-ham.sieve' after=(none)
imap(info@demo.example)<1503>: Debug: imapsieve: mailbox 
INBOX: FLAG event (changed flags: \Seen)


Regards
 Jens


-Ursprüngliche Nachricht-
Von: Christian Kivalo via dovecot  
Gesendet: Sonntag, 30. Juni 2024 22:07
An: dovecot@dovecot.org
Betreff: Re: IMAPSieve plugin will not run rspamd script



On June 30, 2024 7:57:26 PM GMT+02:00, postfix_dovecot--- via dovecot 
 wrote:
>Tried it now in every known combination. Nothing changes. It's my 7th 
>evening about this and I'm starting to despair :(
Your config roughly looks like you followed 


Please post doveconf -n to the list.

Have you checked that your .sieve files have been compiled with sievec, eg have 
a .svbin extension?
Are the scripts being called executable?
--
Christian Kivalo
___
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: Sieve Symlink Error

[John Fawcett via dovecot]

On 01/07/2024 03:32, Benjamin Rose via dovecot wrote:


On 6/30/24 16:48, John Fawcett via dovecot wrote:


On 30/06/2024 07:17, Benjamin Rose via dovecot wrote:

Hello,

I'm in the process of moving our mail server from RHEL 6 to RHEL 9. 
We will be moving to:


# dovecot --version
2.3.16 (7e2e900c1a)

My issue is that sieve does not appear to work on the new setup, 
where it does work on the old one. I made a simple filter rule:


# cat /u/mail0test/.sieve/ingo.sieve
# Sieve Filter
# Generated by Ingo (http://www.horde.org/apps/ingo/) (06/28/2024, 
11:14:52 PM)

require "fileinto";
# Test
if header :comparator "i;ascii-casemap" :contains "Subject" 
"filtertest"  {

    fileinto "Fun";
    stop;
}

Upon sending an email to this test account, the following appears in 
/var/log/maillog:


Jun 29 23:19:56 mail5 dovecot[3066980]: 
lda(mail0test)<3066980>: Warning: sieve: 
file storage: Active sieve script symlink 
/u/mail0test/.dovecot.sieve is broken: Invalid/unknown path to 
storage (points to /u/mail0test/.sieve).
Jun 29 23:19:56 mail5 dovecot[2987026]: 
doveadm(mail0test)<3066983>: Warning: sieve: 
file storage: Active sieve script symlink 
/u/mail0test/.dovecot.sieve is broken: Invalid/unknown path to 
storage (points to /u/mail0test/.sieve).
Jun 29 23:19:56 mail5 dovecot[2987026]: 
doveadm(mail0test)<3067016>: Warning: sieve: 
file storage: Active sieve script symlink 
/u/mail0test/.dovecot.sieve is broken: Invalid/unknown path to 
storage (points to /u/mail0test/.sieve).


Yet:

# ll /u/mail0test/.dovecot.sieve
lrwxrwxrwx. 1 mail0test sysguest 17 Jun 28 23:26 
/u/mail0test/.dovecot.sieve -> .sieve/ingo.sieve

# file /u/mail0test/.sieve/ingo.sieve
/u/mail0test/.sieve/ingo.sieve: ASCII text

That is the filter file I've pasted above.

I've set the following directives in 
/etc/dovecot/conf.d/90-sieve.conf via puppet:


augeas {
  "dovecot_sieve_settings":
    context => "/files/etc/dovecot/conf.d/90-sieve.conf",
    changes => [
      "set plugin/sieve_dir ~/.sieve",
  "set plugin/sieve_user_log ~/.sieve/log"
    ],
    require => Package["dovecot"],
    notify => Service["dovecot"];
}

The full configuration dump is attached.

/u in our environment is the path for user homedirs, which is an NFS 
mount to a NetApp. The OS is Springdale Linux 9.2, a clone of RedHat 
from before the IBM license change. It will soon be RHEL 9.4 as we 
have obtained a license, but for all intents and purposes, 
Springdale 9.2 and RHEL 9.2 should be considered bug-for-bug 
compatible. The arch is x86_64 with both machines mail5 and mail6 
(replicated) having Intel(R) Xeon(R) Gold 6244 CPU @ 3.60GHz and 
768gb of memory. I have the same issue with SELinux in both 
enforcing and permissive modes, so this is not a permissions error 
due to SELinux.


Am I doing something wrong, or is this a bug? I've seen that there 
have been some previous issues similar to this that ended up being 
bugs in pigeonhole, so here I am.


Thanks,
Ben


Hi Ben

what version of Pigeonhole are you using?

I read here that sieve_dir is deprecated since v0.3.1

https://doc.dovecot.org/settings/pigeonhole/#pigeonhole_setting-sieve_dir 



In any case these settings look as though they don't really match up. 
Is the correct directory .sieve or sieve?


sieve = file:~/sieve;active=~/.dovecot.sieve
sieve_dir = ~/.sieve

Also, I was curious if your inboxes are really under 
/var/spool/mail/%u and your indexes under /home/%u/indexes?


John

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



Hello,

Thank you! Adding the line to puppet to enforce that this exists in 
/etc/dovecot/conf.d/90-sieve.conf:


sieve=file:~/.sieve;active=~/.dovecot.sieve

has solved the problem. Filters now work as expected!

To answer your questions, I am using 
dovecot-pigeonhole-2.3.16-8.el9.x86_64, and yes, user mail spools live 
under /var/spool/mail (NFS-mounted mbox files) and indexes live under 
/home (local disk - soon to be SSD). That's only for users who are 
using mbox format / pine / mutt. Most users are using only modern 
clients and in this case their storage is mdbox and entirely kept 
inside of /home. This is configured on a per-user basis inside of an 
LDAP value named mailMessageStore. Either it exists such as 
"mdbox:/home//mail", or it does not exist at all, in which 
case, delivery falls back to old-style mbox format. If they are on 
mbox format, only INBOX is kept in /var/spool/mail, all other folders 
are kept in ~/mail (/u//mail/).


Ben


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


Hi Ben

as far as I can see, dovecot-pigeonhole-2.3.16-8.el9.x86_64 uses 
pigeonhole version 0.5.16. In that case I am pretty sure you can remove 
the deprecated "set plugin/sieve_dir ~/.sieve", setting.


John


___
dovecot 

Re: Glean all from addresses from a users mailbox?

[Paul Kudla (SCOM.CA Internet Services Inc.) via dovecot]

please find python imap script below i use to make csv files etc

it will search all folders, sub folders etc and make a file based on 
display name and email address, i had started on a dav cal format but 
csv is all that is supported at this time. it was also designed to 
import hotmail address books for conversion?


was origionally intended to import to thunderbird.

it will give you a starting point.

#!/usr/local/bin/python2
# encoding: utf-8


import sys, os, socket,traceback
import getopt,base64
import time,datetime
from datetime import date
import select
from urllib import unquote_plus

import psycopg2,imaplib
from email.header import decode_header
import imaplib2
from threading import *

from lib import *

from optparse import OptionParser

USAGE_TEXT = '''\
usage: %%prog %s[options]
'''


parser = OptionParser(usage=USAGE_TEXT % '', version='0.4')
parser.add_option("-e", "--email", dest="email_address", help="Email 
Adress to Process")
parser.add_option("-o", "--outlook", dest="hotmail_import_from", 
help="Filespec for Hotmail Address Book")
parser.add_option("-p", "--password", dest="password", help="Email 
Account Password")
parser.add_option("-f", "--filespec", dest="file_out", default = 
'addressbook.csv', help="Output File")
parser.add_option("-v", "--vcard", dest="vcard", default = False, action 
= 'store_true', help="Output File type vCard")

options, args = parser.parse_args()


if options.email_address == None :
print 'No Email Specified ..., Exiting'
sys.exit()


if options.password == None : #Go get the password
print 'Email Account Not Found, Exiting '
sys.exit()


print 'Processing Email   : %s' %options.email_address
print 'Sending To : %s' %options.file_out
print 'Processing Hotmail Addressbook : %s' %options.hotmail_import_from


print 'Logging in to Account : %s with Password : %s\n\n' 
%(options.email_address,options.password)


# Set the following two lines to your creds and server
M = imaplib2.IMAP4("mail.local.scom.ca")
status = M.login(options.email_address,options.password)
# We need to get out of the AUTH state, so we just select
# the INBOX.
if 'OK' not in status :
print 'Bad Username or Password : %s / %s' 
%(options.uemail_address,options.password)

sys.exit()

address_book = []

#Ok import hotmail address book into system if avaliable

if options.hotmail_import_from != None : #go get the file in csv format
f = open(options.hotmail_import_from,'r')
data = f.read()
f.close

#Now start importing the data

data = data.split('\r\n')

#print data
#sys.exit()

for n in range ( 1,len(data) ) :
entry = data[n]
entry = entry.split(',')
#print
#print n,entry[0]


try :
email_address = entry[8].lower()
display_name = entry[0] + ' ' + entry[2]

print 'Importing Email  : %s' 
%email_address

print 'Importing Display Adress : %s' %display_name

#sys.exit()

b = []
b.append( email_address )
b.append( display_name )
b.append( display_name.split(' ')[0] )

try :
b.append( display_name.split(' ')[1] )
except:
b.append( display_name )

except :
pass

#sys.exit()

#Go get the folder list


for i in M.list()[1]:
mbox = (i.split('"/" ')[1])
print '\nProcessing Mbox : %s' %mbox
select_mbox = M.select(mbox)
if 'OK' not in select_mbox :
print 'Error on MBOX : %s, skipping ...' %mbox
continue
#sys.exit()

result, data = M.search(None, "ALL")
ids = data[0] # data is a list.
id_list = ids.split() # ids is a space separated string
#print id_list
#print
#print
#Ok process each email one at a time trying to look up a match


for ii in range( 0,len(id_list) ):
id = id_list[ii]
print
print 'Processing Message ID Number : %s' %str(id)
result, message_header = M.fetch(id, '(BODY.PEEK[HEADER])')
#print message_header
print
#print
message_header = str(message_header[0]).split('\\r\\n')
print 'Message Header for ID : %s:\n' %id
for n in range (0,len(message_header)) :
a = message_header[n]

if a[0:4] == 'To: ' or a[0:6] == 'From: ' :

if 'To: ' in a :
a = a.split('To: ')[1]
  

AW: [EXT] Re: Debian Bookworm packages, please !

[MK via dovecot]

Here also. We are using the debian 12 provided package since 11/2023 and until 
now we have no problems with handeling 50k and more simultaneous TLS 
connections. 

I would also be interested in some more information what the problems are 
debian had with this package, beyond the mail crypt plugin. 

Greetings,
Oliver

-Ursprüngliche Nachricht-
Von: Bernardo Reino via dovecot  
Gesendet: Donnerstag, 27. Juni 2024 13:18
An: Peter via dovecot 
Betreff: [EXT] Re: Debian Bookworm packages, please !

On Thu, 27 Jun 2024, Peter via dovecot wrote:

> On 27/06/24 06:48, pgnd via dovecot wrote:
>>  for anyone interested, for dovecot v2.3.14+ @ Fedora,
>>
>>   
>> https://src.fedoraproject.org/rpms/dovecot/blob/rawhide/f/dovecot-2.3
>> .14-opensslv3.patch
>
>>  dovecot hums along nicely.
>>  i've not seen a _crash_ in _many_ moons (quick looking thru ~ 18mos 
>> of
>>  logs) ...
>
> I can report the same thing with EL9 and ghettoforge dovecot which 
> uses the same patch.  I haven't had any crashes either, but if you're 
> really concerned you can always set Restart=on-failure in the systemd 
> service (I haven't had to yet which says something, imo)

FWIW I've been using the debian-provided dovecot since the release of bookworm 
and have not had a single crash.

> That said I don't use the mail crypt plugin so I can't attest to what 
> happens with that.

Ditto.

Cheers,
Bernardo
___
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