Re: Overquota flag and auth caching

[list]

On 09-13-2022 5:17 am, Christian Rößner wrote:

The result is that mails are still accepted, even a user went over quota 
resulting in bounces.
What is the correct way to use the over quota flag and which solutions can be 
taken to invalidate the user?
Is it possible to do this in a Lua user  backend? Any other method?



It is unclear in your message if you are aware of how you can use have your MTA 
check quota during delivery, and reject before accepting, to prevent 
back-scatter. For example if you are using Postfix you can use the policy 
service to do this in main.cf:

smtpd_recipient_restrictions =
...
check_policy_service unix:private/quota-status

And here are the docs on setting up quota for postfix on the dovecot side:

https://doc.dovecot.org/configuration_manual/quota_plugin/#quota-service

Overquota flag and auth caching

[Christian Rößner]

Hello,

I like the over quota flag mechanism in Dovecot. I found out that I get in 
trouble if a user gets over quota and I have turned on auth caching, because 
the cache does not automatically invalidate a user while toggling the flag. The 
cache still serves the old state.

The result is that mails are still accepted, even a user went over quota 
resulting in bounces.

Workaround is to flush a user from inside the toggle script, which solves the 
bounce problem, but it prevents the user from getting under quota before the 
user is flushed from the cache again.

What is the correct way to use the over quota flag and which solutions can be 
taken to invalidate the user? Is it possible to do this in a Lua user  backend? 
Any other method?

Thanks in advance

Christian Rößner
-- 
Rößner-Network-Solutions
Zertifizierter ITSiBe / CISO
Karl-Bröger-Str. 10, 36304 Alsfeld
Fax: +49 6631 78823409, Mobil: +49 171 9905345
USt-IdNr.: DE225643613, https://roessner.website
PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5