[GH-ISSUE #294] Use of deprecated spam_modifies_subj field #279

New issue

Closed

opened 2026-02-27 11:10:57 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 11:10:57 +03:00

Owner

Originally created by @tonioo on GitHub (Dec 4, 2013).
Original GitHub issue: https://github.com/modoboa/modoboa/issues/294

Originally assigned to: @tonioo on GitHub.

Originally created by Antoine Nguyen on 2012-08-02T18:03:21Z

Currently, the min. required version of amavis is 2.7.0. The problem is the spam_modifies_subj SQL field was deprecated by this one but Modoboa still use it!

From the changelog :

amavisd-new-2.7.0 release notes

- retired settings $sa_spam_modifies_subj and @spam_modifies_subj_maps.
  Disabling insertion of spam tag into a Subject header field can be achieved
  by turning off the corresponding entries in %subject_tag_maps_by_ccat:
    undef $subject_tag_maps_by_ccat{CC_SPAM()};
    undef $subject_tag_maps_by_ccat{CC_SPAMMY.',1'};
    undef $subject_tag_maps_by_ccat{CC_SPAMMY()};
    undef $subject_tag_maps_by_ccat{CC_CLEAN.',1'};
  or by emptying corresponding lists of lookup tables, e.g.:
    @spam_subject_tag_maps  = ();
    @spam_subject_tag2_maps = ();
    @spam_subject_tag3_maps = ();
  or individually (by-recipient) by specifying suitable lookup tables in
  @spam_subject_tag_maps / @spam_subject_tag2_maps / @spam_subject_tag3_maps,
  either statically, or through SQL or LDAP lookups;
  Both settings are still declared for compatibility with old config files,
  but their value is ignored. An attempt to set the value of a variable
  $sa_spam_modifies_subj to a non-default value produces a warning.

README.sql-pg :

Table 'policy' received a couple of new optional fields with 2.7.0, and
dropped one field. As all fields in this table are optional and any extra
field is just ignored by amavisd, it is not necessary to update this table
unless one really needs these new fields. The following should adjust
a pre-2.7.0 schema:
  ALTER TABLE policy  ADD COLUMN unchecked_lover     char(1) default NULL;
  ALTER TABLE policy  ADD COLUMN spam_tag3_level     real default NULL;
  ALTER TABLE policy  ADD COLUMN spam_subject_tag3   varchar(64) default NULL;
  ALTER TABLE policy  ADD COLUMN disclaimer_options  varchar(64) default NULL;
  ALTER TABLE policy  ADD COLUMN forward_method      varchar(64) default NULL;
  ALTER TABLE policy  ADD COLUMN sa_userconf         varchar(64) default NULL;
  ALTER TABLE policy  ADD COLUMN sa_username         varchar(64) default NULL;
  ALTER TABLE policy DROP COLUMN spam_modifies_subj;

We need to modify the current form but do we want to integrate the three tagging levels? (ie. give users the possibility to choose the tagging policy to apply at each level)

Originally created by @tonioo on GitHub (Dec 4, 2013). Original GitHub issue: https://github.com/modoboa/modoboa/issues/294 Originally assigned to: @tonioo on GitHub. **Originally created by Antoine Nguyen on 2012-08-02T18:03:21Z** Currently, the min. required version of amavis is 2.7.0. The problem is the _spam_modifies_subj_ SQL field was deprecated by this one but Modoboa still use it! From the changelog : <pre> amavisd-new-2.7.0 release notes - retired settings $sa_spam_modifies_subj and @spam_modifies_subj_maps. Disabling insertion of spam tag into a Subject header field can be achieved by turning off the corresponding entries in %subject_tag_maps_by_ccat: undef $subject_tag_maps_by_ccat{CC_SPAM()}; undef $subject_tag_maps_by_ccat{CC_SPAMMY.',1'}; undef $subject_tag_maps_by_ccat{CC_SPAMMY()}; undef $subject_tag_maps_by_ccat{CC_CLEAN.',1'}; or by emptying corresponding lists of lookup tables, e.g.: @spam_subject_tag_maps = (); @spam_subject_tag2_maps = (); @spam_subject_tag3_maps = (); or individually (by-recipient) by specifying suitable lookup tables in @spam_subject_tag_maps / @spam_subject_tag2_maps / @spam_subject_tag3_maps, either statically, or through SQL or LDAP lookups; Both settings are still declared for compatibility with old config files, but their value is ignored. An attempt to set the value of a variable $sa_spam_modifies_subj to a non-default value produces a warning. README.sql-pg : Table 'policy' received a couple of new optional fields with 2.7.0, and dropped one field. As all fields in this table are optional and any extra field is just ignored by amavisd, it is not necessary to update this table unless one really needs these new fields. The following should adjust a pre-2.7.0 schema: ALTER TABLE policy ADD COLUMN unchecked_lover char(1) default NULL; ALTER TABLE policy ADD COLUMN spam_tag3_level real default NULL; ALTER TABLE policy ADD COLUMN spam_subject_tag3 varchar(64) default NULL; ALTER TABLE policy ADD COLUMN disclaimer_options varchar(64) default NULL; ALTER TABLE policy ADD COLUMN forward_method varchar(64) default NULL; ALTER TABLE policy ADD COLUMN sa_userconf varchar(64) default NULL; ALTER TABLE policy ADD COLUMN sa_username varchar(64) default NULL; ALTER TABLE policy DROP COLUMN spam_modifies_subj; </pre> We need to modify the current form but do we want to integrate the three tagging levels? (ie. give users the possibility to choose the tagging policy to apply at each level)