fix: Dovecot Quota dummy accounts for aliases should check for existing users with an exact user key lookup

[tomav]

Description

Fixes #2639

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (README.md or the documentation under docs/)
• If necessary I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[georglauterbach]

@polarathene does this already suffice when it comes to the issue of adding „wildcard“ aliases (#2637 (comment))?

[polarathene]

Only match what's relevant, the user column. Ensure the value is the start of the line and ends at the delimiter : to avoid the current bug.

Additionally I don't think we want to accidentally have two users with different casing, so use case insensitive match -i.

[polarathene]

@polarathene does this already suffice when it comes to the issue of adding „wildcard“ aliases (#2637 (comment))?

No. That is a separate issue.

If I understand correctly, the method would still accept a @example.com wildcard alias entry as a user and enter it into the user DB.

You would have to reject an address that starts with @ with ^@(identify wildcard) or ^[^@] (identify valid entry as any first char that is not @).

---

That said, this methods purpose only is as an awful workaround for supporting ENABLE_QUOTAS=1. Technically without adding the wildcard entry, you'd get the problem with the postfix policy check as Dovecot is not aware of the (fake) user @example.com.

In that sense, by not addressing it like I mentioned, yes, this PR should also fix that issue. It may not fix it fully for that user as they had recursive aliases (aliases that referenced aliases). A similar issue may be present with support for multiple recipients to an alias, as I don't think the current code handles that either.

Unless someone adds a proper policy service to resolve aliases to actual users, the quota support is going to be flakey. AFAIK even then, I think it would be an issue with multiple recipients, as you either accept or reject when at least one alias mapped user has a known quota overage. It'd seem wrong to block delivery to other recipients for the alias, but not doing so would defeat the purpose afaik regarding backscatter prevention.

[polarathene]

We can squeeze in this fix for 11.1 I think.

[georglauterbach]

Yes, this is fine to be in 11.1.0 :)

[tomav]

Well, thanks guys.