On Fri, Jun 24, 2016 at 11:44 AM, francis picabia <fpica...@gmail.com> wrote:
> > 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. > > I have found the source of the problem. The mapping in virtual was to target fileb...@exchange.mydomain.com I could do a postmap -q on fileb...@mydomain.com but I also found postmap -q fileb...@exchange.mydomain.com was returning fileb...@mydomain.com I didn't realize they had this additional value in the AD LDAP related to exchange public folders. The solution was to remove the extraneous attribute with @ exchange.mydomain.com in Active Directory and that took away the logical loop. Thanks for anyone who looked at the problem set/responded.
