Michael,

> One more 'documentation' issue.
>
> I noticed by looking at code if you have the bounce_killer_score > 20,
> it won't ever call SA (if it thinks its a bounce).

Right.

> This might be good for the 2.6.3 documentation.

I didn't want to make too much fuss about it, thinking that
the exact value may change in the future. I'll update existing
text in 2.6.2 release notes (to be published with 2.6.3) and
document this detail.

> Also, one more thing:
> Do_log(5,....)
>
> Even with log_level=5 (and amavisd restart) I never saw any do_log(5, )
> score log entries.. I even tried some in amavisd.custom (do_log(2, works,,
> never showed up anywhee)

It was probably discarded by your syslogd settings.
You need something like
  user.debug  /var/log/amavisd-debug.log
in syslog.conf.

>From release notes:

  The following table shows mapping of SpamAssassin log levels to amavisd
  log levels, and for completeness also shows mapping of amavisd log levels
  to syslog priorities (which has not changed since previous version):

    SA     amavisd  syslog
    -----  -------  -----------
             -3     LOG_CRIT
             -2     LOG_ERR
    error    -1     LOG_WARNING
    warn      0     LOG_NOTICE
    info      1     LOG_INFO
              2     LOG_INFO
    dbg       3     LOG_DEBUG
              4     LOG_DEBUG
              5     LOG_DEBUG

> > Don't know what is the best way to clean up the mess in an SQL database
> > now. I believe turning all '1' in msgs.message_id into empty fields would
> > work.
>
> If msgs.message_id = 1 then set it to md5(timestamp?)+ seed?

I did an:

  UPDATE msgs SET message_id='' WHERE message_id='1';

(after first performing a weekly purge). Seems to do the job,
but it took a long time to run. Luckily PostgreSQL does not
block other operations meanwhite.


> I guess I am still trying to figure out why small (under the size limit),
> not whitelisted, not exempt, not spam lovers, but is backscatter email is
> getting in with a 'Hits: -,' which means amavisd didn't even look at it.
>
> The only thing I can say for every email that got back in is that it is
> backscatter (and if amavisd new doesn't send it to SA, sa vbounce won't see
> it either), and that in the msgs.message-id field, amavisd is recording a
> '1' there.  (and I don't see a one in the quarantined message, and I don't
> see duplicate message id's).

Actually I still don't know an answer to your question.
It seems to me the msgs.message-id = '1' could be a red herring.

It would be useful to see the log (at least log level 2, preferably 5)
for the affected messages.

> (I guess a positive bounce_killer_score in amavisd.conf would TRY to add
> 100 points to them? Not subtract?)

Yes, add. It usually is the only score source, as SA is normally skipped
in case of a bounce. I'll have the following in the updated release notes:

  Bounce killer is enabled by setting $bounce_killer_score to a
  large value, e.g. 100. This value is added to a final spam score if
  a message analysis determines this is a bounce to a third-party message,
  i.e. a backscatter. Spam score of genuine bounces is not affected.
  If a $bounce_killer_score value is above 20 and we know for certain
  the bounce will be killed, SpamAssassin scanning is bypassed, saving
  substantial resources when under a backscatter storm.

Mark

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
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