I saw one discussion on this error from back in 2013, but didn't learn anything from it that resolves my error.
We have an MX pointing to O365. It sends any email it can't match to a mailbox to our "smarthost", which runs Postfix 3.0.2-20150720 On the Postfix smarthost we have: virtual_alias_maps = hash:/etc/postfix/virtual ldap:/etc/postfix/ ldap-aliases.cf The problematic address will be found in virtual and also in ldap lookup. In virtual it is listed like: fileb...@mydomain.com fileb...@exchange.mydomain.com That is the one I want to use, so virtual appears earlier in the map config line. In ldap it matches as well: postmap -q 'fileb...@mydomain.com' ldap:/etc/postfix/ldap-aliases.cf fileb...@mydomain.com *I would hope it matches first in virtual and delivers.* The file transport has an entry for exchange: navi.mydomain.com relay:[navi.mydomain.com]:25 exchange.mydomain.com relay:[exchange.mydomain.com]:25 mydomain.com relay:[mydomain.mail.protection.outlook.com]:25 (I did remember to run postmap on transport.) Our postmaster address currently has two homes like this and I've tested that if I send to it from this Linux system, it delivers to the transport "navi' in virtual and doesn't care about the match in ldap. Yet the problematic address doesn't behave that way. If I telnet to port 25 on the Linux Postfix server to test a mail conversation, it shows: 451 4.6.0 Alias expansion error after entering the "." to end the message. In the 2013 conversation, someone suggested examining the "virtual alias expansion by hand". I don't know what that means other than to grep for the matching line in virtual. The error seems to mean there is a loop in recursion of lookup, but I don't see how, especially when postmaster is in the same situation. The only difference being that postmaster uses the navi transport, whereas fileback using exchange, while both fileback@ and postmaster@ are listed in virtual and in LDAP.
