November 2018 - amavis-devel

amavisd.conf: stucture/default settings
by Patrick Ben Koetter 16 Nov '18

16 Nov '18

Good morning, 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@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

2 2

How amavis reads configuration
by Patrick Ben Koetter 04 Nov '18

04 Nov '18

The way amavis reads in configuration today does not meet todays requirements: - distributions want to add their specific defaults - configuration management services want to add site/service specific without touching/breaking default configs We can ignore that. I don't want to. I suggest the following: - review amavis built-in policies and adapt as (we think to be) apropriate - provide a configuration file with documented options one would/could modify in /etc/amavisd.conf - provide a mechanism that allows distributions/config management to either - overwrite our one confguration file -> already exists - use our default conf file and try a second conf file, e.g. /etc/amavisd-local.conf -> function exists, but isn't used in amavisd.conf by default - use a directory, e.g. /etc/amavis.d/, and load *.conf -> status unknown Opinions? Comments? Ideas? p@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

3 2

Perl development styleguide
by Ralph Seichter 01 Nov '18

01 Nov '18

I use 'autopep8' for Python programming, and I wonder if there is an equivalent tool that enforces a Perl coding styleguide. Also, does such a styleguide actually exist? Perl's whole TMTOWTDI approach still makes me uncomfortable, to be honest. ;-) -Ralph

4 6

Documentation: Status Quo
by Patrick Ben Koetter 01 Nov '18

01 Nov '18

Greetings, I've spent the last two weeks working on amavis documentation. Here's a little status quo: At the moment I am not writing/rewriting the existing documentation. This will have to wait. My first goal is to make the exiting docs more useful in terms of readability (layout/structur/colouring of code examples) *and* migrate all docs to AsciiDoc to allow for better automated conversion to other output such as HTML, man pages etc. Mark's documentation is overwhelming, but it is hard to find the right section and it is inconsistent in terms of the point of view. Some docs adress operators, but most look at amavis from a programmers view. Of course that's no surprise, given Mark's Perl skills. :-) In the long run I'd like to change that view and create documentation that looks at configuring amavis from a adminstrator/operatores point of view first and then – as a second view – complements the docs by sharing developer insights. All this said, I spent my time migrating the docs from plaintext to Asciidoc. If you wonder why I went for AsciiDoc and not Markdown, please read this: https://asciidoctor.org/docs/user-manual/#compared-to-markdown Personally I'd like to add that Ralf and I wrote "The Book of Postfix" in Docbook XML by then. Since AsciiDoc basically is a reimplementation of Docbook as low markup language we get the power of Docbook and the simplicity of AsciiDoc. While I go trough the files I also cross-read the existing documentation. This way I get to know it better and this will (hopefully) serve me well when I take out to create a structure that puts the bits and pieces into place. Here's a litte email stand up meeting: == What have you completed since the last meeting? - created a branch "documentation" and begun to work in it - migrated most of the plaintext files to AsciiDoc low markup - played a lot with AsciiDoc options to come up with a general set that works for all files - ripped the SQL files apart and singled the SQL database import statements out - SQL commands to create a database and tables are now in separate *.sql files for easy use - SQL commands to populate a database with example test data is in a separate SQL file - ripped amavisd-new-docs.html apart and put the sections into separate files - begun to create/write an introduction into amavis. It's supposed to become the intro chapter that links to all other documentation == What do you plan to complete by the next meeting? - finish plaintext to AsciiDoc migration - decide on dropping a few very old documentations. Either remove them completely or move them to some kind of archive - create a list of topics and put them into some structure (sections/subsections) - assign existing documentation to the created structure - find out what parts are missing - come up with some kind of roadmap for documentation work == What is getting in your way? My laptops CTRL-Key broke the other day. This makes typing real hard. Besides that I'll probably have to look out for someone, whose experienced at creating documetation in CI runners. I've zero experience at the moment and while I'd really like to find out myself, it will probably take too long before I will find time to figure out. There are no more cycles left in my calendar this year and January will close down soon as well... p@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

1 0