@polarathene I am not 100% certain whether we should disallow both directions, but to me that makes sense.

If you don't support it, then emit a warning. Call it an advanced option. something other than a pointless block.
The server software supports it without issue.
Now I'm just going to go delete this line from the container I'm hosting.

If you don't support it, then emit a warning. Call it an advanced option. something other than a pointless block.

I'm fine with a change to allow it with a warning emitted, or a prompt for confirmation before continuing.

You're welcome to open a PR if the other maintainers are comfortable with the change. It should include test coverage that avoids errors like this one.

FWIW we do make this concern more prominent in our docs from DMS v15 onwards:

The server software supports it without issue.

Yes but DMS is another layer on top of that.

Virtual aliases by default will be used to create dummy accounts in Dovecot. A side-effect is you can login with that (and some users do this), even though that is unintentional and not supported, it's the only option we have for Dovecot Quota support to work without writing and maintaining our own policy check service for Postfix.

Could you please add some context to why you need an alias to your mailbox account with the same address? We enforced this block due to various bug reports caused by misconfigurations (more context here).

It's also possible you are dealing with an XY problem where you are dismissing our decision to forbid aliases sharing mailbox addresses to solve a problem that would be better supported by other features from Postfix. If so your concern is more for the lack of official support via DMS for such, but even if we had that in place you may have only been familiar with aliases and not considered it?

The valid use-cases that I'm aware of are:

• Wildcard catch-all alias has precedence as aliases are resolved before mailbox addresses. The workaround for that is to have an alias with the mailbox address which will have precedence over the wildcard, be a no-op and send to the same address as the alias, handing over to Dovecot for local delivery.
• Forwarding mail to an external mail server, but still retaining a copy locally. DMS doesn't officially support multiple recipients for an alias however (the Dovecot Quotas workaround isn't compatible for example).

Invalid use-cases tend to be forwarding to an external mail server, often @gmail.com.

If you don't support it, then emit a warning. Call it an advanced option. something other than a pointless block. The server software supports it without issue. Now I'm just going to go delete this line from the container I'm hosting.

Thank you for chiming into this closed issue. I also appreciate the kindness with which this command comment has been put forward. As a consequence, I'm eagerly awaiting your well-tested contribution to this FOSS project, which is maintained by individuals in their spare time.

@polarathene was too kind when he gave a friendly answer here. But I have zero tolerance when it comes to impoliteness. Formulate what you want in a direct, precise, and friendly manner. You are not entitled to demand changes to this project, you can ask for them nicely. At the risk of repeating myself: This project is free, open-source, and maintained by individuals in their spare time. This happens again, and you'll be posting nowhere on this whole project, @KevinBrogan. I've made myself clear here, no discussion necessary anymore.