On Tue, Feb 10, 2015 at 06:10:42PM +1100, Carl Brewer wrote:
> /usr/pkg/sbin/postconf -n
>
> mailbox_transport = lmtp:unix:/var/imap/socket/lmtp
> queue_directory = /var/spool/postfix
> smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination
> reject_unknown_recipient_domain reject_unverified_recipient
> virtual_alias_maps = hash:/usr/pkg/etc/postfix/virtual
> virtual_mailbox_domains = /usr/pkg/etc/postfix/virtual_mailbox_domains
> virtual_transport = lmtp:unix:/var/imap/socket/lmtp
Have you checked that the "postmapped" virtual alias table actually
contains the address that fails verification? Report the output of:
$ export PATH=/usr/pkg/sbin:$PATH
$ addr="[email protected]" # Replace with actual problem address
$ postmap -q "$addr" $(postconf -xh virtual_alias_maps | tr ',' ' ')
> ps -o pid,etime,args -p $(pgrep -x master)
> PID ELAPSED COMMAND
> 25095 37:15 /usr/pkg/libexec/postfix/master -w
That was started rather recently (2.11.3 upgrade). Has the problem
been observed in the last 37 minutes?
One way to explain your logs is if virtual alias expansion is
suppressed somehow for verification probes, but your configuration
shows no evidence of that. The only other possibility is that the
(postmapped) table does not actually contain the address in question.
--
Viktor.
