Nick,

> I am using a Gentoo system with amavisd-new-2.6.1-r1
> My setup uses a postgres db to determine policy. Everything seems to be
> working except the subject line tagging.
>
> My understanding is that if the spam_tag_level column value is lower than
> the score of a mail, spam headers are added, and it is safe to set this to
> -999.

Yes, provided the recipient is considered local.
X-Spam-* header fields are not inserted for outgoing mail.

Btw, undefined spam_tag_level is considered lower than any
spam level, so undef is more universal than -999.

> I also believe if the value of spam_tag2_level is lower than the 
> mail's score, the subject line is modified.

The reaching the tag2 level switches enables modifying the
Subject (and switches NO to YES in X-Spam-Flag and X-Spam-Status).
Again, only if recipient is local.

> In my case, if spam_tag_level is lower than the mail score, it modifies the
> subject. If not, it doesn't do anything to headers at all.
>
> Here's a sample log entry:
>
> Jul 28 15:49:27 rosie amavis[888]: (00888-01) SPAM-TAG, <removed> ->
> <removed>, No, score=2.754 tagged_above=-999 required=5 tests=[AWL=-0.245,
> RDNS_NONE=0.1, TVD_SPACE_RATIO=2.899]
>
> Jul 28 15:49:27 rosie amavis[888]: (00888-01) FWD via SMTP: <removed> ->
> <removed>,BODY=7BIT 250 2.0.0 Ok, id=00888-01, from MTA([127.0.0.1]:10026):
> 250 2.0.0 Ok: queued as 99E9957834D
>
> Jul 28 15:49:27 rosie amavis[888]: (00888-01) Passed CLEAN, [removed]
> [removed] <removed> -> <removed>, Message-ID: <200907281549.04136>,
> mail_id: MsiAgAGMAwg9, Hits: 2.754, size: 1464, queued_as: 99E9957834D,
> 5234 ms
>
> This message came through with ***SPAM*** in the subject. Relevant headers:
>
> X-Spam-Flag: NO
>  X-Spam-Score: 2.754
>  X-Spam-Level: **
>  X-Spam-Status: No, score=2.754 tagged_above=-999 required=5
> tests=[AWL=-0.245,
>          RDNS_NONE=0.1, TVD_SPACE_RATIO=2.899]
> Subject: ***SPAM***test001
>
>
> In case it matters, here is my db schema:
>
>         Column         |     Type     | Modifiers
> -----------------------+--------------+-----------
>  email_user_id         | integer      | not null
>  virus_lover           | boolean      | not null
>  spam_lover            | boolean      | not null
>  banned_files_lover    | boolean      | not null
>  bad_header_lover      | boolean      | not null
>  bypass_virus_checks   | boolean      | not null
>  bypass_spam_checks    | boolean      | not null
>  bypass_banned_checks  | boolean      | not null
>  bypass_header_checks  | boolean      | not null
>  spam_modifies_subj    | boolean      | not null
>  spam_tag_level        | numeric(6,2) | not null
>  spam_tag2_level       | numeric(6,2) | not null
>  spam_kill_level       | numeric(6,2) | not null
>  spam_dsn_cutoff_level | numeric(6,2) | not null
>  warnvirusrecip        | boolean      | not null
>  warnbannedrecip       | boolean      | not null
>  warnbadhrecip         | boolean      | not null
>  spam_subject_tag      | text         |
>
> Also, my policy query:
> $sql_select_policy = 'SELECT email_filters.*, users.id FROM
> email_filters,users WHERE email_filters.email_user_id = users.id AND
> users.name IN (%k)';
>
> If someone can figure out what I'm doing wrong, it would be greatly
> appreciated.


You need to set @spam_subject_tag2_maps (or $sa_spam_subject_tag) to
'***SPAM***', not the @spam_subject_tag_maps (or $sa_spam_subject_tag1).

There is one unfortunate historical inconsistency in naming
to preserve backwards compatibility as explained in release notes:


- added @spam_subject_tag_maps and @spam_subject_tag2_maps,
  to allow per-recipient spam tags string; suggested by Ed Walker;

  Note, there is an inconsistency in names of legacy variables and the
  new @*_maps, in an attempt to rectify an unfortunate choice of name
  for seldomly used variable $sa_spam_subject_tag1:
    @spam_subject_tag_maps  = (\$sa_spam_subject_tag1);  # exotic
    @spam_subject_tag2_maps = (\$sa_spam_subject_tag);   # in common use

  Note also that corresponding SQL fields are 'spam_subject_tag' and
  'spam_subject_tag2'; usually only the 'spam_subject_tag2' would be used;


Mark





------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/amavis-user 
 AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 
 AMaViS-HowTos:http://www.amavis.org/howto/ 

Reply via email to