Re: svn commit: rev 47510 - spamassassin/trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Parker writes: On Wed, Sep 29, 2004 at 10:21:06PM -, [EMAIL PROTECTED] wrote: +- MIMEDefang: version 2.42 or later. FWIW, I completely disagree with doing this. A) It will give the impression that we support these programs (I assume there will eventually be more), B) How are we verifying that the version listed actually works? C) Is someone going to test every single release against each program we have listed to make sure the information is still valid? D) What criteria are we using to decide which programs get listed? (A) well, we *do* to a degree [*] (B) what users/devs of those tools report on the list (C) no (D) the volume of traffic from people asking these questions [*]: SpamAssassin is NOT just a mail filter. It's also a suite of perl modules to perform spam identification inside other mail filters. amavisd, MIMEDefang et al are therefore supported products into which SpamAssassin can be plugged. Therefore we have to consider what documentation will help people who use those apps in using SpamAssassin. Having said all that, I'd be +1 on taking that out of UPGRADE, replacing with a pointer to a wiki page which contains that info. - --j. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh CVS iD8DBQFBWz4wQTcbUG5Y7woRAoq6AKC5uxOr8o6AjxcLZovVxZSPnsUcKgCfcobU XzC6ZAT0rSshWXef5lIjlow= =r7+0 -END PGP SIGNATURE-
[Bug 3830] another pattern for return paths in Received: headers
http://bugzilla.spamassassin.org/show_bug.cgi?id=3830 --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 16:00 --- Tony, good question. are there cases where it appears as return-path:foo? --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3818] There is no configureable variable to disable SQL Bayes Tests
http://bugzilla.spamassassin.org/show_bug.cgi?id=3818 [EMAIL PROTECTED] changed: What|Removed |Added CC||dev@spamassassin.apache.org AssignedTo|dev@spamassassin.apache.org |spamassassin- ||[EMAIL PROTECTED] Severity|normal |enhancement --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 16:18 --- A better way than redirecting stdin is to set the environment variable PERL_MM_USE_DEFAULT to a true value (see man ExtUtils::MakeMaker). That's what I use in the Gentoo ebuild. But I guess I'll add a few additonal test parameters anyway, they won't hurt. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is.
[Bug 3817] spamd failed to restart on receiving SIGHUP (kill -HUP _pid_)
http://bugzilla.spamassassin.org/show_bug.cgi?id=3817 [EMAIL PROTECTED] changed: What|Removed |Added BugsThisDependsOn||3568 --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3568] spamd creates log file before dropping privileges
http://bugzilla.spamassassin.org/show_bug.cgi?id=3568 [EMAIL PROTECTED] changed: What|Removed |Added OtherBugsDependingO||3817 nThis|| --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3817] spamd failed to restart on receiving SIGHUP (kill -HUP _pid_)
http://bugzilla.spamassassin.org/show_bug.cgi?id=3817 [EMAIL PROTECTED] changed: What|Removed |Added BugsThisDependsOn|3568|3577 --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3577] SIGHUP to spamd doesn't work if running as non-root and using a privileged port
http://bugzilla.spamassassin.org/show_bug.cgi?id=3577 [EMAIL PROTECTED] changed: What|Removed |Added OtherBugsDependingO||3817 nThis|| --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3836] .packlist misses custom files
http://bugzilla.spamassassin.org/show_bug.cgi?id=3836 --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 16:47 --- 'I don't think the packlist is reliable, or ever has been, IIRC.' oops! incomplete comment. I mean I don't think it's been reliable for *any* perl module that installs more than .pm files; so better not to rely on it. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3747] make test fails on spamc_l
http://bugzilla.spamassassin.org/show_bug.cgi?id=3747 --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 16:53 --- Subject: Re: make test fails on spamc_l On Wed, Sep 29, 2004 at 04:43:06PM -0700, [EMAIL PROTECTED] wrote: The problem is that we can't rely on *any* port to be closed -- in the end you can bind your services anywhere which will make that test fail. Yeah, but it's unlikely non-standard services on ports 10 are going to be listening. Perhaps the error message ought to be more verbose about how port X is listening and it's not an actual error if that port is actually in use. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3836] .packlist misses custom files
http://bugzilla.spamassassin.org/show_bug.cgi?id=3836 --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 16:57 --- Yeah, but if its trivial to add that support to Makefile.PL it could be nice to do so. If it's more than, say, 10 lines of code I don't think its worth it. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3831] RegistrarBoundaries module doesn't correctly extract domains out of certain URIs
http://bugzilla.spamassassin.org/show_bug.cgi?id=3831 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #2376 is|0 |1 obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 17:04 --- Created an attachment (id=2393) -- (http://bugzilla.spamassassin.org/attachment.cgi?id=2393action=view) new version --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug 3845] spamd is unable to log to stderr w/out timestamps
http://bugzilla.spamassassin.org/show_bug.cgi?id=3845 [EMAIL PROTECTED] changed: What|Removed |Added CC||spamassassin- ||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 17:15 --- The log-to-file (of which the log-to-stderr is just a variation) is currently some kind of hack which we (erm... I) put in there to have that feature and clean it up later on. So any patches for that code are very welcome and I'll try to have a look at them when time permits :) --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3827] [review] SURBL ccTLD list updated, please update SA TLD code
http://bugzilla.spamassassin.org/show_bug.cgi?id=3827 --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 17:16 --- 'If things like SURBL are only going to list actual domains, we need to deal with that correctly.' what d'you mean -- actual registrar-boundary domains, or any domain that a spammer could possibly register, even if not with an ICANN-recognized registrar boundary? --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3747] make test fails on spamc_l
http://bugzilla.spamassassin.org/show_bug.cgi?id=3747 --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 17:17 --- Maybe at least for UNIX we could put some call to netstat in there to see if we can find any closed port and try that one? --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3831] RegistrarBoundaries module doesn't correctly extract domains out of certain URIs
http://bugzilla.spamassassin.org/show_bug.cgi?id=3831 --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 17:17 --- +1 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug 3831] RegistrarBoundaries module doesn't correctly extract domains out of certain URIs
http://bugzilla.spamassassin.org/show_bug.cgi?id=3831 --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 17:19 --- Created an attachment (id=2394) -- (http://bugzilla.spamassassin.org/attachment.cgi?id=2394action=view) domain output list diff I ran my listuri with the 3.0 code, then with the 3.1/patched code. I diffed the two and came up with this output. I checked all of the changes, and they all look right to me. there doesn't seem to be anything private in the ham domains, so I don't mind uploading it. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug 3831] [review] RegistrarBoundaries module doesn't correctly extract domains out of certain URIs
http://bugzilla.spamassassin.org/show_bug.cgi?id=3831 [EMAIL PROTECTED] changed: What|Removed |Added Summary|RegistrarBoundaries module |[review] RegistrarBoundaries |doesn't correctly extract |module doesn't correctly |domains out of certain URIs |extract domains out of ||certain URIs --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug 3805] [review] Manual whitelist for URIDNSBL lookups
http://bugzilla.spamassassin.org/show_bug.cgi?id=3805 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 01:44 --- Good catch. Theo, would you please take ne.jp off this list? --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3827] [review] SURBL ccTLD list updated, please update SA TLD code
http://bugzilla.spamassassin.org/show_bug.cgi?id=3827 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 01:57 --- Does that mean domains like medecin.fr would stay in? I think the principle of these is that doctors could register subdomains under that one, etc. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3827] [review] SURBL ccTLD list updated, please update SA TLD code
http://bugzilla.spamassassin.org/show_bug.cgi?id=3827 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 03:39 --- Is medicin.fr an official subdomain by the French NIC (whatever it is called)? (And is it actually abused?) If not, whats the difference to other (free) ccTLDs, like maybe gmxhome.de (just one which came to my mind) or somerandomprovider.fr? Just like the removed .de domains which were actually just a random list of generic words. We just can't keep an up-to-date list of every provider which offers third-level domains in our codebase, especially not in one big RE. (I must admit that I don't exactly know what this RE is used for but the above is true anyway.) For 3.0 I'm fine (aka +1) if the RE is updated as suggested. If not impossible, I'd love to see those generic-word-domains go from the list so that only the official boundaries stay, but if the SURBL code needs to have these they can stay in but that has to be fixed to something more dynamic for 3.1. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3847] Consider removing RFCI tests from SA 3.0
http://bugzilla.spamassassin.org/show_bug.cgi?id=3847 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 03:54 --- I will go away but I am sick of no one listening when I try to help reduce false positives in this program. No one wants to listen or care that someone might be going off the wall with their policies, if you all want to be this way I will leave you alone. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3847] Consider removing RFCI tests from SA 3.0
http://bugzilla.spamassassin.org/show_bug.cgi?id=3847 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 04:18 --- Fred, please don't be upset by that last comment by Matus UHLAR, he's not one of the dev team and at least on my personal record you appear as one of the positive contributors to this project. You're bug reports are always welcome. But please understand also that we sometimes might close bugs for reasons you might not like. Here Matus had a valid point: We might use the RFCI DB in a way which is not recommended by the maintainers. But in the very low input RFCI gives to the overall score of a mail it looks like it works and I'm pretty sure that mail from RP (or any other valid company which is listed in RFCI) isn't flagged as spam because of the fractions the DNS_FROM_RFC_POST test adds to their score. At least as long as their mail doesn't show any other grave spam signs. Maybe the DNS_FROM_RFC_POST should be limited to some upper border (the reliability which was discussed on the lists before) like 1.0 or 0.5 though to ensure that it won't be scored too high by the algorithm accidently. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 1201] RFE: add learning support to spamd/spamc
http://bugzilla.spamassassin.org/show_bug.cgi?id=1201 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 04:38 --- As Michael Parker wrote on 2004-06-11 09:15: I've started working on this, and have most of it done. A few questions/comments, if anyone sees a problem with assumptions of design decisions feel free to speak up. I really don't want to bother about this feature request. But as Michael Parker stated, it's already near complete. My intention to this, is i am actually in programming a complete SpamAssassin-integrated suite into Domino. To complete the project, i'll need to enable the user-based learn into bayes. Because i want to smartly integrate SpamAssassin into Domino i have to use only spamc. Would it be possible to hand over the current sources. I want to give me a try on myself to get the development process continue! Best regards. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug 3847] Consider removing RFCI tests from SA 3.0
http://bugzilla.spamassassin.org/show_bug.cgi?id=3847 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 04:47 --- Malte, I took it wrong, I get hot when trying to help and no one wants to hear me or I fail to make the point I was trying to make. That's why I spent some time trying to re-make my point in my last post. Thanks for the support, I know you close bugs for reasons we might not like, I am understanding and didn't say anything to even question Daniels actions. I realize the devs have the final word, I was leaving it alone until that last comment. Then I took time to realize i might not have made the point I wanted to make so I tried again. Thanks again! --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3847] Consider removing RFCI tests from SA 3.0
http://bugzilla.spamassassin.org/show_bug.cgi?id=3847 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 04:53 --- It doesn't matter this was for 1.6 points or 1 million points, if someone knows about a test which is FPing I always thought it was right to put the information in front of the devs. As someone else pointed out, if that was the only logic, the HTML-in-Body checks would all have to be stripped out effective immediately because they *do* false-positive. My $.02 worth as the guy who runs RFCI. :-P --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: [Bug 3848] SA 3.0 time outs with amavis+razor
Hi,
On Wed, 29 Sep 2004, Theo Van Dinter wrote:
On Wed, Sep 29, 2004 at 03:32:22PM -0500, Bob Apthorpe wrote:
If I wanted to analyzed a message using either SA 2.6x or 3.x, what do I
use to encapsulate that message aside from
Mail::SpamAssassin::NoMailAudit? That is, how do I have to change:
$self-{'_mail'} = Mail::SpamAssassin::NoMailAudit-new();
# Make a M::SA object; point to custom configs
my $spamtest = Mail::SpamAssassin-new($self-{'sa_prefs'});
# Get verdict, score, list of rules
my $status = $spamtest-check($self-{'_mail'});
so that it'll work with both SA 2.6x and 3.x?
the top of the M::SA docs have it pretty clear:
my $spamtest = Mail::SpamAssassin-new();
my $mail = $spamtest-parse( $message );
my $status = $spamtest-check( $mail );
We decided to change the API to just call parse() which will return the
appropriate object instead of calling NoMailAudit (or in 3.0, Message,) and
doing it yourself (although you can do that, the parse() method lets us change
things on the backend without having to change the published API).
So in theory, you could figure out what version you're on, then do an if/else
to call NMA or parse() appropriately.
Ok, so let me see if I have this straight:
At the head of the module where all the 'use' statements live...
use Mail::SpamAssassin;
use Mail::Header;
use Mail::Internet;
if ($Mail::SpamAssassin::VERSION 3) {
use Mail::SpamAssassin::NoMailAudit;
} else {
use Mail::SpamAssassin::Message;
}
Then later, once we've wrapped the text in fake mail headers to make
a RFC822-compliant message...
my $message =
Mail::Internet-new('Header' = $mailhead, 'Body' = $Rl_body);
# Fake up a mail message and stuff the comment in the body
if ($Mail::SpamAssassin::VERSION 3) {
$self-{'_mail'} =
Mail::SpamAssassin::NoMailAudit-new('data' =
[$message-as_string]);
} else {
$self-{'_mail'} =
Mail::SpamAssassin::Message-new({'message' =
$message-as_string});
}
And finally, analyze the message...
# Make a M::SA object; point to custom configs
my $spamtest = Mail::SpamAssassin-new($self-{'sa_prefs'});
# Get verdict, score, list of rules
my $status = $spamtest-check($self-{'_mail'});
That should gracefully handle both SA 2.x and 3.x, correct?
-- Bob
Re: svn commit: rev 47516 - spamassassin/trunk
On Thursday 30 September 2004 01:44 CET Justin Mason wrote: [EMAIL PROTECTED] writes: Author: mss Date: Wed Sep 29 16:25:24 2004 New Revision: 47516 Modified: spamassassin/trunk/MANIFEST spamassassin/trunk/MANIFEST.SKIP Log: Sort MANIFEST* alphabetically (again? maybe we should do this via a script) actually, it's better *not* to do this. 1. it makes merging the file a pain, if/when that becomes necessary If the file is sorted in each branch, merging is no issue :~) I'll do the same with the one in the branch so merging any possible changes is made easier again... Why I sort that file now and then is because it makes it much easier to see if a file is already in there or remove one which is gone. Keeping the MANIFEST up-to-date is already a PITA and an unsorted file makes it even worse (ok, there are grep and friends but I think its faster to scan the file with your eyes instead of calling some command). It would be cool if subversion could be configured in a way that the file is piped through sort on each commit. Even cooler would be if the server would check on each added or removed file if it is already in either the MANIFEST or MANIFEST.SKIP and print a warning in the commit message if not. Hmmm 2. someone else did it last time and used DIFFERENT sort semantics from yours (yours = case sensitive, theirs = case-i)! The file was *already* sorted, just using case-i. Yeah, I noticed that too late. I noticed that MANIFEST.SKIP wasnt sorted yet and just did a 'cat MANIFEST | sort' on both the files thinking that if the other wasn't sorted yet it wouldn't change anything... 3. the MANIFEST order dictates the order of files in the tarball, and in my opinion it's better to have the README, UPGRADE et al listed first. (this isn't aimed at your sorting, it's aimed at whoever sorted it last time btw) I don't see the point in maintaining any order in the tarball -- everybody and -script I know either checks out the sources or does a 'tar xvfj' on the bzipped tarball; neither the one nor the other cares about the order. But if the stuff is sorted case sensitive, the README and stuff should stay on top. Cheers, Malte -- [SGT] Simon G. Tatham: How to Report Bugs Effectively http://www.chiark.greenend.org.uk/~sgtatham/bugs.html [ESR] Eric S. Raymond: How To Ask Questions The Smart Way http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 3847] Consider removing RFCI tests from SA 3.0
http://bugzilla.spamassassin.org/show_bug.cgi?id=3847 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 07:30 --- The HTML tests do not give an e-mail 1/3 of the required score to consider it spam. 1.6 is 32% of 5.0, html tests which FP do not get scores like this. HTML_MAIL which you keep referring to has a score of: 0.001 HTML_90_100 is scored at max of: 0.346 So if I sent a 100% HTML e-mail it would score 0.347, much less than your score of 1.6 Maybe this ticket should be changed to reflect ensuring the scores for RFCI rules do not get raised too high by the scoring process. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3847] Consider removing RFCI tests from SA 3.0
http://bugzilla.spamassassin.org/show_bug.cgi?id=3847 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 07:51 --- We have all seen RBLs go down and list the world, say someone like XBL list does this, now because of RFC's known FP, David's mail might score 4.69 now we are getting much closer to having a real issue at hand. I'm looking at the future. I don't care for input unless it's helpful in some way. Stuff happens, you can sit on your rear and wait for it to happen or you can get up and do something about it. I choose to be active in helping people, do you really think you are helping anyone by listing his domain? --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3847] Consider removing RFCI tests from SA 3.0
http://bugzilla.spamassassin.org/show_bug.cgi?id=3847 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 09:07 --- Agreed with Bob. Fred - we've been partners in crime before g, so I think we can speak frankly. I agree that I've found the DESCRIPTIONS of policies at RFCI a little ... dubious. But do you have some solid stats or examples of FPs? The mass checks apparently show it SEEMS to be of value, so the onus is somewhat on you to cite specific info. OTOH I do think that if folks feel RFCI policies are discriminatory, discussion of pulling or minimizing is a valid concern. No,we don't want to be the policeman of the antispam world, but we still have a right to decide if we want to support a particular test/initiative --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3847] Consider removing RFCI tests from SA 3.0
http://bugzilla.spamassassin.org/show_bug.cgi?id=3847 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 09:19 --- I agree with you Mike Bell, no solid evidence yet, nothing to worry about. I live in a world of what-ifs too much and need to drop this thinking when it comes to certian things in life. I guess I was looking to warn the folks here of the possible unfriendly nature of the actions taken by those who effect the product we all work to improve. I am a rule writer in my world, so I look for as few FPs by any means necessary. I was thinking this would be more important than it was, I know with the RulesEmporium, if we have a rule scoring 1.6 on valid e-mail we do something about it to reduce any risk of False positives. We don't care if it happened or not, we want to avoid FPs at all cost. If it means a good rule has to be removed so be it, as long as we don't cause e-mail to be delayed / rejected / whatever. I need to better define how I react to events around me and focus my efforts on something where I can make a bigger difference. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: svn commit: rev 47516 - spamassassin/trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Malte S. Stretz writes: Why I sort that file now and then is because it makes it much easier to see if a file is already in there or remove one which is gone. Keeping the MANIFEST up-to-date is already a PITA and an unsorted file makes it even worse (ok, there are grep and friends but I think its faster to scan the file with your eyes instead of calling some command). make distcheck works for me ;) make disttest is also useful -- if a file is missing, it should cause a test to fail anyway. - --j. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh CVS iD8DBQFBXDeIQTcbUG5Y7woRAjWCAJ4oFDL80ZRaNoLEeVUjEOpNCU4CRACfaSCD NvF+wmqPaQ7UfrSvdIT7Lg8= =n0Qq -END PGP SIGNATURE-
Re: svn commit: rev 47516 - spamassassin/trunk
On Thursday 30 September 2004 18:42 CET Justin Mason wrote: Malte S. Stretz writes: Why I sort that file now and then is because it makes it much easier to see if a file is already in there or remove one which is gone. Keeping the MANIFEST up-to-date is already a PITA and an unsorted file makes it even worse (ok, there are grep and friends but I think its faster to scan the file with your eyes instead of calling some command). make distcheck works for me ;) make disttest is also useful -- if a file is missing, it should cause a test to fail anyway. Yeah, they are useful but do you call them after (or better: before) each commit? I do so before each bigger change but for small things I often simply forget it (or avoid it because it can take ages). Cheers, Malte -- [SGT] Simon G. Tatham: How to Report Bugs Effectively http://www.chiark.greenend.org.uk/~sgtatham/bugs.html [ESR] Eric S. Raymond: How To Ask Questions The Smart Way http://www.catb.org/~esr/faqs/smart-questions.html
[Bug 3847] Consider removing RFCI tests from SA 3.0
http://bugzilla.spamassassin.org/show_bug.cgi?id=3847 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 09:55 --- IIRC, we looked at this before -- the reason RFCI has a tendency to get a high score, is because it's very good at hitting the spam other rules don't hit, so the Perceptron (or GA in the past) has given it a reasonably high score compared to its FP rate. just a data-point for discussion, I haven't decided what I think about this issue yet. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3827] [review] SURBL ccTLD list updated, please update SA TLD code
http://bugzilla.spamassassin.org/show_bug.cgi?id=3827 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 10:05 --- I think I should update what the pros and cons of this listing non-ICANN-registrar domain boundaries are, since there seems to be some confusion. When we initially considered how SURBL and other RHSBL-style domain tests should work, we considered the possible abusable holes that spammers could use. This is one of them. Here's how it works: 1. if we only list ICANN-registrar domain boundaries (ie, com, co.uk, info, cn et al), then we have a smaller regexp and less maintainance 2. however, if sh.cn is a small company that offers for-free or for-pay subdelegation to third parties, and a spammer registers foo.sh.cn, but there are nonspam domains at bar.sh.cn, baz.sh.cn, we cannot list them (because we'd have to list sh.cn and hit all the nonspam domains too). in other words, we have a hole in our rules and in SURBL. 3. therefore we should list any registrar boundary where a company or organisation allows third parties to register domains under their domain, even if it's not an official one. (what is an official one anyway? do ICANN maintain a list of all the sub-ccTLD delegators, like whoever deals with registration for .co.uk, .ac.uk, et al?) So the danger is that if we cut the list down, we'll provide a hole spammers can drive through. If you all are OK with that, then fine ;) --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Wiki organization
Kenneth Porter [EMAIL PROTECTED] writes: There was a post today about recording versions of software compatible with SA3 (eg. MIMEDefang) in the Wiki. I went to look where such a thing might go and see top-level items for Using SA and Using SA with Procmail when the latter should be part of the former. But I'd hate to go mucking with the entry page (esp. as a Wiki newbie) without more discussion of direction. Does it make sense to create a new mailing list for Wiki authors? Would there be enough traffic to justify it? I'd be fine with a new mailing list for change messages and discussion. In terms of making changes, just do it. Be bold. If you want feedback, go ahead and ask, but it's better to ask for forgiveness than permission in this case. Daniel -- Daniel Quinlan ApacheCon! 13-17 November (3 SpamAssassin http://www.pathname.com/~quinlan/ http://www.apachecon.com/ sessions more)
Re: svn commit: rev 47516 - spamassassin/trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Malte S. Stretz writes: On Thursday 30 September 2004 18:42 CET Justin Mason wrote: Malte S. Stretz writes: Why I sort that file now and then is because it makes it much easier to see if a file is already in there or remove one which is gone. Keeping the MANIFEST up-to-date is already a PITA and an unsorted file makes it even worse (ok, there are grep and friends but I think its faster to scan the file with your eyes instead of calling some command). make distcheck works for me ;) make disttest is also useful -- if a file is missing, it should cause a test to fail anyway. Yeah, they are useful but do you call them after (or better: before) each commit? I do so before each bigger change but for small things I often simply forget it (or avoid it because it can take ages). before every commit where you've added or removed files. no question of that ;) - --j. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh CVS iD8DBQFBXD9iQTcbUG5Y7woRAu5fAKCtEf030gQrTrtfFXtXui8uxxeXLQCg4Wx8 8e3RNo6Qxmg6U/+K2rcOcpQ= =ZFBz -END PGP SIGNATURE-
Re: [Bug 3848] SA 3.0 time outs with amavis+razor
On Thursday 30 September 2004 18:50 CET Justin Mason wrote:
Bob Apthorpe writes:
That should gracefully handle both SA 2.x and 3.x, correct?
actually, it looks like we totally dropped the
Mail::SpamAssassin::NoMailAudit module entirely. When we were doing
this, I suggested we leave a vestigial, empty module for that in 3.0.0 to
avoid this problem, just so that the use line could still be used, but
looks like I got outvoted :( So the code has to be more complex,
unfortunately.
I can just judge from the snippet below, but...
At the head of the module where all the 'use' statements live...
use Mail::SpamAssassin;
use Mail::Header;
use Mail::Internet;
if ($Mail::SpamAssassin::VERSION 3) {
eval { require Mail::SpamAssassin::NoMailAudit; };
} else {
eval { require Mail::SpamAssassin::Message; };
}
This should be enough:
use Mail::SpamAssassin;
use Mail::Header;
use Mail::Internet;
if ($Mail::SpamAssassin::VERSION 3) {
require Mail::SpamAssassin::NoMailAudit;
}
Because Mail::SpamAssassin v3 already use()s ::Message so it's also
available for the calling code. And wrapping the stuff into eval()s
doesn't make sense because require() (in contrast to use()) is scoped so if
the block isn't reached, nothing will try to include ::NoMailAudit.
Then later, once we've wrapped the text in fake mail headers to make
a RFC822-compliant message...
# Make a M::SA object; point to custom configs
my $spamtest = Mail::SpamAssassin-new($self-{'sa_prefs'});
my $message =
Mail::Internet-new('Header' = $mailhead, 'Body' = $Rl_body);
# Fake up a mail message and stuff the comment in the body
if ($Mail::SpamAssassin::VERSION 3) {
$self-{'_mail'} =
eval { Mail::SpamAssassin::NoMailAudit-new('data' =
[$message-as_string]); };
} else {
$self-{'_mail'} =
eval { $spamtest-parse ([$message-as_string]); };
}
The eval()s aren't needed here either.
[...]
Cheers,
Malte
--
[SGT] Simon G. Tatham: How to Report Bugs Effectively
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
[ESR] Eric S. Raymond: How To Ask Questions The Smart Way
http://www.catb.org/~esr/faqs/smart-questions.html
Re: [Bug 3848] SA 3.0 time outs with amavis+razor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 actually, you're right on both; I just checked with perl -e in perl 5.8.4. I must have been thinking of java instead of perl ;) - --j. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh CVS iD8DBQFBXEEhQTcbUG5Y7woRApMlAJ4ykLqTSFEDQAwqRAlyLO1wP/q2lACgp9zn OMvd703Ss/p7/n3lSrbgRz8= =wo5U -END PGP SIGNATURE-
[Bug 3851] New: Mails sent via SMTPAuth are recognized as spam
http://bugzilla.spamassassin.org/show_bug.cgi?id=3851 Summary: Mails sent via SMTPAuth are recognized as spam Product: Spamassassin Version: unspecified Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: Rules AssignedTo: dev@spamassassin.apache.org ReportedBy: [EMAIL PROTECTED] I use SMTPAuth as SMTP proxy. This proxy adds [via SMTPAuth x.xx, bisswanger.com] to the X-Mailer header (this cannot be disabled). Yesterday I recognized that GMX deleted some of my mails, because they are recognized as spam. X-Mailer: Mozilla 4.79 [en] (Win98; U) [via SMTPAuth 0.9, [via SMTPAuth 2.00, bisswanger.com] [...] X-GMX-Antispam: 5 (Score=2.799; FORGED_MUA_MOZILLA) Then I posted the information to the SMTPAuth mailing list - and the mail got scored there, too: X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Win95; U) [via SMTPAuth 2.00, bisswanger.com] [...] X-Spam-Score: 2.7 (++) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=addgroup_id=1atid=21 0.0 SF_CHICKENPOX_MINUSBODY: Text interparsed with - 0.0 SF_CHICKENPOX_AT BODY: Text interparsed with @ 0.0 SF_CHICKENPOX_APOSTROPHE BODY: Text interparsed with ' 0.0 SF_CHICKENPOX_PERIOD BODY: Text interparsed with . 0.0 SF_CHICKENPOX_UNDERSCORE BODY: Text interparsed with _ 2.7 FORGED_MUA_MOZILLA Forged mail pretending to be from Mozilla --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3850] spamassasin with -T option consumes all memory
http://bugzilla.spamassassin.org/show_bug.cgi?id=3850 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 11:05 --- 2.63 was replaced with 2.64 and since then 3.0 was released. Also, we do not support running SpamAssassin on a Palm Pilot, even if you did get Perl to install there somehow. What, you say that you are not running on a Palm Pilot? Well, I can't tell that from your bug report. Closing as WORKSFORME --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Sequence analysis/bioinformatics
A very interesting paper at Toorcon -- the use of bioinformatics techniques to perform black-box protocol reverse-engineering. Again, this is likely to be useful for automated discovery of antispam regexp rules... worth a read: http://www.baselineresearch.net/PI/PI-Toorcon.pdf --j.
Re: [Bug 3703] clean up debugging
Justin, I need more information about what you require or need for the patches you are porting to 3.0. It seemed like you had some dbg() statements that were essentially higher in priority/severity than most others of that type. I think the best solution would be to add an info() or notice() function to sit between dbg() and warn(). That is, the level that would normally be logged via syslog or whatever, but not indicate a warning condition. -- Daniel Quinlan ApacheCon! 13-17 November (3 SpamAssassin http://www.pathname.com/~quinlan/ http://www.apachecon.com/ sessions more)
[Bug 3703] clean up debugging
http://bugzilla.spamassassin.org/show_bug.cgi?id=3703 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 13:51 --- Subject: Re: clean up debugging Justin, I need more information about what you require or need for the patches you are porting to 3.0. It seemed like you had some dbg() statements that were essentially higher in priority/severity than most others of that type. I think the best solution would be to add an info() or notice() function to sit between dbg() and warn(). That is, the level that would normally be logged via syslog or whatever, but not indicate a warning condition. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
debug facility organization
count and current name, if there's a third column, that's the proposed new facility group 164 bayes 40 dns 38 dcc 29 eval 19 locklocker 12 unlock locker 16 config 14 pyzor 14 SPF spf 12 SpamAssassinsomething else 9 plugin 9 URIDNSBLuridnsbl 8 LDAPldap 7 hashcash 6 infomaybe something else 6 accessdb 5 debug 5 awl 4 warning something else 4 metadata 4 learn maybe bayes or awl 4 decodingmessage 3 system maybe something else 3 refresh something else 3 forget learn or bayes 2 securitysomething else 2 markup 2 ignore 2 diagmaybe something else 1 untie_dbwhatever module it's in 1 tokenize bayes or token 1 token_expiration 1 tok_touch_all 1 tok_touch 1 tok_get_all 1 tok_get 1 tok_count_change 1 tie_db_writable whatever module it's in 1 tie_db_readonly whatever module it's in 1 sync_duebayes 1 syncbayes you get the idea... 1 setuid 1 set_running_expire_tok 1 set_last_expire 1 seen_put 1 seen_get 1 seen_delete 1 rewrite_header 1 restore_database 1 remove_running_expire_tok 1 refresh_lock 1 perform_upgrade 1 nspam_nham_get 1 nspam_nham_change 1 get_storage_variables 1 get_running_expire_tok 1 get_magic_re 1 facility 1 error 1 dump_db_toks 1 db_writable 1 db_readable 1 clear_database 1 cleanup 1 calculate_expire_delta 1 backup_database 1 add_score 1 Razor2 1 Mail 1 Conf 1 AWL
[Bug 3851] Mails created by Netscape Messanger 4 are recognized as spam
http://bugzilla.spamassassin.org/show_bug.cgi?id=3851 [EMAIL PROTECTED] changed: What|Removed |Added Priority|P2 |P1 --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3851] Mails created by Netscape Messanger 4 are recognized as spam
http://bugzilla.spamassassin.org/show_bug.cgi?id=3851 [EMAIL PROTECTED] changed: What|Removed |Added Severity|critical|normal Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 14:47 --- we need a sample message (with a Message-ID header) to verify this. it has nothing to do with SMTPAuth -- it's the message-ID format that's matched. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3851] Mails created by Netscape Messanger 4 are recognized as spam
http://bugzilla.spamassassin.org/show_bug.cgi?id=3851 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 14:48 --- oops, closing prematurely there --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
[Bug 3703] clean up debugging
http://bugzilla.spamassassin.org/show_bug.cgi?id=3703 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 14:50 --- Subject: Re: clean up debugging -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Quinlan writes: Do we want to require debug facilities to be registered? (A primary list in SpamAssassin.pm plus a registration function for plugins.) Pros: keeps things cleaner and more organized allows users to list current facilities Cons: minor pain By require, I mean that we'd warn() or dbg() for unknown facilities. I'm not keen on it; I think it'd be overkill. BTW regarding the number of facilities -- in my opinion if a message is output not too frequently, and/or is only output by 1 or 2 dbg() statements, a misc facility would do fine. Having too many facilities is one factor of what makes sendmail's debugging a nightmare to use. - --j. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh CVS iD8DBQFBXH+EQTcbUG5Y7woRAsJFAJ9OGUhJ9NqSp4pakz4uEzfh7lLCrgCgvU24 pFs6I2MbhEvhg5OTVsylEh0= =ZGBX -END PGP SIGNATURE- --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Bug 3851] Mails created by Netscape Messanger 4 are recognized as spam
http://bugzilla.spamassassin.org/show_bug.cgi?id=3851 --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 15:00 --- Please attach the actual complete headers of the message, doing the minimum of obfuscation that you need to preserve privacy. In this case the rule is looking at the Message-ID header, which you did not include in your excerpt. But I repeat, attach the complete set of headers, use the Create A New Attachment link in the Bugzilla page to do it, do not paste it into a comment here and especially do not just try to tell me what the Message-ID is in a reply to this comment. There may be other information necessary to track this down that would be missing if you supplied anything less thanthe complete headers as an attachment. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
