On Tue, Aug 19, 2008 at 1:43 PM, Wietse Venema <[EMAIL PROTECTED]> wrote: > Jeff: >> On Tue, Aug 19, 2008 at 11:38 AM, Wietse Venema <[EMAIL PROTECTED]> wrote: >> > Jeff: >> >> It took me a while before I could test this. The recommended solution >> >> succeeds at blocking the specified aliases when relayed through our >> >> gateway, but it does not do so at the SMTP level. It generates bounce >> >> notifications, which in the end will create back-scatter. The bounce >> >> message I got in testing gave an error code of 554. >> > >> > Sorry, reject_unverified_recipient does not generate backscatter. >> > If you believe this is not so, then you need to provide actual >> > evidence so that we can point out your mistake. >> > >> > Wietse >> >> Exactly! I can't figure out why I'm getting bounces instead of rejects. > > That's because your configuration does not work the way you describe it. > >> I did (moments after clicking "send") discover in "man -s 5 access" >> that I can put the reject code (550) directly in the map. However, I >> am still getting bounces when I send mail to the private address I am >> using for testing. >> >> Updated config on the back-end MTA... > > Of course, reject_unverified_recipient is meaningful only when > tun on the FRONT END MTA. >
It IS turned on on the front end MTA. But the front end gateway depends on having recipient verification functioning on the back-end servers. The gateway has no knowledge of actual user accounts. The gateway acts as a proxy for recipient verification. When an external MTA is sending a message, the gateway contacts the back-end MTA to verify the recipient (using a dummy MAIL FROM and RCPT TO), then responds to the external MTA accordingly. I want the back-end to tell the front-end gateway 550 for [EMAIL PROTECTED], but I want it to tell my other internal MTAs OK, whilst not breaking regular recipient verification. -- Jeff
