Friends, What would be valuable (or at least interesting) to me is to treat the RDNS lookup (peer address->name and subsequent name->address) as a part of smtpd_client_restrictions, or in some way delay it until that time. Currently, it seems that both of the above lookups take place before any smtpd_client_restrictions processing even begins, which means that two DNS queries are made [I won't say that postfix makes them since that seems to provoke some ire, but it does cause them to be made on its behalf via a call to gethostbyaddr()], which in some cases could be avoided, thus saving reducing traffic. For example, I eliminate >85% of my incoming email at "RCPT TO" time via a local access(5) map for valid/invalid recipients (smtpd_recipient_restrictions's check_recipient_access), which generates no external traffic; since I use "smtpd_delay_reject = yes", I defer RBL lookups (which also consume network resources since I don't locally mirror any RBLs) until after receipt of the "RCPT TO" and subsequent recipient-check; but I am not able to defer the peername lookup without turning off smtpd_peername_lookup entirely, which I assume disables the use of, e.g., reject_unknown_client_hostname (whether or not this is true is ambiguous at best in the postconf(5) documentation for my version, 2.5.5, which might be an example of what Steve refers to as incomplete documentation).
I suspect that eliminating 3 or 4 DNS query packets and the same number of DNS result packets outweighs the additional traffic of receiving HELO, MAIL FROM: and RCPT TO: (and resultant TCP ACKs), and it definitely would save on traffic for me since I will delay-reject in any case, to reduce the number of queries to the RBL. If the peername lookup could be specified (in order) as a part of smtpd_client_restrictions (smtpd_helo_restrictions, smtpd_recipient_restrictions, etc. when smtpd_delay_reject is turned on), it would allow me to check my local invalid-recipient map and reject the majority of incoming connections without two external PTR lookups while preserving the ability to check the peername validity for incoming connection with a valid recipient. Of course, the reverse-resolved peername is sometimes needed as part of client restrictions, so another strategy is "lazy resolution", delaying resolution until needed, i.e. during/after client restrictions processing. If I understand Steve's problem correctly, wouldn't this furthermore solve it, since he could specify permit_mynetworks prior to reject_unknown_client_hostname (or perhaps a new "pseudo-restriction" to specify lookup without rejection like "lookup_client_hostname") in smtpd_client_restrictions? Of course, I haven't gone through the code with a fine-toothed comb, so there may perhaps be something taking place between the peername lookup (looks to me to be very early on, in smtpd_peer_init(), called from smtpd_state_init()) and the later checks (e.g. client-check in smtpd_check_client(), called from smtpd_proto()) that might require the reverse-resolved peername, but (1) it currently may not be available if smtpd_peername_lookup is turned off, and (2) if needed, the "lazy-resolve" method would retrieve it "just in time." Cheers, David
