You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Richard Troy <rt...@ScienceTools.com> on 2023/03/01 03:46:54 UTC
The rewrite_header Subject [SPAM] directive has stopped working?!
Hi All,
I've been subscribed for ... close to 15 years, I think? Heck, 20 is maybe
possible! ... Just reading I have learned a hell of a lot, thanks to this
community, but have never posted before. Now's the time, though, because I
really need some help and am not sure where to look for it. (I've already
done the basic searches - if I've missed something, I apologize.)
Very recently our entire /var tree got wiped out due to a bug in a backup
script someone was testing, and not only on our primary system but also on
our alternate (backup) system too. Ouch! We've had to do a complete
rebuild and apply what we can from backups.
We have pretty good backups, mostly, but on /var? Well, you learn how good
your backups are when you have a disaster just like this! And, it turns
out, we didn't have a recent local.cf (or, for that matter a lot more).
(We now backup /var and EVERYTHING in /! ... Good advice, now that disk
space is dirt cheap!)
The reason for posting is ultimately that the above denoted directive was
working fine as I was trying to rebuild things - namely:
rewrite_header Subject [SPAM]
But at some point as I made some edits, SA continues to work, and honors
everything else in the file so far as I have noted so far - such as
required hits, which is directly above it - but the subject is no longer
"rewritten" to include the above noted label.
People have come to depend on it (because we don't move it to an
alternative "folder" for them) so... Presuming this is NOT the place,
where do I find help? Or, if someone just recognizes this, please do
reply! All input welcome, thanks.
I'd never bothered to try before, but since I'm here and you have the
background, and I know it's slightly off topic: Is there an easy solution
to delivering / moving spam to a specific "folder" not involving Dovecot
on a Fedora / Postfix system? I know I could pull it off by directing all
pre-mailbox delivery to a script I write myself (via the .forward
mechanism if necessary), but I just don't have the time! Private replies
welcome!
Regards ... and thanks to the list for all the great and useful materials
- just wish I could absorb it all! (I'm now trying to relearn years worth
of stuff I've forgotten because I don't use it often enough! I only run
this one site's systems as an SA!)
Richard
--
Richard Troy
<Sig thoughtfully truncated>
Re: The rewrite_header Subject [SPAM] directive has stopped working?!
Posted by Richard Troy <rt...@ScienceTools.com>.
Hmmm... I think I'm close here!
Thanks for the tip about procmail, and I was delighted to find that my
system not only has procmail already installed but there was even an
active - APPARENTLY active! - ~/.procmailrc ... that even already had
Spam Assassin setup in it?! Nice!
Here's what ha(d/s):
##############################
#:0fw
#| /usr/bin/spamassassin
:0
* ^X-Spam-Status: *Yes
* ^X-DSPAM-Result: *!Innocent
$HOME/mail/spam/
##############################
Well... The only thing I want a tiny bit different there is to send it to
Spam instead of spam, because I want to use one of them for confirmed
spam, for possible future training, and the other for suspected spam.
However, it's not actually doing anything at present...
Can someone save me from reading a heck of a lot of the docs to find out
how to configure this in WITHOUT creating a problem for using Dovecot,
too? ...We DO need Dovecot, it's just not authenticating the imap
connections properly and I just don't have time right now to focus on it.
Parking the damned spam somehow is a great help. And, this is perhaps
BETTER than gettting the subject line rewrite working again because it'll
be automagically moved for folks! Win!
Thanks much,
Richard
Re: The rewrite_header Subject [SPAM] directive has stopped working?!
Posted by Richard Troy <rt...@ScienceTools.com>.
Hi Fokls,
Before I get into the replies, so far, no solutions! More ideas?
Now, here are my responses the the replies so far:
First, thank you for all your replies! I'm avoiding replying to each by
consolidating my response to them into this one mail. Normally I delete
"all unnecessary materials," but I'll make an exception this time!
> On 2023-02-28 at 22:46:54 UTC-0500 (Tue, 28 Feb 2023 19:46:54 -0800
(PST))
> Richard Troy <rt...@ScienceTools.com>
> is rumored to have said:
>
>> Hi All,
>>
>> I've been subscribed for ... close to 15 years, I think? Heck, 20 is
>> maybe possible! ... Just reading I have learned a hell of a lot,
>> thanks to this community, but have never posted before. Now's the
>> time, though, because I really need some help and am not sure where
>> to look for it. (I've already done the basic searches - if I've
>> missed something, I apologize.)
>>
>> Very recently our entire /var tree got wiped out due to a bug in a
>> backup script someone was testing, and not only on our primary system
>> but also on our alternate (backup) system too. Ouch! We've had to do
>> a complete rebuild and apply what we can from backups.
> Date: Wed, 1 Mar 2023 09:03:44 +0100
> From: Reindl Harald <h....@thelounge.net>
>
> in other words: you don't have offsite backups on unconnected machines
> and no backup versioning - congratulations
Presuming that was intended to be helpful and not sarcastic, yes, we have
all those things and more - even spun down, removed disks and even the
occasional set of DVDs for archival... We're almost completely ready for
an EMP - which could come from a solar flair, you know!
The reality is, however, that we first created this system WAY "back in
the day" (1997, I think... it was Red Hat 1.1) and back then it wasn't
really practical to backup whole system disk trees and the focus was on
user data, which is how our backup system evolved. ... We have, for USER
data, 24 hr complete live copy of everything, 48 hrs, 72hrs, a week copy
renewed at the start of each week and a monthly copy refreshed on the
start of each month... And, these backups are kept on two separate live
systems, a primary and an alternate, with the software designed to handle
an arbitrary number of additional alternates - we are planning on at least
two alternates (for a total of three complete systems) live and ready to
go "on a moment's notice", but just haven't gotten there yet since it has
seemed to be a low priority.
In the modern era - fairly recently - we've thought that it was time to
take care of the system disk, with an emphais for a live copy as opposed
to rebuilding the OS from disaster as a top priority while we sort
through many terabytes of backups and reduce the huge number of duplicates
of a lot of the data ... How many copies of the stuff we did in 2000, do
we really need? One a month for 23 years?... And so that's been our focus
of late and THEN we were going to look at completing the rest of this
restructuring of backups. ... More funding would have helped a lot!
So, we were caught with our pants down - it's embarrassing, but we'll
live.
BTW, despte this gaff, if anyone wants to know more about how we're doing
things, which is pretty sophisticated, some of which is noted above, just
send me an email.
>> We have pretty good backups, mostly, but on /var? Well, you learn how
>> good your backups are when you have a disaster just like this! And,
>> it turns out, we didn't have a recent local.cf (or, for that matter a
>> lot more). (We now backup /var and EVERYTHING in /! ... Good advice,
>> now that disk space is dirt cheap!)
> Date: Wed, 01 Mar 2023 01:01:05 -0500
> From: Bill Cole <sa...@billmail.scconsult.com>
>
> What was local.cf doing on /var? The standard location is in
> /etc/mail/spamassassin/.
Sorry for any confusion; In short, we lost more than /var, it was just
what came to mind as I typed because the loss of it was the reason the OS
had to be rebuilt.
What happened was that in order to help offload the "system disk", an SSD,
from write loads (we don't trust them for anything but reads), things like
var got moved off the disk and the bug in the backup script (never used
for this purpose before!) was that it had the wrong case for a dash el
argument - that is it was either -l when it should have been -L, or visa
versa - and so everything below links got wiped out. Since /var is a
high-update tree, moved! ... And, as we like to keep packages together and
SA refreshes nightly via cron job, _all_ its components were moved, too...
LIKELY this is a more complicated strategy than it should have been, but
the OS wasn't designed based on this kind of concern and write loads are
scattered. In our view, at present it's harder to offload heavy write
loads completely than it should be and there ought to be a re-think of
disk usage when it comes to directory tree design for the modern 'nix
systems. As it is, doing this is rather hit-and-miss as there are few
whole trees which contain primarily write loads. blah-blah-blah... sorry
for the digression.
>> The reason for posting is ultimately that the above denoted directive
>> was working fine as I was trying to rebuild things - namely:
>>
>> rewrite_header Subject [SPAM]
>>
>> But at some point as I made some edits, SA continues to work, and
>> honors everything else in the file so far as I have noted so far -
>> such as required hits, which is directly above it - but the subject
>> is no longer "rewritten" to include the above noted label.
> Date: Wed, 1 Mar 2023 09:03:44 +0100
> From: Reindl Harald <h....@thelounge.net>
>
> from 2014:
> spamass-milter[14891]: Could not extract score from <Yes: Score=5.7,
> Tag-Level=5.0, Block-Level=10>
>
> seek for "add_header all Status" - changes here may result in some
> milter or other software processing the message can't parse it
Thanks: I get "Pattern not found: add_header" from vim. And nothing else
should be editing a thing - it's either accept or reject!
> Date: Wed, 01 Mar 2023 01:01:05 -0500
> From: Bill Cole <sa...@billmail.scconsult.com>
>
> The critical missing fact: what mechanism do you use to integrate SA
> into mail delivery? In some cases (e.g. MIMEDefang) the 'glue' layer
> actually handles header modification. In other cases, the glue may
> explicitly load its own config files and/or run as a special user with a
> bespoke user_prefs file.
We've just let the headers get marked - and subject lines - and leave it
to the mail clients, such as Thunderbird, which many of our system's users
like. ... That is, Postfix delivers as usual.
>> People have come to depend on it (because we don't move it to an
>> alternative "folder" for them) so... Presuming this is NOT the place,
>> where do I find help?
> Date: Wed, 01 Mar 2023 01:01:05 -0500
> From: Bill Cole <sa...@billmail.scconsult.com>
>
> If 'perldoc Mail::SpamAssassin::Conf' and searches of the wiki and list
> archives don't answer a question, this is the best place to come for
> help. No one can guarantee that you find a solution here, but it's the
> best place to look.
Thanks!
>> Or, if someone just recognizes this, please do reply! All input
>> welcome, thanks.
>>
>> I'd never bothered to try before, but since I'm here and you have the
>> background, and I know it's slightly off topic: Is there an easy
>> solution to delivering / moving spam to a specific "folder" not
>> involving Dovecot on a Fedora / Postfix system?
> Date: Wed, 01 Mar 2023 01:01:05 -0500
> From: Bill Cole <sa...@billmail.scconsult.com>
>
> SA knows nothing about mail delivery.
Yes, of course, and that's why I acknowledged up front that this was off
topic.
> Any solution has to be specific to whatever mechanism you use to access
> delivered mail, i.e. your IMAP server or a local MUA or ???. If you have
> an IMAP server other than Dovecot, it probably has a documented
> mechanism for non-INBOX delivery which you will need to use. Consult the
> docs for whatever you use.
We use Dovecot but are having post rebuild difficulties with it and our
imap is therefore not working ATM... We're working on it, but meanwhile,
people can log in the old fashioned way and read their mail.
> Date: Wed, 01 Mar 2023 01:01:05 -0500
> From: Bill Cole <sa...@billmail.scconsult.com>
>
> If your mailstore uses mbox or Maildir, the unmaintained antique
> software named "procmail" could be used for delivery. As an antique
> myself, I use it, but I cannot in good conscience recommend anyone else
> adopt it de novo.
> Date: Wed, 1 Mar 2023 08:52:10 +0100
> From: David Bürgin <db...@gluet.ch>
>
> It looks like procmail is maintained again, by the original author even
> (with interesting background on the procmail code, too):
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006633#24
HEY, I remember procmail! AND, I didn't have to do anything:
procmail-3.22-57.fc37.x86_64 is already installed - via being Fedora
Server, I guess?! Not sure, but OK, I can try it!
> Date: Wed, 01 Mar 2023 09:22:29 -0500
> From: Bill Cole <sa...@billmail.scconsult.com>
>
> I rescind my warning. That is very good news, as there is nothing that
> quite replaces it. Translating my personal .procmailrc to Sieve has been
> on my 'to do' list for longer than I've used SpamAssassin. Also very
> good news there from the author that he has integrated most of the
> Debian patches and fixed all of the bug backlog.
HEY, Impressive! Let's hear it for an obvious old timer still in the game,
producing useful stuff for folks!... I like to think of myself in that
category, landing my first job in computing in 1977 at the age of 14! But
I digress, sorry.
My man page says:
AUTHORS
Stephen R. van den Berg
<sr...@cuci.nl>
Philip A. Guenther
<gu...@sendmail.com>
...I'll have a cocktail and toast them later this afternoon!
Thanks for all replies,
Richard
--
Richard Troy
Re: The rewrite_header Subject [SPAM] directive has stopped working?!
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 2023-03-01 at 02:52:10 UTC-0500 (Wed, 1 Mar 2023 08:52:10 +0100)
David Bürgin <db...@gluet.ch>
is rumored to have said:
> Bill Cole:
>> If your mailstore uses mbox or Maildir, the unmaintained antique
>> software
>> named "procmail" could be used for delivery. As an antique myself, I
>> use it,
>> but I cannot in good conscience recommend anyone else adopt it de
>> novo.
>
> It looks like procmail is maintained again, by the original author
> even
> (with interesting background on the procmail code, too):
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006633#24
I rescind my warning. That is very good news, as there is nothing that
quite replaces it. Translating my personal .procmailrc to Sieve has been
on my 'to do' list for longer than I've used SpamAssassin. Also very
good news there from the author that he has integrated most of the
Debian patches and fixed all of the bug backlog.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: The rewrite_header Subject [SPAM] directive has stopped working?!
Posted by David Bürgin <db...@gluet.ch>.
Bill Cole:
> If your mailstore uses mbox or Maildir, the unmaintained antique software
> named "procmail" could be used for delivery. As an antique myself, I use it,
> but I cannot in good conscience recommend anyone else adopt it de novo.
It looks like procmail is maintained again, by the original author even
(with interesting background on the procmail code, too):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006633#24
Re: The rewrite_header Subject [SPAM] directive has stopped working?!
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 2023-02-28 at 22:46:54 UTC-0500 (Tue, 28 Feb 2023 19:46:54 -0800
(PST))
Richard Troy <rt...@ScienceTools.com>
is rumored to have said:
> Hi All,
>
> I've been subscribed for ... close to 15 years, I think? Heck, 20 is
> maybe possible! ... Just reading I have learned a hell of a lot,
> thanks to this community, but have never posted before. Now's the
> time, though, because I really need some help and am not sure where to
> look for it. (I've already done the basic searches - if I've missed
> something, I apologize.)
>
> Very recently our entire /var tree got wiped out due to a bug in a
> backup script someone was testing, and not only on our primary system
> but also on our alternate (backup) system too. Ouch! We've had to do a
> complete rebuild and apply what we can from backups.
>
> We have pretty good backups, mostly, but on /var? Well, you learn how
> good your backups are when you have a disaster just like this! And, it
> turns out, we didn't have a recent local.cf (or, for that matter a lot
> more). (We now backup /var and EVERYTHING in /! ... Good advice, now
> that disk space is dirt cheap!)
What was local.cf doing on /var? The standard location is in
/etc/mail/spamassassin/.
>
> The reason for posting is ultimately that the above denoted directive
> was working fine as I was trying to rebuild things - namely:
>
> rewrite_header Subject [SPAM]
>
> But at some point as I made some edits, SA continues to work, and
> honors everything else in the file so far as I have noted so far -
> such as required hits, which is directly above it - but the subject is
> no longer "rewritten" to include the above noted label.
The critical missing fact: what mechanism do you use to integrate SA
into mail delivery? In some cases (e.g. MIMEDefang) the 'glue' layer
actually handles header modification. In other cases, the glue may
explicitly load its own config files and/or run as a special user with a
bespoke user_prefs file.
> People have come to depend on it (because we don't move it to an
> alternative "folder" for them) so... Presuming this is NOT the place,
> where do I find help?
If 'perldoc Mail::SpamAssassin::Conf' and searches of the wiki and list
archives don't answer a question, this is the best place to come for
help. No one can guarantee that you find a solution here, but it's the
best place to look.
> Or, if someone just recognizes this, please do reply! All input
> welcome, thanks.
>
> I'd never bothered to try before, but since I'm here and you have the
> background, and I know it's slightly off topic: Is there an easy
> solution to delivering / moving spam to a specific "folder" not
> involving Dovecot on a Fedora / Postfix system?
SA knows nothing about mail delivery. Postfix only knows a few ways to
deliver mail, none of which involve delivering one recipient's mail to
multiple different places based on content.
Any solution has to be specific to whatever mechanism you use to access
delivered mail, i.e. your IMAP server or a local MUA or ???. If you have
an IMAP server other than Dovecot, it probably has a documented
mechanism for non-INBOX delivery which you will need to use. Consult the
docs for whatever you use.
If your mailstore uses mbox or Maildir, the unmaintained antique
software named "procmail" could be used for delivery. As an antique
myself, I use it, but I cannot in good conscience recommend anyone else
adopt it de novo.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire