On 10/02/2015 6:21 PM, Viktor Dukhovni wrote:
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 ',' ' ')
bash-4.3# export PATH=/usr/pkg/sbin:$PATH
bash-4.3# addr="[email protected]"
bash-4.3# postmap -q "$addr" $(postconf -xh virtual_alias_maps | tr ',' ' ')
[email protected]
so it's doing the right thing
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?
No.
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.
It seems to be working fine now.
thank you Viktor
Carl
