amavisd.conf: stucture/default settings

[Patrick Ben Koetter]

Anyone interested to share their ideas/opninions on this?

p at rick



* Patrick Ben Koetter <p at sys4.de>:
> as it is today amavisd.conf is full of options, but none of them really seem
> to make a lot of sense – at least not to newcomers. Some options are redundant
> and serve as examples. Some, belonging to the same topic, touch the surface
> only, while others go into depth.
> 
> As a whole it is hard for newbies and even for more experienced, long time
> users to come up with a setup that does exactly what they want. Many have no
> idea how powerful amavis is, because documentation and configuration file
> don't reflect this.
> 
> I'd like to change that. I want to provide newbies with a useful default
> configuration that covers their main use case by default *and* gives them
> feeling they would be capable – without any doubt – to modify settings and
> still have a functional and secure server afterwards. For the more advanced
> users I'd like to add information that gives them ideas how they could
> improve/individualize/... their setup.
> 
> To me this requires a fundamental change of amavisd.conf. I've summed up my
> toughts in the following sections.
> 
> Please comment. I'd like to get a decision on the changes I propose and start
> putting them to effect.
> 
> 
> == Parameters
> 
> 
> === Comment parameters
> 
> Any parameter in amavisd.conf should be accompanied by a brief comment that
> documents its purpose and its default behaviour.
> 
> 
> === Use new parameters
> 
> There's a pletora of configurations out there today, that uses and mixes old
> and new parameters. Usually the new ones provide better/more functionality. I
> would like to establish and propagate the new ones.
> 
>     .example: socket configuration
>     remove: inet_socket_port
>     add:    listen_sockets
> 
> 
> === Administrator view
> 
> amavis' configuration file is pure Perl. You can add program code to it and it
> will be executed. This is useful if you are a programmer, but it also
> complicates things if you an administrator, whose Perl is not so fluent. The
> majority of amavisd.conf users are administrators.
> 
> I'd like to deliver a configuration file that looks at amavis how they see the
> world, i.e. group options by content class and not by function.
> 
> I'd like to single out options from *_maps_by_ccat and place them into
> sections where they belong e.g. spam related options from *_maps_by_ccat into
> a spam setting dedicated section.
> 
> 
> == Structure
> 
> As of today amavis.conf loosely enforces a structure adding "COMMONLY ADJUSTED
> SETTINGS" as a section and "OTHER MORE COMMON SETTINGS".
> 
> My goal is to improve readability and reduce errors adding sections that help
> to "to jump through the document and scan options" looking for the right
> setting to modify.
> 
> I'd also like to remove anything that distracts attention, e.g. rarely used
> options. The noise should go and the signal should remain only.
> 
> Here's a rough structure I have on my mind (I've been using it with success as
> an amavis trainer throughout the last years):
> 
> .proposed new amavisd structure
> ----
> Server settings
>     identity
>     @listen_sockets
>     nr. instances
> Logging
>     type
>     template
> destinations
>     @local_domains_maps
>     @mynetworks
> policy mappings
>     interface_policy
>     client_ipaddr_policy
>     author_to_policy_bank_maps
> notifications
>     mailfrom_notify_*
>     hdrfrom_notify_*
> Quarantine settings
>     release_format
>     ...
>     notify_release_templ
> IP reputation
> Virus policy (default)
>     scanners
>     ...
> Spam policy (default)
> Banned policy (default)
> Bad Header policy (default)
> Undecipherable policy (default)
> DKIM
>     verification
>     signing
> Policy banks
>     MYNETS
>     submission
>     whitelists
>     AM.PDP
> ----
> 
> 
> == Default policies
> 
> Distributions add their own default policies. Regardless of what they do I'd
> like to review amavis' current policies and modify them (if required).
> 
> 
> === pre-queue by default
> 
> In most countries it is illegal to accept messages for transport first but not
> deliver them later, e.g. because the policy for viruses says to discard
> messages containing malware.
> 
> I'd like to ship amavis with a configuration that has been optimized for
> pre-queue filtering (and documentation addressing pre- and post-queue
> policies).
> 
> 
> === localhost by default
> 
> A content filter (framework) should not be reachable outside the host it runs
> on *unless* someone decides to change that on purpose.
> 
> Back when I was using $inet_socket_port to establish ports amavis would - due
> to limitations of Net::Server - listen on any network interface provided by
> the host and I had to firewall the service in order to allow local sockets
> only.
> 
> Eversince Mark came up with @listen_sockets, which may replace
> $inet_socket_port, this isn't necessary anymore. @listen_sockets allows to
> configure ip:port mappings. I want it to be 127.0.0.1:10024 by default.
> 
> 
> 
> Regards,
> 
> p at rick
> 
> -- 
> [*] sys4 AG
>  
> https://sys4.de, +49 (89) 30 90 46 64
> Schleißheimer Straße 26/MG,80333 München
>  
> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
> Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
> Aufsichtsratsvorsitzender: Florian Kirstein
>  

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein