On 03/02/2026 22:01, Jérôme via dovecot wrote:
Hi.
Thanks for anwsering. Things are much clearer now. I had the pieces,
but couldn't get them together.
The part I overlooked was the interest of checking before delivery to
avoid backscatter (reject vs. bounce).
Also, it wasn't obvious to me from the docs that the quota status
policy service was an option, an optimization. I thought it was the
"normal" way or enforcing quotas. And for some reason I thought the
rejection that occurs in a later step was a side effect of sieve or
whatever that happened to do the right thing, rather than the actual
intended quota enforcement.
Thinking of it, it is clear to me that rejection can't always be
achieved right away (e.g. external or multiple alias) so the DUNNO line
is mandatory.
About the query, I could keep the modified one in a best effort to
resolve aliases to get more rejections and less bounces. My initial
question remains. Is it safe to do so? I mean is this query used in
places where returning a virtual alias could be wrong and harmful?
Thanks.
Hi
yes, you could keep the modified query and get more rejections and less
bounces. I don't see anything inherently unsafe about it, but I'll leave
a definitive answer to whoever may be using it and has more experience
to comment on it.
So basically what you are doing is alias expansion in dovecot (that may
or may not be 100% the same as that done in postfix but worst case it's
a subset) for quota checking of aliases which have a direct mapping to
mailboxes and quota checking of mailboxes and then doing alias expansion
in postfix and delivering to mailboxes. I think the unusual part of this
configuration is that your query is common for quota status and
presumably for lmtp delivery and also imap login. You managed the imap
login part by not modifying the password query. For lmtp you are not
actually ever calling this query with an alias (and even if you were it
would probably work anyway). So I think it all logically fits together
though the key point is to test it out before using it in case something
has been overlooked.
One thing I can suggest if you want to converge towards a configuration
that works similarly to how your old query does for lmtp and imap is to
use the variable %s (2.3) or %{service} (2.4) in the query. It is
populated to differentiate the service being called. This takes the
value quota-status for quota checking. It should be possible to make a
query that includes aliases only when called for quota-status and only
mailboxes for service different to quota-status. This is an example of
how I use it in a different context (to allow a different condition for
smtp respect to all other services, that can disable email sending while
allowing login and mail delivery etc.)
user_query = SELECT concat('/var/vmail/', maildir) as home,
concat('maildir:/var/vmail/', maildir, 'mail/') as mail, 200 AS uid, 12
AS gid, concat('*:storage=', quota, 'K') as quota_rule FROM mailbox
WHERE username = '%u' AND active = '1' AND (('%s' = 'smtp' AND
smtp_active = '1') OR '%s' <> 'smtp')
If should be possible to make a query that returns values where user is
a mailbox only when called for services different to quota-status and
returns values where user is alias and mailboxes for quota-status.
John
_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
