amavisd web interface

[Jeroen van Meeuwen]

On Thursday, March 29, 2012 02:58:43 PM Troy Carpenter wrote:
> I've been looking at an easier way to manage white and blacklists first
> globally for my site, then for individual users.  Right now I've moved all
> white/black list configuration to text files in the amavisd template, but of
> course I have to maintain the files myself.
> 
> I'm wondering if anyone has already extended this to make it easier for an
> admin to add/remove entries, as well as extended it on a per user basis.
> Even more, tie it into the kolab web admin interface (probably the best
> place to put that functionality given the number of possible web-based
> clients out there).
> 

Hi Troy,

You cut into a very interesting topic. Let me ponder this out loud for a bit.

A global sender whitelist/blacklist could be implemented in Postfix relatively 
easily, with for example:

  smtpd_sender_restrictions =
      check_recipient_access hash:/etc/postfix/whitelist,
      check_recipient_access hash:/etc/postfix/blacklist

Substitute the hash lookup table for something LDAP, or something SQL, and it 
can be shared between nodes real-time, and perhaps more easily administered.

A more conditional sender whitelist/blacklist on a per-user basis is a little 
more difficult.

Just a little in the sense that we have the kolabAllowSMTPSender in LDAP that 
could be used to this end - but is often used as a mandatory administrative 
policy for a user, and not editable by users themselves. This is implemented 
with the new Kolab SMTP Access Policy[1,2,3]. The downside of this 
implementation may be that it either blacklists the entire mail (for all 
recipients included in the message) or accepts the message for all recipients.

A second solution comes to mind, using Wallace[4] (something entirely new).

I think you are tapping into a third solution, one that could possible be 
implemented on top of Kolab 2.3 as well, and I suppose you are (or could be) 
using the techniques listed at [5,6]?

Could you share some more details on what it is you are doing exactly, to 
implement this?

Kind regards,

Jeroen van Meeuwen

[1] http://docs.kolab.org/en-
US/Kolab_Groupware/2.4/html/Architecture_and_Design/chap-
Architecture_and_Design-Kolab_SMTP_Access_Policy.html
[2] http://wiki.kolab.org/User:Kanarip/Draft:Kolab_SMTP_Access_Policy
[3] http://git.kolab.org/pykolab/tree/bin/kolab_smtp_access_policy.py
[4] http://docs.kolab.org/en-
US/Kolab_Groupware/2.4/html/Architecture_and_Design/chap-
Architecture_and_Design-Kolab_Content_Filters.html#sect-
Architecture_and_Design-Kolab_Content_Filters-The_Wallace_Content_Filter
[5] 
http://www.akadia.com/services/postfix_amavisd.html#Globally%20Sender%20Whitelists%20and%20Blacklists
[6] http://www.akadia.com/services/postfix_amavisd.html#Per-
Recipient%20Sender%20Whitelists%20and%20Blacklists%20%28Maia%20Mailguard%29

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/users/attachments/20120330/1ecef8a9/attachment.sig>