On 2/18/22 12:20, Wietse Venema wrote: > Jaroslaw Rafa: >> Dnia 18.02.2022 o godz. 11:17:13 Wietse Venema pisze: >>> Starting to wonder if reject_unverified_recipient should be given >>> more publicity. >> >> Definitely should. I always thought of reject_unverified_recipient only in >> context of a front-end server relaying mail to the final server, which is a >> pretty rare case for me (I usually work with single-server setups). I did >> not think that it can be used in such context as rewriting by canonical >> maps. > > Upon closer reading, address verification has limits some of > which are intentional. > > Address verification will validate addresses that result from > canonical mappings and of 1-to-1 virtual aliases. > > Address verification will not validate addresses that result from > the expansion of 1-to-many virtual aliases. It will just report > that the address before alias expansion is valid. > > It does not validate 1-to-many expansions because that would result > in an explosive behavior, because the result would ambiguous if > some addresses in the expansion result are valid and some not, and > because it could be undesirable to reveal what 1-to-many aliases > expand into. > > Address verification will also not validate addresses that result > from local aliasing/forwarding with alias_maps or ~/.forward files, > because I was too lazy to write code that determines if these are > 1-to-1 or 1-to-many, but also because it might reveal too much > information. It will just report that the address before alias > expansion or forwarding is valid. > > Wietse
Is reject_unverified_recipient the correct approach for a standard Postfix/Dovecot setup? -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature