On 30/12/19 8:42 pm, Viktor Dukhovni wrote:
With "ldap", "pgsql" and "mysql" it is generally a good idea to use
"proxy:ldap", "proxy:pgsql", ...
I agree, but in this particular case I was focusing on the problem at
hand. I find on IRC it pays to not always get caught up in every
problem I see with someone's configuration if I want to see the end of them.
with "XFORWARD" the logs could be misleading, this could be the
processing of the message south of the content filter, and perhaps
the recipient is not listed in virtual_alias_maps.
While this is possible I doubt it because he did mention that removing
no_address_mapping made the problem go away, so I think this is directly
related to that setting. Also he insisted that the address was in the
db. That said, it wouldn't be the first time I've seen someone say
things like that on IRC that turned out not to be true.
Is there any
other logging for "84E583E814" or the message-id in question?
None that was provided, but I did reference the OP to this thread so
perhaps he will join in at this stage and provide more info.
If the "content_filter" was set as reported, the message would
not have been handed off to the error transport. The presence
of a filter:
https://github.com/vdukhovni/postfix/blob/master/postfix/src/qmgr/qmgr_message.c#L1105-L1115
preëmpts recipient-specific resolution:
https://github.com/vdukhovni/postfix/blob/master/postfix/src/qmgr/qmgr_message.c#L1121-L1127
that (for example) bounces unknown recipients in virtual alias domains.
The reported symptoms are not consistent with content_filter being set
for the message.
Yes, but does it preempt the resolution of whether a recipient exists at
all? I thought that was done in smtpd, not qmgr. I believe there might
be an implicit check_recipient_access on the end of
smtpd_recipient_restrictions that does that, but I'm not sure. The idea
being that a message needs to be rejected before it hits the queue?
That said the logs do show the message going straight into qmgr, so I'm
really just baffled here.
Peter
