Re: The rewrite_header Subject [SPAM] directive has stopped working?!
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?!
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 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 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 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.
Re: The rewrite_header Subject [SPAM] directive has stopped working?!
On 2023-03-01 at 02:52:10 UTC-0500 (Wed, 1 Mar 2023 08:52:10 +0100) David Bürgin 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 b...@scconsult.com or billc...@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?!
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?!
On 2023-02-28 at 22:46:54 UTC-0500 (Tue, 28 Feb 2023 19:46:54 -0800 (PST)) Richard Troy 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 b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
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
