March 2019 - amavis-devel

Merge request approvals
by Ralph Seichter 13 Jun '19

13 Jun '19

Hello folks, I have mentioned this individually before, but I'd like to point out here as well that we have not yet decided who may approve GitLab merge requests. Please don't be surprised or annoyed if you have contributed a MR and don't see it move forward. Thanks. -Ralph

2 2

Splitting amavis: The master plan ;-)
by Patrick Ben Koetter 26 Mar '19

26 Mar '19

Greetings, we decided to split amavis. Now we need to do it. This raises a few questions (at least to me): - What do we split amavis into? - How do we split amavis? - How will we use the packages? - Who will be affected? - Who will split amavis? - Where will we push the splitted version to? = What do we split amavis into? My (naive) understanding is, we will split amavis into several packages. These packages will be libraries. The libraries will be pushed to CPAN, where they can be downloaded by those who want to install amavis by themselves or package maintainers, who want to ship these libraries with an OS/distribution. I can see that e.g. DKIM code may become a libary. OTOH I don't see notification or log templates become a library. But they should exported to external files too, I think. Would we ship those templates as separate files that come along with the amavis TARball, while libraries are on CPAN? Who will sit down and identify the code sequences that should be extracted? And who will propose which should come along with the tarball and which should go to CPAN? = How do we split amavis? I guess someone will write a script that extracts the code sequences from amavis and exports them to files. Then someone will add code into amavis that references and loads those packages. This raises the question, if all packages should be loaded at the start or only if they provide functionality that has been activated by configuration. To me it seems more secure to load functionality and code only when it is required. = Who will be affected? Once we know what we want to export and where to put the templates/libraries we will know who will be affected. I assume it will affect those who want to install amavis and/or provide ready to install amavis packages. Would it make their lives easier if we provided a list of modules that need to be downloaded? = Who will split amavis? Markus Benning created the issue to split amavis. I assume he will also do the actual split. (@Markus: Will you?). Who will review the result? I lack the skills to review perl code. = Where will we push the splitted version to? This is probably a question that has been raised and answered before. The libraries will go to CPAN. Correct? 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

Splitting amavis in separate files/libraries
by Patrick Ben Koetter 22 Mar '19

22 Mar '19

Good Morning, Markus sent a WIP merge request asking to split amavis into separate files/libraries with the goal to put them on CPAN. https://gitlab.com/amavis/amavis/merge_requests/6 Reducing the size of the rather large amavis file was one of the first issues we discussed on this list. I'd like to take this discussion to a point where we can reach a conclusion and act on it. As far as I can remember nearly everyone consented to split amavis into a main program and a collection of libraries. Are there any opinions that suggest we do not split amavis? If not then I'd like to start talking about how we'd split amavis, what we need to provide to package maintainers to make it as easy as possible to follow that major change and other details we should look out for. Which come to mind? So please take a few minutes, think about it and raise your voice. 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

amavis documentation
by Patrick Ben Koetter 21 Mar '19

21 Mar '19

Good Morning, I'm still short on time, but I've been working on amavis documentation now and then when time permitted to do so. There are a few changes I want to discuss before I take this further: == Subproject I'd like documentation to become a subproject of the main amavis branch. Being reduced to the documentation code only will make it easier to handle all the transformation that doc code needs to go through before it becomes available in various formats. This said I created <https://gitlab.com/amavis/docs.amavis.org> a few minutes ago. It holds what I am currently are working on. Does anyone feel uncomfortable with the docs becoming a subproject? == Coverage There already is quite a lot of documentation available. It is focussed on functionality and how it was implemented, with a few exceptions (e.g. DKIM) where it also explains how to get things done. I'd like to put a stronger emphasis on "getting things done". My intent is to provide at least as much information as it takes to mobilize people to a point where they think: "Hey, I can do that." == Structure This said I've begun to work on a general "amavis" document that states what amavis is and then tries to route readers into the right directions. Ideally this will become the main starting point in the future. The main directions I'm currently thinking of are: Setup:: How to install and run amavis on a computer. Configuration:: How to configure specific aspects of amavis. Integration:: How to integrate amavis into an MTA. Operation:: How to work with amavis on a server. Understanding amavis:: How amavis processes email. === Setup The setup section will cover what it takes to install amavis on your server if you download the sources from our website/repos. Before that it should point people to the various distribution specific packages that provide amavis as they will probably provide better/simplier integration that works with the system from the start. === Configuration The Configuration section should explain the syntax used to configure amavis. It should also tell people how to use routines that help e.g. to read in external data (read_hash). Now that readers would know about the means they have at hands they should set their mind on what they want to do. I'd like to give them $something to read into "content policies". Maybe thoughts on filtering, a collection of best practices and/or architectural examples to get this or that done. I haven't really set my mind on a particular approach yet and I'm open to suggestions. Then there should be a part that deals with amavisd.conf. It should explain the sections this config file will consist of and what they configure. === Integration This section should address how people can integrate amavis into their mail flow. There are serveral documents there already, but they are very different in depth and how much they explain. Some are plain cut & paste from Mailing list threads. I'd like to update all of them. Working on integration into Postfix myself seems natural to me. If someone wants to join in, please raise your voice. As for the other MTAs I will try to reach out to others. I've no idea how to integrate amavis with Exim. The website says " The last 3.x release was 3.36. It is obsolete and should not be used." So I will remove all docs pointing to 3.x soon. How many people are still using Sendmail? I really don't know and I'd like to find out if we should maintain documentation for Sendmail. (If you are a Sendmail user, speak up. I'll be happy to maintain docs if it makes sense.) Any other MTAs we should address? === Operation This section deals with daily routines. Stale files in $TMPDIR, reading and interpreting LOG, database cleanup/stats etc. pp. If you know of something you'd like to find in here, drop me a note or create an issue at <https://gitlab.com/amavis/docs.amavis.org/issues>. === Understanding amavis Understanding amavis aims to give the reader an idea how amavis works. What's amavis' system metaphor? What are the steps each message handed over to amavis goes through? Why, for example, would amavis unpack a message and it's MIME parts *before* it hands it down to various content classifiers? Speaking of "classifiers". This section should also set and explain the terminology we want to use throughout the project: content filte framework, classifier, content classes, policy bank etc. pp. One of the goals of this section is to help people create an inner model of amvis workings. When things go wrong and they need to debug they should be able to walk that inner model and think: "It should be doing this at the moment, but it doesn't. What could be the reason why it fails at exactly this step?" That's it for know. I'm curious about feedback. 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 3