Re: Sieve: fileinto a subfolder of inbox
2 Dec 2022 18:16:43 dove...@ptld.com: >> I'm trying to write a sieve script that moves emails to a *subfolder* of the >> inbox. >> My script: >> require ["envelope", "fileinto", "mailbox"]; >> if anyof( address "to" "supp...@domain.cc", >> address "cc" "supp...@domain.cc", >> envelope "to" "supp...@domain.cc" ) { >> fileinto :create "INBOX.support"; >> } >> But this creates a new "support" folder BESIDE the inbox, not INSIDE it. > > > Mine looks like this: > if anyof (header :contains "sender" "@dovecot.org", header :contains > "to" "redac...@example.com") > { > fileinto "INBOX.Dovecot"; > } > > > I notice your rule has ":create" which might be why its always creating a new > folder. > Try the rule without the ":create" Hi! See here for the relevant stuff. Basically you haven' passed "LAYOUT=fs" to mail_location So you need to use "." for hierarchical separator. I presume there IS some advantage for the default Maildir++ format, but I don't know what that is...
Re: bug: ARGON2 hash selection incompatible with LDAP
"Krisztián Szegi" k@mszk.eu – 15 November 2022 20:18 > "Michael Ströder" mich...@stroeder.com – 15 November 2022 15:00 > > On 11/15/22 13:45, Krisztián Szegi wrote: > >> I'd like to report that non-binding auth to (Open)LDAP doesn't work > >> if the latter hashes passwords with ARGON2. > > Could you please elaborate why using LDAP bind is a problem for you? > > > > Ciao, Michael. > > > > > > Fair enough question! > > I cannot specify bind_dn template due to mismatched mail addresses and user > DNs, and I thought that that would be suboptimal due to re-binding. > I am a bit confused about how to optimize LDAP lookups now (static files not > option :), re-reading the docs it just made me question more things > - auth_bind_dn cannot be given in my case, as a fixed starting point > - auth_bind adds a temporary binding (using pass_filter) > - can I use userdb prefetch? Docs say I cannot if I use bind with template, > but I am not using the latter. So the search for the user's dn during auth IS > the passdb lookup? > - assuming I am correct, I should give back stuff with passdb lookup: or do I? > - Must I give back userid an guid? 10-mail.conf has "vmail" for both, as > mail accounts don't have UNIX ones linked to them... > - same for home? There is no default I've given until userdb lookup. Just > specify a global mail_home with variables, and get on with life? > -if I should give back one, should I pass it with default_fields = > userdb_home (currently I specify it under default_fields:home in userdb > lookup as LDAP doesn't override home). > > The docs are confusing around userdb. The main thing what is not clear that > they CAN override fields on a per-user basis, but must they provide them for > non-extra fields, when there are global settings for those? > > Thanks! > > BTW, thanks for the great software all of you. > Michael, I've come across some of your work, you have my respect! > On second though: I switched to auth_bind = yes, (I'll start a new thread on optimizing passdb and userdb, because the scattered documentation has some holes in it I think) but my patch is still needed - if I understand correctly - because I use postfix with dovecot as LMTP and auth backend.
Re: bug: ARGON2 hash selection incompatible with LDAP
"Michael Ströder" mich...@stroeder.com – 15 November 2022 15:00 > On 11/15/22 13:45, Krisztián Szegi wrote: >> I'd like to report that non-binding auth to (Open)LDAP doesn't work >> if the latter hashes passwords with ARGON2. > Could you please elaborate why using LDAP bind is a problem for you? > > Ciao, Michael. > > Fair enough question! I cannot specify bind_dn template due to mismatched mail addresses and user DNs, and I thought that that would be suboptimal due to re-binding. I am a bit confused about how to optimize LDAP lookups now (static files not option :), re-reading the docs it just made me question more things - auth_bind_dn cannot be given in my case, as a fixed starting point - auth_bind adds a temporary binding (using pass_filter) - can I use userdb prefetch? Docs say I cannot if I use bind with template, but I am not using the latter. So the search for the user's dn during auth IS the passdb lookup? - assuming I am correct, I should give back stuff with passdb lookup: or do I? - Must I give back userid an guid? 10-mail.conf has "vmail" for both, as mail accounts don't have UNIX ones linked to them... - same for home? There is no default I've given until userdb lookup. Just specify a global mail_home with variables, and get on with life? -if I should give back one, should I pass it with default_fields = userdb_home (currently I specify it under default_fields:home in userdb lookup as LDAP doesn't override home). The docs are confusing around userdb. The main thing what is not clear that they CAN override fields on a per-user basis, but must they provide them for non-extra fields, when there are global settings for those? Thanks! BTW, thanks for the great software all of you. Michael, I've come across some of your work, you have my respect!
Re: bug: ARGON2 hash selection incompatible with LDAP
Sorry, I wanted to post from this alias, but From-Address isn't saved with my drafts :) I failed to recognize during my patchwork that the verification function is the same for ARGON2I and -ID: both call `verify_argon2`, which in turn calls `libsodium's crypto_pwhash_str_verify`. In the new light this, there is no "harm" in my patch: - If backend gives back "{ARGON2}...", dovecot verifies with the same call anyway, regardless of what subtype it actually is, i.e.: {ARGON2I} will work too. - If dovecot generates the hash, the prefix will be the one set by the config's default hash, so for backwards comp., "{ARGON2ID}" could be used if someone wants that. Dovecot will succeed in verifying {ARGON2} generated by itself as well. "Aki Tuomi" aki.tu...@open-xchange.com – 15 November 2022 13:55 > > On 15/11/2022 14:45 EET Krisztián Szegi wrote: > > > > > > Good day to all, > > > > this is my first post to the mailing list! > > > > I'd like to report that non-binding auth to (Open)LDAP doesn't work if the > > latter hashes passwords with ARGON2. > > > > Although dovecot (I am using http://2.3.19.1) does support ARGON2 with > > libsodium, but it doesn't recoginize hashes beginning "{ARGON2}$argon2id$" > > stored (and hashed, using ppolicy module's hashCleartext) by OpenLDAP. > > > > Now, I understand that ARGON2I, -D, and -ID are not compatible, but the > > ACTUAL algorithm is there between the two $. > > Furthermore, I think dovecot is in the minority here, I haven't met any > > software that specifies the ARGON2 subtype between {}. > > BTW, I haven't met any software that hashes passwords with ARGON2, but not > > with the ARGON2ID subtype (where libsodium is available, which also seems > > to be the standard here), as THAT is the recommended one anyway. > > > > I patched the rpm in OpenSUSE repo to alias {ARGON2} to {ARGON2ID}: > > https://build.opensuse.org/package/view_file/home:Samonitari:branches:openSUSE:Factory/dovecot23/dovecot-2.3.0-alias_ARGON2_to_ARGON2ID.patch > > > > Could we get something like this (but maybe more correct) into the official > > source? > > Maybe a config switch to alias it runtime? > > > > Thanks for the attention: > > Krisztián > > Hi! > > Thanks for your report. I think it makes sense, we'll see what we can do > about this. > > Aki > >
bug: ARGON2 hash selection incompatible with LDAP
Good day to all, this is my first post to the mailing list! I'd like to report that non-binding auth to (Open)LDAP doesn't work if the latter hashes passwords with ARGON2. Although dovecot (I am using http://2.3.19.1) does support ARGON2 with libsodium, but it doesn't recoginize hashes beginning "{ARGON2}$argon2id$" stored (and hashed, using ppolicy module's hashCleartext) by OpenLDAP. Now, I understand that ARGON2I, -D, and -ID are not compatible, but the ACTUAL algorithm is there between the two $. Furthermore, I think dovecot is in the minority here, I haven't met any software that specifies the ARGON2 subtype between {}. BTW, I haven't met any software that hashes passwords with ARGON2, but not with the ARGON2ID subtype (where libsodium is available, which also seems to be the standard here), as THAT is the recommended one anyway. I patched the rpm in OpenSUSE repo to alias {ARGON2} to {ARGON2ID}: https://build.opensuse.org/package/view_file/home:Samonitari:branches:openSUSE:Factory/dovecot23/dovecot-2.3.0-alias_ARGON2_to_ARGON2ID.patch Could we get something like this (but maybe more correct) into the official source? Maybe a config switch to alias it runtime? Thanks for the attention: Krisztián