On 2/26/2012 4:55 PM, Wietse Venema wrote:
> 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.

That looks great Wietse.  I know I would have in the past, and will in
the future, find such permit logging very helpful.  But I don't recall
such a request from others.  I'd rather not be the instigator of you
wasting any development time on this if few others would want/use this
capability.  A show of hands or something would be nice--we have 2 so far.

Thanks for taking the time to analyze my feature request and consider it
for possible implementation Wietse.

-- 
Stan


Reply via email to