I've been doing some testing of smtpd_*_restrictions utilizing a bespoke TCP table server to capture query strings against Postfix v3.5.9. In the spirit of contemporaneous practice I present the results here for you at /interface value/. Although I have read through code in the past, I did it initially here to scope testing but I didn't continue the exercise post-testing to verify the observations.
The TCP table server is a stripped-down derivative of the /Trualias/ server. I added it to the fwm branch on the offchance that someone else may find it useful for testing, or to build a custom server (which I will be doing but will likely not publish): https://github.com/m3047/trualias/blob/fwm/python/base_server.py Eventually it will get some additional cleanup / doc and I'll merge it to the main trunk. Specific findings regarding the interaction of smtpd_delay_reject, selected smtpd_*_restrictions /restrictions/, and check_*_access /actions/ are documented here: http://athena.m3047.net/pub/postfix/postfix-restrictions-actions.html (humans only, some cloud services restricted) The documentation surrounding smtpd_delay_reject suggests that there may be some way to achieve a fusion of e.g. HELO (smtpd_helo_restrictions) and MAIL FROM (smtpd_sender_restrictions) resulting in functional logic containing both, but this is merely aspirational: the query strings presented to the server are constrained by the particular check_*_access action and there is no way for the server to acquire the information which would be presented by a different action to the server. Some game with global context might be possible, but that's not a game we're playing here. (We're also not debating policy. Policy is definitionally not debatable as to its presence or absence, it is only debatable by the actual stakeholders in terms of its contents.) Actions are documented with the restriction to which they apply in _postconf(5)_, but there is no enforcement in the context of configuration: a sender action may be specified in an earlier (client connection, HELO) restriction (we'll call this a /premature action/) but this is not flagged / logged. When smtpd_delay_reject = yes then the action fires (query strings are sent to the server); when smtpd_delay_reject = no such a premature action is silently ignored, there is no logging, there is no error. Conversely a client connection action which is specified as a sender restriction (a /delayed action/) always fires regardless of the setting of smtpd_delay_reject. (If all actions can be validly specified as delayed actions, then the role of smtpd_delay_reject seems more in the spirit of mitigating sloppy configurations which contain premature actions.) Some of the differences between actions are subtle, and some of them are perhaps too subtle to detect. For instance check_client_access performs a reverse lookup of the FQDN (even if it's localhost and resolution consists of simply referencing /etc/hosts): all that's presented during connection is the client's address, yet it queries both the hostname and the address. On the other hand check_reverse_client_hostname_access would presumably have to perform a reverse lookup (this is even suggested in its name) and yet it also queries for the client address. Functionally they appear to be the same. In passing, I note that attempting to specify debug_peer_list = ::1 kicks a (delayed) syntax error. Respectfully... -- Fred Morris, internet plumber
_______________________________________________ Postfix-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
