On 2/8/19 1:40 PM, Patrick Ben Koetter wrote:
* Dominic Raferd <[email protected]>:
On Fri, 8 Feb 2019 at 17:17, Robert Moskowitz <[email protected]> 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@rick
