Re: Problem with envelope from in Pigeonhole after upgrade
Hi! How are you executing dovecot-lda? I can get 'MAILER-DAEMON' if I omit -f sender-address-here parameter. Aki > On 14 September 2018 at 08:46 David Dodd wrote: > > > To get out of the problem this bug was causing I have now downgraded the > affectect servers to using dovecot 2.2.36 & dovecot-pigeonhole 0.4.24 . > > These versions work correctly for me. > > Has anyone else been able to see the same sort of problem when using > dovecot-2.3 > and dovecot-pigeonhole-0.5 ? > > I am wondering if this is a FreeBSD porting issue or a general problem. > > --Dave
Re: auth_policy in a non-authenticating proxy chain
> On 15 September 2018 at 12:32 Peter Mogensen wrote: > > > > > On 09/15/2018 10:41 AM, Aki Tuomi wrote: > > Point of sending the success ones is to maintain whitelist as well as > > blacklist so you know which ones you should not tarpit anymore. We > > know it does scale as we have very large deployments using the whole > > three request per login model. > > > > > > "Success" in a proxy which is not it self authenticating is only whether > it know where to proxy the requested username to. > I'm not sure whether this would be input to a whitelist. > > I'm not doubting that 3 req/login scales. > > /Peter > This is rather uncommon use-case. Most cases authentication occurs on proxy and is forwarded using, say, master password on to the backend. Aki
Re: auth_policy in a non-authenticating proxy chain
On 09/15/2018 10:41 AM, Aki Tuomi wrote: > Point of sending the success ones is to maintain whitelist as well as > blacklist so you know which ones you should not tarpit anymore. We > know it does scale as we have very large deployments using the whole > three request per login model. > > "Success" in a proxy which is not it self authenticating is only whether it know where to proxy the requested username to. I'm not sure whether this would be input to a whitelist. I'm not doubting that 3 req/login scales. /Peter
Re: auth_policy in a non-authenticating proxy chain
Point of sending the success ones is to maintain whitelist as well as blacklist so you know which ones you should not tarpit anymore. We know it does scale as we have very large deployments using the whole three request per login model. ---Aki TuomiDovecot oy Original message From: Peter Mogensen Date: 15/09/2018 11:25 (GMT+02:00) To: Dovecot Mailing List Subject: Re: auth_policy in a non-authenticating proxy chain Hi ... After the below thread, I wrote a patch to select on a node-by-node basis which auth-policy request should be done from that node. To my surprise the exact same functionality then turned up in 2.2.34 with just slightly different option names:* * *auth_policy_check_before_auth*: Whether to do policy lookup before authentication is started *auth_policy_check_after_auth*: Whether to do policy lookup after authentication is completed *auth_policy_report_after_auth*: Whether to report authentication result This is great. However... in the setup where you have a proxy in front of a backend and the backend does all authentication, it would be nice with an option to only do report requests in case of authentication failure. Point being that, if the proxy authentication "fails", it does not proxy and the backend will never see the req. and do any actual authentication or reporting. However, you would probably still want to know that there has been a failed auth-attempt. Enabling "report_after_auth" on the proxy would however, send a lot of meaningless traffic about "successful" proxy auth events which would tell you basically nothing the backed wouldn't later also report. And the ration between success' and failures in the proxy is probably very high. regards, Peter Mogensen On 12/14/2017 08:30 AM, Peter Mogensen wrote: > Hi, > > I was looking into the new Authentication Policy feature: > https://wiki2.dovecot.org/Authentication/Policy > > I had kinda hoped that I would be able to enfore this in a proxy running > in front of several backends. This proxy does not authenticate. It use > "nopassword". > > > But I realize that the "succes" reported in the final authpolicy req. > (command=report) is not what is actaully happening on the IMAP protocol > level, but rather the result of the passdb chain in the proxy. > (I should probably have predicted this, it's kinda reasonable). > > However... since the proxy use "nopassword", ALL passdb lookups result > in "success", so the proxy will never report an authentication failure > to the authpolicy server. > > This, of course, forces me to do the authpolicy check on the backend > with a shared state, but It would still have been nice to have the proxy > being able to do the first "command=allow" req. and reject attemps > already there even though the backend does "command=report". > > /Peter
Re: auth_policy in a non-authenticating proxy chain
Hi ... After the below thread, I wrote a patch to select on a node-by-node basis which auth-policy request should be done from that node. To my surprise the exact same functionality then turned up in 2.2.34 with just slightly different option names:* * *auth_policy_check_before_auth*: Whether to do policy lookup before authentication is started *auth_policy_check_after_auth*: Whether to do policy lookup after authentication is completed *auth_policy_report_after_auth*: Whether to report authentication result This is great. However... in the setup where you have a proxy in front of a backend and the backend does all authentication, it would be nice with an option to only do report requests in case of authentication failure. Point being that, if the proxy authentication "fails", it does not proxy and the backend will never see the req. and do any actual authentication or reporting. However, you would probably still want to know that there has been a failed auth-attempt. Enabling "report_after_auth" on the proxy would however, send a lot of meaningless traffic about "successful" proxy auth events which would tell you basically nothing the backed wouldn't later also report. And the ration between success' and failures in the proxy is probably very high. regards, Peter Mogensen On 12/14/2017 08:30 AM, Peter Mogensen wrote: > Hi, > > I was looking into the new Authentication Policy feature: > https://wiki2.dovecot.org/Authentication/Policy > > I had kinda hoped that I would be able to enfore this in a proxy running > in front of several backends. This proxy does not authenticate. It use > "nopassword". > > > But I realize that the "succes" reported in the final authpolicy req. > (command=report) is not what is actaully happening on the IMAP protocol > level, but rather the result of the passdb chain in the proxy. > (I should probably have predicted this, it's kinda reasonable). > > However... since the proxy use "nopassword", ALL passdb lookups result > in "success", so the proxy will never report an authentication failure > to the authpolicy server. > > This, of course, forces me to do the authpolicy check on the backend > with a shared state, but It would still have been nice to have the proxy > being able to do the first "command=allow" req. and reject attemps > already there even though the backend does "command=report". > > /Peter
