Re: (again) Proposed Patch for Spamassassin
Michael Holzt wrote: | item leave_old_headers [0|1|2] | | Another mail server before might have checked this mail already and may have | added X-Spam-Status, X-Spam-Flag and X-Spam-Check-By lines. In general this | headers can not be trusted (may be forged by an spammer) and should be | removed from the message (which is default or parameter '0'). You may want | to opt for renaming them to X-Old-... (parameter '1') or leaving them | intact (parameter '2'). Think careful before making an decision. I still think that the patch should emulate current behavior as a default, i.e. anyone upgrading /now/ should get the current SA plugin behavior, no matter how much I prefer stripping the previous headers. I would apply the patch if you swapped your options 0 (zero) and 2 (unless I hear any vetos). John
Re: (again) Proposed Patch for Spamassassin
John Peacock [EMAIL PROTECTED] wrote: I still think that the patch should emulate current behavior as a default, i.e. anyone upgrading /now/ should get the current SA plugin behavior, no matter how much I prefer stripping the previous headers. It seems to me that the default behavior should be to emulate SpamAssassin itself, which does strip the existing X-Spam-* headers. -- Keith C. Ivey [EMAIL PROTECTED] Washington, DC
Re: (again) Proposed Patch for Spamassassin
I still think that the patch should emulate current behavior as a default, i.e. anyone upgrading /now/ should get the current SA plugin behavior, no matter how much I prefer stripping the previous headers. In my opinion the current behaviour is bad, wrong, unusual and dangerous and we should get rid of it. All known implementations of Spamassassin will by default work like the default in my patch: They will strip old lines. We should try to behave the same way like every other setup with spamassassin. -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks
Re: (again) Proposed Patch for Spamassassin
Michael Holzt wrote: I'm very certain that nobody right now uses the bug/feature that old X-Spam-Status lines are not getting removed. Reread the comment here: news://nntp.perl.org:119/[EMAIL PROTECTED] which is largely why I reverted the previous patch. If Robert is happy with the ability to preserve the headers, but having the default behavior change, I'm satisfied and would commit the change. Perhaps I am being too compulsive here; I've been working on a few patches to the Subversion project, where the compatibility guarantees are very strict (some would argue too strict). I just don't like to change the interface of the existing plugin without support from one of the other core developers... John
Re: (again) Proposed Patch for Spamassassin
If Robert is happy with the ability to preserve the headers, but having the default behavior change, I'm satisfied and would commit the change. So Robert, please make a comment on this. -kju -- It's an insane world, but i'm proud to be a part of it. -- Bill Hicks
Re: (again) Proposed Patch for Spamassassin
On 11 Oct 2004, at 19:53, John Peacock wrote: Michael Holzt wrote: I'm very certain that nobody right now uses the bug/feature that old X-Spam-Status lines are not getting removed. Reread the comment here: news://nntp.perl.org:119/[EMAIL PROTECTED] which is largely why I reverted the previous patch. If Robert is happy with the ability to preserve the headers, but having the default behavior change, I'm satisfied and would commit the change. Perhaps I am being too compulsive here; I've been working on a few patches to the Subversion project, where the compatibility guarantees are very strict (some would argue too strict). I just don't like to change the interface of the existing plugin without support from one of the other core developers... As an ex spamassassin developer, I support the change. However I don't use the plugin (SA isn't aggressive enough for me), so don't take my word as gospel. Matt.
Re: (again) Proposed Patch for Spamassassin
Matt Sergeant wrote: As an ex spamassassin developer, I support the change. However I don't use the plugin (SA isn't aggressive enough for me), so don't take my word as gospel. That's what's funny - I don't use SA any more either! I'm using dspam to great effect: Your overall accuracy is97.888% with only about 2 months training... John
Re: (again) Proposed Patch for Spamassassin
Michael Holzt wrote: So Robert, please make a comment on this. I just saw a posting from Robert on P5P: Perl5 Bug Summary -- Live from the middle of the Adriacic Sea, on the way to Greece. Perl Whirl 2004! So I wouldn't hold your breath... ;) John
Add Apache::Qpsmtpd?
Would it be worth adding Apache::Qpsmtpd to the base distro? http://www.sergeant.org/Apache-Qpsmtpd/
anti-spamassassin [was Re: (again) Proposed Patch for Spamassassin]
On 11 Oct 2004, at 20:26, John Peacock wrote: Matt Sergeant wrote: As an ex spamassassin developer, I support the change. However I don't use the plugin (SA isn't aggressive enough for me), so don't take my word as gospel. That's what's funny - I don't use SA any more either! I'm using dspam to great effect: Your overall accuracy is97.888% with only about 2 months training... Pshawww.. Bayes is *so* last year's technology :-) I have about 99.9% accuracy without bayes (or any per-user training). Though admittedly I sometimes quarantine my wife's newsletters :-) My top tips: Block anything without a Message-ID header. Block anything without any Received headers. Block anything found in CBL, SBL and SORBS. Block anything HELOing with a string matching \d+[\.-]\d+ Block anything marked bulk in DCC. That gets pretty much all my spam, though I have a few extras in there too. Matt.
Re: anti-spamassassin [was Re: (again) Proposed Patch for Spamassassin]
On 11 Oct 2004, at 21:06, John Peacock wrote: Block anything without a Message-ID header. Block anything without any Received headers. Block anything found in CBL, SBL and SORBS. Block anything HELOing with a string matching \d+[\.-]\d+ Block anything marked bulk in DCC. I'm managing a corporate e-mail system, so I have to be less arbitrary. The first two could probably be changed soon to anything without SPF/Sender-ID and without Received headers. Which would be less aggressive (those are the only two aggressive rules really) and still work quite well. Oh, I forgot two 100% zero FPs guaranteed rules: - Block anything HELOing as a domain in rcpthosts. - Block anything HELOing as my IP address. TBH, even if you're happy with dspam, stick some of these rules in front to get rid of the ABSOLUTE garbage that comes in, then let dspam mop up the rest.
