Len Conrad wrote: > ---------- Original Message ---------------------------------- > From: Brian Evans - Postfix List <grkni...@scent-team.com> > Reply-To: Postfix users <postfix-users@postfix.org> > Date: Tue, 18 Aug 2009 12:58:43 -0400 > > >> Len Conrad wrote: >> >>> ---------- Original Message ---------------------------------- >>> From: "Len Conrad" <lcon...@go2france.com> >>> Reply-To: <lcon...@go2france.com> >>> 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 "exst...@xxx.com" >>>> mysql:/etc/postfix/mysql-virtual_forwardings.cf >>>> exst...@yyy.net >>>> >>>> ... 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=<exst...@xxx.com>, relay=virtual, delay=0.05, >>>> delays=0.04/0/0/0.01, dsn=5.1.1, status=bounced (unknown user: >>>> "exst...@xxx.com") >>>> >>>> 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 key=exst...@xxx.com -> status=0 result=exst...@yyy.net >>> >>> 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): >>> exst...@xxx.com = exst...@yyy.net >>> >>> Aug 18 11:37:02 ms1.zzz.net/ms1.zzz.net postfix/smtpd[22753]: >>> mail_addr_find: exst...@xxx.com -> exst...@yyy.net >>> >>> Aug 18 11:37:02 ms1.zzz.net/ms1.zzz.net postfix/virtual[22030]: >>> 3EF9B4E407F: to=<exst...@xxx.com>, relay=virtual, delay=0.06, >>> delays=0.05/0/0/0.01, dsn=5.1.1, status=bounced (unknown user: >>> "exst...@xxx.com") >>> >>> 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=<exst...@xxx.com> 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=<exst...@xx.com>, > relay=virtual, delay=0 > .07, delays=0.06/0/0/0.01, dsn=5.1.1, status=bounced (unknown user: > "exst...@xxx.com") > > > >> 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.
