To me, applying policy banks as they are implemented today, is overly
complicated. In my MTA I need to filter messages and deliver them on a
dedicated port. In amavis I need to enable that port and finally I can start
creating that policy.
In my perfect world all I want is to define a policy in amavis and amavis
figures out the rest. No need to work on the MTA config and everything in one
place in amavis. Please ignore the syntax and parameter names in the following
example. Both only serve to demonstrate how I think it could work:
<amavis>
# amavis wide settings
# Globals and defaults policies can fall back to if they don't override them
# Global
$max_servers =
# Defaults
$forward_method =
$release_method =
..
$hdrfrom_notify_admin =
...
<policy abc>
Policy wide settings
$forward_method =
$release_method =
..
$hdrfrom_notify_admin =
...
# @networks
# Networks to whom the policy should be applied to.
# A MTA can either use XCLIENT or a MILTER to tell the originating clients IP.
# A message from a client within $networks is considered outgoing or
# internal if the client sends from $networks to $domains
# @domains
# A list of domains to whom the policy will be applied. A message destined to
# $domains is incoming or outgoing if the client is SMTP AUTHenticated and the
# envelope sender is within $domains
# $authenticated
# Use state of authentication derived either from Milter {auth_author},
# {auth_authen} or XCLIENT (to be expanded) to determine a message is
# "incoming"
# $port
# An incoming port that triggers usage of that policy (incoming message)
<incoming>
Policy for incoming messages e.g. accept banned files and put them into
quarantine
</incoming>
<internal>
Policy for interal messages e.g. reject banned files
</internal>
<outgoing>
Policy for outgoing messages e.g. accept banned files
<outgoing>
</policy abc>
<policy xyz>
...
</policy xyz>
</amavis>
I believe most of the functions are already in place, but the logic and config
syntax isn't. In my eyes a structure as noted above would make configuration a
lot easier.
Comments?
p...@rick
--
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.
saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>
------------------------------------------------------------------------------
Forrester recently released a report on the Return on Investment (ROI) of
Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even
within 7 months. Over 3 million businesses have gone Google with Google Apps:
an online email calendar, and document program that's accessible from your
browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
Please visit http://www.ijs.si/software/amavisd/ regularly
For administrativa requests please send email to rainer at openantivirus dot
org
