Thank you for the reply. Yes, I am familiar with reject_unlisted_recipient and the differences with reject_unverified_recipient. I help maintain a server control panel (ISPConfig), and we had a use case where recipient address verification for local domains was used as a solution to avoid generating bounces: https://git.ispconfig.org/ispconfig/ispconfig3/-/issues/5772#note_82522
Dropping support for the amavis scanner is not (currently) an option, so that use case remains valid; I'd sure be open to ideas for how to resolve that without the use of recipient verification. Thanks, Jesse On Fri, 2021-08-27 at 16:01 -0400, [email protected] wrote: > > I am trying to utilize 'reject_unverified_recipient' selectively, > > so > > that only addresses for domains which I host are verified > > I might not be understanding your goals, but if you only want to > verify > email accounts that the server is final destination for you don't > want > to be using reject_unverified_recipient. You might be > misunderstanding > what this feature is for. > http://www.postfix.org/ADDRESS_VERIFICATION_README.html > > reject_unlisted_recipient is what postfix uses to check if the > address > is valid for the accounts it accepts mail for. > > The reject_unverified_recipient and reject_unverified_sender are for > checking if an email address hosted else where is valid. It causes > postfix to attempt to delivery a fake email to that account on > another > server. I say fake in the sense that once it finds out that address > is > legit it aborts the message and doesn't send an email. > > A use case would be... when accepting email, to prevent spam, you > could > check that the person claiming to be sending you that email is real. > Not > a made up [email protected] address. If postfix tries to fake deliver > an > email to the [email protected] address and it can't it would then > reject > receiving an email from that address. > > Postfix designers caution against using this feature as an everyday > every mail option as it has some draw backs which you read about on > the > page linked above. -- Jesse Norell Kentec Communications, Inc. 970-522-8107 - www.kci.net
