trilemma wrote:
Hello,
For the policy delegation protocol described in [1] I need some clarification:
1. Is reverse_client_name always present as an attribute?
No attribute is guaranteed to be present every time, but as a
practical matter this one usually is.
2. If so, is it equal to either REVERSE_DNS_LOOKUP(client_address) or
(case exactly) "unknown" (as suggested by the default_rbl_reply
section in [2])?
Yes, this is the client's rDNS hostname, or if no hostname is
found it will be "unknown". There is no differentiation
between temporary and permanent DNS failures.
This is the same hostname postfix will use in
check_reverse_client_hostname_access tables.
http://www.postfix.org/postconf.5.html#check_reverse_client_hostname_access
A client may have a rDNS hostname but still appear in the
maillog as "unknown" if the hostname could not be verified.
3. Is client_name always present as an attribute?
same as above.
4. If so, is it (case exactly) equal to either reverse_client_name (in
the case that DNS_LOOKUP(reverse_client_name) matches client_address)
or "unknown" (as suggested by the default_rbl_reply section in [2])?
This is the same client hostname postfix will record in the
maillog and will use in check_client_access tables.
http://www.postfix.org/postconf.5.html#check_client_access
Sometimes called a "verified" hostname. For explanation see:
http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
If the hostname does not exist or cannot be verified, it will
be "unknown". There is no differentiation between temporary
and permanent DNS failures.
--
Noel Jones
