Len Conrad wrote: > ---------- Original Message ---------------------------------- > From: Brian Evans - Postfix List <[email protected]> > Reply-To: Postfix users <[email protected]> > Date: Tue, 18 Aug 2009 12:58:43 -0400 > > >> Len Conrad wrote: >> >>> ---------- Original Message ---------------------------------- >>> From: "Len Conrad" <[email protected]> >>> Reply-To: <[email protected]> >>> Date: Tue, 18 Aug 2009 18:08:59 +0200 >>> >>> >>> >>>> mail_version = 2.3.3 >>>> >>>> postconf | egrep virtual_alias_maps >>>> >>>> proxy_read_maps = $local_recipient_maps, $mydestination, >>>> $virtual_alias_maps, $virtual_alias_domains, $virtual_mailbox_maps, >>>> $virtual_mailbox_domains, $relay_recipient_maps, $relay_domains, >>>> $canonical_maps, $sender_canonical_maps, $recipient_canonical_maps, >>>> $relocated_maps, $transport_maps, $mynetworks >>>> >>>> virtual_alias_maps = proxy:mysql:/etc/postfix/mysql- >>>> >>>> virtual_forwardings.cf, mysql:/etc/postfix/mysql-virtual_email2email.cf >>>> >>>> On the mailbox server, the mysql table answers correctly: >>>> >>>> postmap -q "[email protected]" >>>> mysql:/etc/postfix/mysql-virtual_forwardings.cf >>>> [email protected] >>>> >>>> ... so the virtual_forwardings.cf is correct, the table is correct, >>>> returing the right answer. >>>> >>>> but: >>>> >>>> Aug 18 10:56:54 ms1.zzz.net/ms1.zzz.net postfix/virtual[5386]: >>>> 854544E4066: to=<[email protected]>, relay=virtual, delay=0.05, >>>> delays=0.04/0/0/0.01, dsn=5.1.1, status=bounced (unknown user: >>>> "[email protected]") >>>> >>>> When we do "virtual -vv", we see virtual resolving recipients only with >>>> virtual_mailbox_maps, and apparently not looking at virtual_alias_maps >>>> >>>> virtual_alias_maps worked fine for months until yesterday. We can't find >>>> what changed. >>>> >>>> Suggestions? >>>> >>>> Len >>>> >>>> >>> ============ >>> >>> it's not virtual, but smtpd that's acting strange: >>> >>> Aug 18 11:37:02 ms1.zzz.net/ms1.zzz.net postfix/smtpd[22753]: >>> dict_proxy_lookup: table=mysql:/etc/postfix/mysql-virtual_forwardings.cf >>> flags=lock|fold_fix [email protected] -> status=0 [email protected] >>> >>> Aug 18 11:37:02 ms1.zzz.net/ms1.zzz.net postfix/smtpd[22753]: maps_find: >>> virtual_alias_maps: >>> proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf(0,lock|fold_fix): >>> [email protected] = [email protected] >>> >>> Aug 18 11:37:02 ms1.zzz.net/ms1.zzz.net postfix/smtpd[22753]: >>> mail_addr_find: [email protected] -> [email protected] >>> >>> Aug 18 11:37:02 ms1.zzz.net/ms1.zzz.net postfix/virtual[22030]: >>> 3EF9B4E407F: to=<[email protected]>, relay=virtual, delay=0.06, >>> delays=0.05/0/0/0.01, dsn=5.1.1, status=bounced (unknown user: >>> "[email protected]") >>> >>> The query is answered, so why is the msg bounced? >>> >>> >> First, turn OFF verbose logging and show a complete transaction for a >> message. >> > > Aug 18 13:39:38 xxx postfix/smtpd[2328]: connect from xxx > > Aug 18 13:39:38 xxx postfix/smtpd[2328]: NOQUEUE: warn: RCPT from xxx: 4tup > le_webmail_unfiltered; from=<x> to=<[email protected]> proto=ESMTP helo=<xxx> > > Aug 18 13:39:38 xxx postfix/smtpd[2328]: 022FF4E4066: client=xxx > > Aug 18 13:39:38 xxx postfix/cleanup[1359]: 022FF4E4066: > message-id=<b0094bdf850b84002f7641797fc96c66.sq > uir...@xxx> > > Aug 18 13:39:38 xxx postfix/qmgr[998]: 022FF4E4066: from=<xxx>, size=744, > nrcpt=1 (queue a > ctive) > > Aug 18 13:39:38 xxx postfix/smtpd[2328]: disconnect from x > > Aug 18 13:39:38 xxx postfix/virtual[1400]: 022FF4E4066: to=<[email protected]>, > relay=virtual, delay=0 > .07, delays=0.06/0/0/0.01, dsn=5.1.1, status=bounced (unknown user: > "[email protected]") > > > >> Also provide 'postconf -n' hiding domains with example.(com|net|org) if >> required. >> > > postconf -n > > > receive_override_options = no_address_mappings >
This is why virtual_alias_maps is not working on receipt. Remove this line and use the default. If you are going to use a content filter, set it on re-entry instead in master.cf. > smtpd_recipient_restrictions = check_client_access > hash:/etc/postfix/webmail_client.class, check_helo_access > pcre:/etc/postfix/4tuple_main_unfiltered.pcre, reject_unauth_pipelining, > reject_unknown_recipient_domain, warn_if_reject reject_unverified_sender, > check_client_access hash:/etc/postfix/mta_clients_black.map, > permit_mynetworks, check_client_access hash:/etc/postfix/mta_clients_bw.map, > permit_sasl_authenticated, reject > Rather interesting choice of restrictions. I hope that this is an internal box. You really should put reject_unauth_destination somewhere. Blanket SAV (Sender Address Verification) is frowned upon by many admins. It increases traffic and you are doing it for every message, even if it is spam. You may get blacklisted by some people with this policy. I suggest reviewing the order of restrictions as these may generate problems later.
