Postfix Domain in BOTH mydestination and virtual_alias_domains


I have regular entries in /var/log/mail.log which reads postfix/trivial-rewrite[: warning: do not list domain domain.tld in BOTH mydestination and virtual_alias_domains.

The server is named server.domain.tld and I also (of course) do have the domain.tld as virtual host managed in Virtualmin. Removing $mydomain from the $mydestination line in /etc/postfix/ results in mails not being delivered, as all the virutal user mails are internally forwarded to virtual.tld-user@domain.tld.

Is there any way to get this fixed without breaking the system's or Webmin's or Virtualmin's logic?



Howdy -- it shouldn't be a problem to have domain.tld added as a Virtual Server, and server.domain.tld in the mydestination line.

The only thing that might cause that notice, is if server.domain.tld is added as a Virtual Server. Do you know if that's the case?

However, are things working, in spite of that warning message?

Yeah, unless mail delivery is failing, I'd recommend ignoring that message.

Everything works fine - I am just annoyed by superfluous log entries and think that there should / must be a "proper" way to handle this ... probably by removing domain.tld from the virtual hosts - but that is uncomfortable. Anyway, I have to accept that this is an unavoidable behaviour ... very sad.

This trigger for this is creating a Virtualmin domain which matches your system's hostname. Because we add all domains to virtual_alias_domains regardless, you can end up seeing this (quite harmless) warning.

My hostname is and I have virtual server and I get this in my error log:

Mar 19 18:41:27 server postfix/trivial-rewrite[28256]: warning: do not list domain in BOTH mydestination and virtual_alias_domains

I added a virtual server with the same FQDN in order to make a test page for server and make use of Webmin's automatic issuance of Let's Encrypt certificate, etc.

Is it safe to remove from virtual_alias_domains?

You should remove it from mydestination instead.

Everything that I have tried so far failed or had bad side effects - just to warn you. ;)

In that case, maybe just ignore this message?

For the time being: yes.

But it is absolutely desirable to understand, why this happens and to find some solution to avoid the error messages. This also applies to some other issues that I have raised in the past. No administrator likes to read "meaningless" warnings in his log files - at least none administrator, I know. ;)

Agreed ... but I've yet to find a solution that doesn't have other side-effects.

I quite imagine how difficult it is to change such a big configuration / administration system without breaking anything - I keep fingers crossed for all of us. :)