Mail Filtering Amavis, adding mail domains
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu Server Guide |
Fix Released
|
Undecided
|
Unassigned | ||
ubuntu-docs (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: ubuntu-docs
The current guide at
Ubuntu Documentation > Ubuntu 9.10 > Ubuntu Server Guide > Email Services > Mail Filtering
[ http://
includes information about configuring Amavisd-new. It says:
" ... Also, if the server receives mail for multiple domains the @local_domains_acl option will need to be customized. Edit the /etc/amavis/
But this is error-prone. When users add new domains to their postfix configuration, they are likely to forget to add those new domains to amavis. And some users have many domains on one server, so this is not exactly an easy job. So why not enable Amavis for all domains? Most users will probably want spam checks on all mail flows anyway. You can do that by setting local_domains_acl = qw(.)
Note that I have marked this as also as a security bug. Users who (understandably) forget to add new domains to the amavis config will create mail domains where recipients will receive mails which are not scanned for spam or viruses.
# to just use ALL domains, use local_domains_acl = qw(.) or maybe local_domains_acl = ('.') ,
# so you do not need to explicitly list all domains
@local_domains_acl = qw(.);
I propose to make this default behavior.
Cheers, Evert
Related branches
- Connor Imes (community): Approve
-
Diff: 72 lines (+23/-4)1 file modifiedserverguide/C/mail.xml (+23/-4)
tags: | added: serverguide |
Changed in serverguide: | |
status: | New → Confirmed |
assignee: | nobody → Leo Jackson (lajjr) |
Changed in serverguide: | |
status: | Confirmed → In Progress |
Changed in serverguide: | |
status: | In Progress → Fix Committed |
Changed in serverguide: | |
status: | Fix Committed → Fix Released |
Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.