Bugzilla Bug 131634

As a policy, we allow all spam to come through (D_PASS), but have amavisd-new
set to tag it as spam.  So here are the relevant lines from /etc/amavisd.conf

$final_virus_destiny      = D_DISCARD;  # (defaults to D_DISCARD)
$final_banned_destiny     = D_BOUNCE;   # (defaults to D_BOUNCE)
$final_spam_destiny       = D_PASS;     # (defaults to D_REJECT)
$final_bad_header_destiny = D_PASS;     # (defaults to D_PASS)
...
$sa_tag_level_deflt  = -999.0;
$sa_tag2_level_deflt = 5.0
$sa_kill_level_deflt = $sa_tag2_level_deflt;
$sa_dsn_cutoff_level = 9;
...
$sa_spam_subject_tag = '***SPAM*** ';
$defang_spam         = 1;

This has worked fine for years.  Since getting amavisd-new-2.4.0, however, all
spam is coming through without the subject header being modified (i.e. whereas
before the subject line would change to "***SPAM*** Buy some junk!", the
subject line is now simply "Buy some junk!"  

Interestingly, everything ELSE seems to work - the other headers are added
correctly (e.g. X-Spam-Flag: YES, X-Spam-Score: 12.626, X-Spam-Level:
************), and the spam-defang'ing takes place as it should.  It's just the
subject line that isn't modified.

I dug through the Perl of /usr/sbin/amavisd as far as I dared, and all I could
tell was that it seemed to be trying to work.  For instance, way down on line
8268, there's this snippet:
--------------------------------------------
      if ($do_subj || $do_subj_u) {
        if (defined $msginfo->orig_header_fields->{'subject'}) {
          $hdr_edits->edit_header('Subject',
                    sub { $_[1]=~/^([ \t]?)(.*)\z/s; ' '.$subject_insert.$2 });
        } else {  # no Subject header field present, insert one
...
--------------------------------------------
At this point in the code, "$do_subj" is set to "1", and "$subject_insert" is
set to "***SPAM*** ".  Whatever is going on in the $hdr_edits->edit_header()
function must not be working.

I thought maybe this bug was related to Bug 130492 , but I'm starting to think
it's not.  Just to be safe, I commented out ALL of the *_by_ccat lines, leaving
only the old-style $final_*_destiny variables.  It didn't help.  Which wasn't
surprising, since the new *_by_ccat variables were defaulting to D_PASS spam,
which is what $final_spam_destiny already had.

Anyway, my info:

Portage 2.1_pre9-r4 (default-linux/x86/2005.0, gcc-3.4.6, glibc-2.4-r1,
2.6.16-gentoo-r4 i686)
=================================================================
System uname: 2.6.16-gentoo-r4 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz
Gentoo Base System version 1.12.0_pre18
dev-lang/python:     2.4.2-r1
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r5
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild
/etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="ftp://gentoo.mirrors.pair.com/ http://gentoo.mirrors.pair.com/
http://www.gtlib.cc.gatech.edu/pub/gentoo
ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo "
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X acl alsa apache2 apm arts avi berkdb bitmap-fonts cdr cli crypt cups
curl dga directfb dri dvd dvdr eds emboss encode esd fbcon flash foomaticdb
fortran gd gdbm ggi gif gnome gphoto2 gpm gstreamer gtk gtk2 imap imlib isdnlog
java jpeg kde ldap libg++ libwww mad maildir matrox mbox mcal mikmod mmx motif
mp3 mpeg mysql nas ncurses nls odbc ogg oggvorbis opengl oss pam pcre pdflib
perl png ppds pppd python qt quicktime readline reflection samba sasl scanner
sdl session snmp spell spl sse ssl tcltk tcpd tiff truetype truetype-fonts
type1-fonts usb vorbis x86 xml xml2 xmms xorg xv zlib elibc_glibc
input_devices_keyboard input_devices_mouse kernel_linux userland_GNU
video_cards_mga video_cards_vesa video_cards_fbdev"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL,
LDFLAGS, LINGUAS

Thanks for the help!

I have just added 2.4.1 to portage, can you please try if the problem persists?
I can see couple of related things mentioned in the release notes...

A quick test seems to indicate that this is indeed fixed in 2.4.1 - the
***SPAM*** tag on the modified subject line has returned!  Thanks for your work
on this, Andrej.