Hi Tom!
> i find, that support@??? gets properly resolved to
> support_fesh_com BUT THEN instead of being delivered locally it is
> passed back into the (queue?) as support_fesh_com@???
> which then in turned is resolved into another account via
> trying default match @ohne-microsoft.de
You have qualify_preserve_domain set on your virtusertable router.
That way, unqualified local parts will be qualified with the original
domain (that's ohne-microsoft.de in the above example), and then
processed further.
> one attempt to fix this, was to add an explicit mapping in
> virtusertable such as
> support_fesh_com@??? support_fesh_com
> [...]
> finally it ends up in local delivery...
That's right. The second time that the virtusertable router sees the
address support_fesh_com@???, it will decline, because
it has handled this address before.
> surely this can't be the way it's supposed to be?
No. If you remove qualify_preserve_domain, unqualified local parts
will be qualified using "qualify_domain", which defaults to
"primary_hostname". Usually, the primary hostname is also in
+local_domains, but not in your case (you seem to have accidentally
removed the "@" from local_domains):
> routing olga_groove_de@???
> --------> dnslookup router <--------
> local_part=olga_groove_de domain=smtp.tomster.org
> checking domains
> smtp.tomster.org in "lists.tomster.org : lists.klingendes-museum.de :
> primary.tomster.org : thesilencer.de :
> ds80-237-202-128.dedicated.hosteurope.de"? no (end of list)
> smtp.tomster.org in "! +local_domains"? yes (end of list)
^^^
So, try to remove qualify_preserve_domain, and add "@" to your
local_domains. Some of your problems might go away then.
Andy
