Amavis not being called from postfix

[Robert Moskowitz]

On 2/8/19 1:40 PM, Patrick Ben Koetter wrote:
> * Dominic Raferd <dominic at timedicer.co.uk>:
>> On Fri, 8 Feb 2019 at 17:17, Robert Moskowitz <rgm at htt-consult.com> wrote:
>> ...
>>> I would think I want to use MILTER.
>> I too am interested in running amavis as milter (Patrick has written
>> some instructions in German), but the standard and more common setup,
>> and the one which you are emulating at present, is as content filter
>> instead, and I think you should focus on getting that working first.
> There will be a MILTER section in the upcoming docs.

Patrick,

I am going to move forward and launch with what I have working. Just a 
couple more 'nits' to improve on (e.g. Let's encrypt rather than 
self-signed and backups).  Current server has been running since 4/17 
and is long overdue replacement.  My 'old' 2 core Cubietruck running 
Redsleeve6 and my 'new' 8 core Odroid-HC1 running CentOS7.

Then I will work on improvements likemilter so I can run DKIM....

thanks.

>
>
>
>> As I understand it the disadvantages of this content filter
>> post-queue(?) approach are
>> - that mails are queued twice in the MTA [postfix] (once when it sends
>> them out to amavis, and again when they return), with two different
>> queue-ids, which is untidy and can make log tracking harder, and
>> - that the response from amavis cannot be passed back to the client
>> because the client has been told all is ok (250) when the email is
>> passed over to amavis and before amavis has processed it - but usually
>> you may not want to tell the client if you are quaranting or
>> discarding the mail it has sent.
> pre-queue::
>      Mail is scanned while the client is still in session with the MTA. The MTA
>      receives the verdict from amavis and can immediately respond to the
>      client. If the server rejects the message it was never accepted. At least
>      in Germany this is an important detail, because - from a legal point of
>      view - one would have to deliver the message to the recipient once it has
>      been accepted – even if it is spam or anything worse…
>      -> Postfix: Use smtpd_milters or smtpd_proxy_filter for pre-queue handling
> post-queue::
>      The MTA accepts the message, queues it and sends it to amavis. The
>      client/server session comes to an end. The client (sender) believes the
>      message is on its way to the recipient. Amavis classifies the message and
>      acts on the result. A late bounce may notify the sender, *but* for
>      malware/spam envelope senders are usually forged. So you end up notifying
>      the wrong person -> backscatter
>      -> Postfix: Use content_filter for post-queue handling
>
>
>> The main advantage over calling amavis as a milter is that it doesn't really
>> matter how long amavis takes to process the mail, whereas with a milter you
>> have the client still connected and waiting for a response. You can use
>> something like $child_timeout = 20; so that amavis forces any child
>> processes (esp. clamav) to give up after a given period - this isn't
>> required with the content_filter approach.
> If you use Postfix and want to use other milters, such as
> open(dkim|spf|dmarc|...) together with amavis you *have* to use milter for
> amavis, because smtpd_proxy_filter and milters don't work together. If you use
> smtpd_proxy_filter a milter can't 'see' the content - only the session. That's
> a technical limitation caused by Postfix compartmentalized architecture.
>
> p at rick
>
>
>