On 5/7/22 13:18, Wietse Venema wrote:
James Feeney:
At http://www.postfix.org/postconf.5.html :
----
smtpd_reject_unlisted_recipient (default: yes)
Request that the Postfix SMTP server rejects mail for unknown
recipient addresses, even when no explicit reject_unlisted_recipient
access restriction is specified. This prevents the Postfix queue
from filling up with undeliverable MAILER-DAEMON messages.
An address is always considered "known" when it matches a virtual(5) alias or a
canonical(5) mapping.
If that last sentence above is confusing, then I can invert the
text to make it consistent with its context.
(no change) Request that the Postfix SMTP server rejects mail
for unknown recipient addresses, even when no explicit
reject_unlisted_recipient access restriction is specified. This
prevents the Postfix queue from filling up with undeliverable
MAILER-DAEMON messages.
(inverted) The recipient address is unknown when it does not
match a virtual(5) alias or a canonical(5) table, plus one of
the following conditions holds:
*The recipient domain matches $mydestination, $inet_interfaces or
$proxy_interfaces, but the recipient is not listed in $local_recipient_maps,
and $local_recipient_maps is not null.
*The recipient domain matches $virtual_alias_domains but the recipient is not
listed in $virtual_alias_maps.
*The recipient domain matches $virtual_mailbox_domains but the recipient is not
listed in $virtual_mailbox_maps, and $virtual_mailbox_maps is not null.
*The recipient domain matches $relay_domains but the recipient is not listed in
$relay_recipient_maps, and $relay_recipient_maps is not null.
Thanks for considering this.
Well, your rewording seems to make the "logic structure" more clear, which helps - assuming that
you did *not* mean to imply "NOT match a virtual(5) alias OR NOT match a canonical(5) table", and
really did mean "NOT ( match a virtual(5) alias OR match a canonical(5) table )".
But then, I think the statement would be easier to understand without all the negations, which, it seems in retrospect,
is what you began with the current wording. Rather than focus upon "unknown" and "known", it would
be more direct to focus upon "reject" and "accept", after applying a DeMorgan transform.
Rewording, after the DeMorgan transform, collecting common terms, converting a few of "A and
B" to "if B, then A", and reordering to place the simple terms first and the more
complex terms last, the description of smtpd_reject_unlisted_recipient seems to be saying:
----
(revised part)
With this setting, mail will be ACCEPTED when the recipient address:
1) matches a virtual(5) alias table, OR
2) matches a canonical(5) table, OR
3) REJECTED when:
i) ( the recipient address is NOT listed in the table ) AND
ii) ( the recipient domain ( matches any of:
A) ( the $virtual_alias_domains table ), OR
B) ( IF the $virtual_mailbox_maps table is not null, THEN the
$virtual_mailbox_domains table ), OR
C) ( IF the $relay_recipient_maps table is not null, THEN the $relay_domains
table ), OR
D) ( IF the $local_recipient_maps table is not null, THEN any of:
( the $mydestination table, OR
the $inet_interfaces table, OR
the $proxy_interfaces table ) ) ) ).
Note that when the recipient domain matches the $virtual_alias_domains table, then the
recipient *must* be listed in the $virtual_alias_domains table, to avoid having their
mail rejected as "unknown recipient address".
----
The original wording implies that "recipient" has a data type "element of a table" and "recipient domain" has the same data type
as "domains table". It might also be appropriate here to provide links to descriptions of "recipient", "recipient domain", and
"recipient address", in the sense of their "data type" and where those data types are likely to appear, as, for example, recipient in
tables.
Hmm - maybe the term "recipient" is an abbreviation of the term "recipient address"? And the links would be
to the "Postfix Address Classes" page, linked as "ADDRESS_CLASS_README" and another, linked as
"LOCAL_RECIPIENT_README"?
Oh! Now I see there is an entire page titled "Rejecting Unknown Local Recipients with Postfix", linked as
"LOCAL_RECIPIENT_README". Hmm - "LOCAL_RECIPIENT_README" does not immediately seem to be a name equivalent of
"Rejecting Unknown Local Recipients with Postfix", though I suppose the "Local Recipients" part is the important bit.
Maybe that page should instead be titled "Local Recipients and Rejecting Unknown Local Recipients with Postfix"?
But still, I should think that "smtpd_reject_unlisted_recipient" would deserve a direct link to the
page "Rejecting Unknown Local Recipients with Postfix" - except that *nowhere* on that page is
there any mention of the configuration option "smtpd_reject_unlisted_recipient". So, maybe I'm
still confused - or, it was an oversight? Seemingly minor inconsistencies, confusing to the uninitiated.
This format emphasizes the four-layer depth of compound terms and the relationship
between the recipient domain and the six possible tables referenced by the recipient
domain. It also makes it easier to recognize that, if the maps tables are
"null", then there is no need to list the recipient there, to avoid having
their mail rejected. And, it makes it easier to recognize that, when the recipient
domain *does* match the $virtual_alias_domains table, the recipient *must* be listed in
the $virtual_alias_domains table, to avoid having their mail rejected. Hmm - maybe that
last bit deserves its own special note, as shown.
There are a lot of moving parts there, and I find this format, by inspection
rather than by actual trial and error, much easier to parse. Actually, it has
taken me this long just to wrap my head around it all. I expect that this is
not just me, struggling for clarity.
What do think about that format?
Wietse
James
