Stan Hoeppner:
> On 2/26/2012 2:15 PM, Wietse Venema wrote:
> > Stan Hoeppner:
> >> I can't seem to find any logging of permit_dnswl_client actions. Maybe
> >> I just don't know what to grep for. I would like to be able to track
> >> such data.
> >
> > Are there any "permit" features that log their decision?
>
> No.
Reflecting Postfix origins that go back to days that most email was
not spam.
> > Hard-coding it "on" only for some would make little sense.
>
> I agree.
We have a bunch of permit actions:
all-numerical (in access maps only)
ok (in access maps only)
permit
permit_auth_destination
permit_dnswl_client
permit_inet_interfaces
permit_mx_backup
permit_mynetworks
permit_rhswl_client
permit_sasl_authenticated
permit_tls_all_clientcerts
permit_tls_clientcerts
Retrofitting is not hard if we do it right: in all access control
code that decides to permit something, replace this:
return (SMTPD_CHECK_OK);
with
return (smtpd_check_permit(state, permit_action_name,
reply_class, reply_name,
format_string, arguments...));
If the permit_action_name appears in a configurable list of permit
action names, smtpd_check_permit() would log that the named permit
action fired, along with the values of:
- reply_class (what kind of thing was permitted: client, helo,
sender, recipient, data, or end-of-data),
- reply_name (the actual value of the thing that was permitted: a
client name[address], helo argument, etc.),
- format_string+arguments with free text for additional context
(for example "whitelisted by name-of-dnsbl").
- and maybe also the client=xxx, helo=yyy, from=aaa, to=bbb
(this information is conveyed with the state argument).
This would introduce one parameter with the names of the permit
actions that need to be logged, one hash table that is indexed with
the permit action name, and one function that searches this table
to find out if the extra logging is needed.
Wietse
