equinox:
> Re-reading the documentation over and over again i yesterday realized
> that a simple non-regexp table containing
>
> <snip>
> @example.com @example.org
> ...
> </snip>
>
> does suffice to do the same thing. However the problem i'm having stays
> the same.
Indeed. With Postfix 2.4 and later, both the virtual(5) and
canonical(5) manpages document that wildcard address mappings will
break adress validation.
Address validation in the SMTP daemon was not part of the initial
Postfix design, and therefore the validation will be an over-approximation
when a map replaces an address. To be more precise, the lookup
result would have to go through all the steps that are implemented
in the cleanup daemon.
Currently, you can make the address validation more precise with:
- Replace the @example.com - @example.org mapping with a 1:1 alias
for each valid address in example.com.
- Keep the @example.com - @example.org mapping, and add a
reject_unverified_recipient check for recipients in example.com.
unverified_recipient_reject_code = 550
smtpd_recipient_restrictions =
...
reject_unauth_destination
check_recipient_access inline:{example.com=reject_unverified_recipient}
The inline: table is available in Postfix 3.0 and later. Use a
hash: map with earlier Postfix versions.
The reject_unverified_recipient feature requests that the verify(8)
daemon sends a probe email message to find out of the recipient
address would bounce (after RCPT TO, Postfix sends RSET and QUIT).
The probe message result is cached for several days, so the number
of probes per recipient will be small.
If the alias (or canonical mapping) resolves to a remote address,
Postfix will contact a remote server. If this happens a lot then
the remote site might object.
Wietse
