On 2022-01-27 at 16:47:23 UTC-0500 (Thu, 27 Jan 2022 22:47:23 +0100)
Víctor Rubiella Monfort <vrubie...@cdmon.com>
is rumored to have said:
Thanks a lot Wietse and Viktor for quick and util responses!.
bent smtpprox samples are so useful it's just what i was looking for.
Consider recheck doc link on this page
http://www.postfix.org/FILTER_README.html because is not upgraded
(it's ok on http://www.postfix.org/SMTPD_PROXY_README.html).
Considering you recomendation to use milters instead of After-Queue
filters, I was reading several documentation about pros/cons, and I'm
specially worried about the delay of our antispam and antivirus
scanner introduce on process.
One issue with the Postfix docs' discussion of load and filtering delays
is that it has not much changed in many years, while the capacity of
hardware has advanced faster than the demands of handling mail. If you
use a 'defense in depth' approach with *at least* postscreen (and maybe
on-host or external firewall packet filtering) ahead of postfix's
pre-data filters (e.g. rejecting bogus envelope addresses, policy
filtering etc.) you csan safely shed MOST spam and malware mail before
any content filter sees it.
Of course you need to look at your own mail volume and handling capacity
to know whether your system will handle before-queue filtering well
(hint: RAM. Lots of RAM.) The biggest risk of before-queue filtering is
if you normally get big spikes of legitimate traffic that needs to be
content-filtered because it's not readily identified as wanted based on
network & envelope values. You can also get some benefit by splitting
"inbound" and "outbound" mail if you have significant outbound, because
you probably can require outbound to be authenticated
and do less expensive content filtering.
My VERY rough heuristic is that until a system is seeing >200k SMTP
connections per day or peaks over 20k/hour, filtering architecture isn't
going to be a problem with adequate RAM and a couple of reasonably
recent CPU cores. As a concrete example, I work with a system that sees
~500k SMTP connections per day *plus* IMAP, Webmail, & LDAP traffic with
some 25k/hr peaks, and it never breaks a load average of 1.5 on a
QEMU-KVM VM with 12GB RAM and a pair of E3-1271@3.6GHz cores, doing
before-queue SpamAssassin and ClamAV filtering. Nothing ever takes more
than a few seconds to filter. I could probably cut that RAM back to 8GB
without trouble, and there's actually more load from intensive logging
than mail filtering.
In fact I want to move to Before-Queue the lighter functionalities
of current filter. In any case I will test both aproaches in a stress
test.
Best.
El 27/1/22 a las 19:34, Wietse Venema escribió:
V?ctor Rubiella Monfort:
Hi!,
I'm working on redefine inbound mail delivery but I have some basic
"mixconceptions".
Now I have several separate inbound servers. I want to improve
deploying
MX gateway postfix gateways, improve content filtering, etc.
First of all if someone can provide some links with more info about
configuration and architecture on this kind of layered aproach
(GW->postfix->dovecot) I will be very grateful :D. (something more
than
official doc and "postfix the definitive guide book" :D)
Now I have an old perl script doing a lot of task in one filter
script,
I want to refactor and optimize it.
See my suggestions below. They are likely more secure and more
performant. It's hard to give recommendations for writing custom
code like you do.
I'm need help on concepts for "advanced content filter". First of
all,
documentation referers to Perl sample with broken link
(http://bent.latency.net/smtpprox/. )
You're looking at old documentation. The on-line doc has a link to
https://web.archive.org/web/20151022025756/http://bent.latency.net/smtpprox/
I have found quite few samples for Before-Queue filters (Milters),
but
nothing advanced samples with After-Queue filtering.
I'd suggest using Milters (i.e. before-queue) where possible, many
SPAM filters have a Milter integration (examples: mimedefang,
amavis, spamass-milter).
Wietse
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
