Posted by Francis Brosnan Blázquez on January 9, 2017
Key index
Abstract
Controlling mails checked or produced by Content Filter server (Amavis) by the access policy delegation protocol (Valvula) configured at Postfix.
Introduction
Due to the way Postfix works when you configure the parameter “content filter =”, where you configure Amavis or any other Content Filter service, this makes all mail that comes in into Postfix queue, to be then sent to Amavis (or the content filter server you might have) so that mail is processed and, in turn, if everything is fine, that mail comes back to Postfix through a different internal port (typically 10025/tcp).
From here, we will assume your Content Filter service is Amavis and Valvula your policy delegation server. If it is not the case, this article is still relevant for your configuration.
Once Amavis have decided that everything is correct, that mail is sent back to postfix in a dedicated port usually declared as follow at /etc/postfix/master.cf:
# amavis connection, messages received from amavis
127.0.0.1:10025 inet n - y - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
-o receive_override_options=no_address_mappings
As you can see, any mail will be accepted on that port (10025) as long as it comes from localhost (total trust).
However, the problem we want to solve is how to deal with mails originated from within the server itself (submitted by mail/maildrop) or because a mailman installed (or some configuration produced by the Content Filter server that might produce mails by itself) to make them be also limited by your policy server (Valvula).
In that case, given the configuration above, all mails that comes in into Amavis, are not controlled by the policy server you might have installed (in this article Valvula).
What to change to make policy server be called so your policy is applied
With this information identified, in the case it is required to filter mails sent back to postfix by the Content Filter server, you can update the following parameter:
-o smtpd_recipient_restrictions=permit_mynetworks,reject
..to the following:
-o smtpd_recipient_restrictions=check_policy_service,inet:127.0.0.1:3579,permit_mynetworks,reject
This is the recommended setting with Core-Admin, where the relevant part is “127.0.0.1:3579″ and has to be updated with your local settings.
This way when Amavis finishes, that mail will have to go through Valvula when it goes back to postfix.
Interactions that might cause this configuration
This change might make Valvula (or the policy server configured) to be called twice for every mail received. First when it is received and second after Amavis finishes processing mail.
Why not configure this by default
This configuration here described might be interesting in some scenarios.
For the case of dedicated mail servers this configuration is not useful/needed. We mean “dedicated mail servers” those that do not have mailing list software, web pages or any other software that might produce mail internally that might be needed to be limited, blocked or discarded.
In the other hand, this configuration might not be interesting in all those cases where this limitation can be done in origin (updating the configuration of the service producing those mails to limit) or even using postfix’s authorized_submit_users.
In short, this is not the only configuration available to limit/control mails from inside the server using policy delegation protocol.
