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. -- Jérôme _______________________________________________ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
