On 5/11/22 09:56, Wietse Venema wrote:
Please do not reply to the list AND my address.
Ah! I was wondering why I was not being copied directly. My "postfix-users"
mail gets filtered into a separate folder, and I have to go looking there, to see if
there has been a response. Your work-flow is different. No problem, though.
The pseudocode is incomplete. Condition 2.i) matches the recipient
address against an unspecified table.
unspecified table ???
From http://www.postfix.org/postconf.5.html#smtpd_reject_unlisted_recipient , there are four specific maps tables,
which I have labeled, in a different order, as "A", "B", "C", and "D".
Oops! - 2.ii.A was not transcribed correctly - completely missed
$virtual_alias_maps.
Hmm - so, Condition 2.i needs to be more expressive, and some rewording, and
fix $virtual_alias_maps at 2.ii.A, and in the note also:
----
(revised part)
The smtpd_reject_unlisted_recipient configuration option:
1) will NOT REJECT mail when:
i) ( the recipient address matches a virtual(5) alias table ), OR
ii) ( the recipient address matches a canonical(5) table ), AND
2) will REJECT mail when:
i) ( the recipient address is NOT listed in the specified "maps" table, at
A, B, C, and D, following ) AND
ii) ( the recipient domain ( matches any of:
A) ( in the $virtual_alias_maps table, the $virtual_alias_domains table ),
OR
B) ( in the $virtual_mailbox_maps table, IF not null THEN the
$virtual_mailbox_domains table ), OR
C) ( in the $relay_recipient_maps table, IF not null THEN the
$relay_domains table ), OR
D) ( in the $local_recipient_maps table, IF 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 address *must* be listed in the $virtual_alias_maps table, to avoid having the
mail rejected for having an "unknown recipient address".
----
The implementation matches the recipient domain (to determine the
address class) before matching the recipient address against the
valid recipient table for that specific addres class. This avoids
unnecessary recipient address lookups, which is good for reliability.
The documentation is consistent with this behavior.
Perhaps, "not inconsistent"? The reader is not likely to deduce this subtlety on their
own. If this is important to know, then, to actually make the reader aware of this point, the
documentation should simply come out and say so, literally: "The implementation matches the
recipient domain (to determine the address class) before matching the recipient address against the
valid recipient table for that specific address class." You can add a note. But that
operating detail does not tell the reader anything about whether their particular mail message is
going to be rejected, or not, which is probably what they are struggling to understand, by reading
this description for smtpd_reject_unlisted_recipient.
I think that replacing the documentation with (correct) pseudocode
would not be an improvement. Humans are not machines.
Neither are machines human. Machines require precise instructions, from the
operator, to produce a predictable result.
I expect that the smtpd_reject_unlisted_recipient function makes perfect sense to you, because *you wrote* the code. Your prose, in the documentation, though,
has very much a "cannot see the forest for the trees" character about it. Humans may struggle to follow and decipher layers of indirection, as is
required with the current documentation - "but the recipient is not listed", repeated four times, "is not null", repeated three times,
"recipient domain matches", repeated four times, all describing "unknown" for an option called "reject". By the end of it, the
reader has not even been told what this thing will *do*. Will it Reject the mail message, or not? We don't know; there were 14 separate variables referenced,
three of them repeated, on two opposing predicates, with three additional layers of subordinate clauses, and no mention at all of "rejecting mail".
It is like unraveling a bowl of spaghetti, and, as you say "humans are not machines".
Not that I mean to suggest that the documentation is like that generally. But
here particularly, it is a problem.
Wietse
James
