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.rei...@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 <sausers-20150...@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.rei...@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 <sausers-20150...@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 <sausers-20150...@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 <sausers-20150...@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 <sausers-20150...@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 <dbuer...@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 <sausers-20150...@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
<s...@cuci.nl>
Philip A. Guenther
<guent...@sendmail.com>
...I'll have a cocktail and toast them later this afternoon!
Thanks for all replies,
Richard
--
Richard Troy
