amavisd: uninformative policy names

[fatbear]

The policy names for anti-spam are found on the control panel as Email > Policy and include:

• Non-paying (3, 7, 10)
• Uncensored (3, 999, 999)
• Wants all spam (3, 999, 999)
• Wants viruses (3, 6.9, 6.9)
• Normal (1, 4.5, 50)
• Trigger happy (3, 5, 5)
• Permissive (3, 10, 20)

Furthermore, in the GUI on the Policy page, it would appear to most users that Non-paying, Normal, and Trigger happy are identical. The numbers in parenthesis above are not shown and are the database fields: spam_tag_level, spam_tag2_level, and spam_kill_level. This information is available if the user inspects the record more thoroughly, but this is harder for the customer to deal with.

I've looked through the amavisd documentation (the README_FILES in amavisd-new-2.8.0.tar.gz) the and there is no clear specification for what these words mean or what the ranges of values are for the various fields are, along with what those numbers mean. I can't imagine any user who "Wants all spam" or "Wants viruses", however. The wording can be improved.

So, here is what I've done to make things "better":

1. To fix the ISPConfig GUI to show better heading lines, edit the files:
   
   /usr/local/ispconfig/interface/web/mail/lib/lang/en_spamfilter_policy.lng
   /usr/local/ispconfig/interface/web/mail/lib/lang/en_spamfilter_policy_list.lng
   
   and change:
   
   'Virus lover' to 'Allow Viruses'
   'Spam lover' to 'Allow Spam'
   'Banned Files lover' to 'Allow Banned Files'
   'Bad Header lover' to 'Allow Bad Headers'
   
2. The default policies are not good because they are not intuitive and confuse customers resulting in helpdesk tickets being created that we need to answer. I deleted them all and replaced them with something I think is more sensible.
   
   I also think that the GUI is not intuitive because the sense of the filtering is backwards. Instead of showing 'allow' states, it should be showing 'block' states. That is, the heading titles should be: Block Viruses, Block Spam, Block Banned Files, and Block Bad Headers. Then, instead of showing red X's, the GUI would show green checks and vise versa.
   
   And, if the Policy page also showed next to the policy name the Spam Kill level and sorted on this with lowest numbers shown first, I think this would also improve the usability of this page because customers think in terms of a continuum from very strict protection to no protection.

If anyone is interested, I can post some SQL that, if run, will replace the default policy settings with those that I've created. Also, would the change in the sense for the GUI (block vs. allow) be of interest? If so, how would I submit a proposed change?