Re: Bug#320283: ITO: re2c
On Sun, May 27, 2007 at 03:30:06PM -0400, Robert Edmonds wrote: > The spamassassin just uploaded to unstable has a new feature for > compiling rulesets to native code which apparently results in a large > performance boost[0]. The sa-compile(1p) man page states that re2c > version 0.10.x is required for this functionality, and only an orphaned > 0.9.x is available in Debian. I intend to adopt re2c and upload the > latest upstream version (0.12.1). Whoops, looks like I missed that dependency on re2c >= 0.10.0 for spamassassin, but I think it's working fine with 0.9.x. (At least, I haven't found a problem with it.) I'd be happy to co-maintain the package if you would like a co-maintainer. (Though I'm not going to have much time for Debian in the next couple of weeks.) -- Duncan Findlay pgpXn9aVLoOuf.pgp Description: PGP signature
Best practices for cron jobs?
Hi everybody, What is the best practice when it comes to packages that need to access a network resource in a daily cronjob? Specifically I'd like to have a daily cronjob included in the spamassassin package that will run sa-update. I planned to do this by dropping a con job in cron.daily. As was pointed out in bug 428319, this results in many servers hitting the spamassassin update servers at 6:25 am local time (every server in a timezone that does not have anacron installed). Ideally this should be spread out throughout the course of an hour (at least). Adding a sleep $[ $RANDOM % 60 ] is probably not a good idea as it will hold up all the other cronjobs that should be run. I imagine it would be relatively simple to have the postinst generate a random time during the day for a cron script to run, but this doesn't work with anacron -- many users would never get updates. What can I do to satisfy those with and without anacron, and to avoid hammering the sa-update servers at a specific time? Thanks! -- Duncan Findlay pgpqxfJCSucpx.pgp Description: PGP signature
Re: Every spam is sacred: tagging mails because of their content or their supposed origin?
On Sun, Jun 15, 2003 at 07:45:02PM +0200, Santiago Vila wrote: > Mathieu Roy wrote: > > But I definitely find spamassassin conceptually much better - because > > it really takes a mail for what it is. It cannot be trapped. > > Because if the DNSBL one day become a major problem to spammers, who > > knows what kind of methods they may use to attack them. > > A spamassassin rule is much easier to fool than an IP address. > Not a long time ago there were a lot of spam which was "PGP-signed". FWIW, the next version of spamassassin (2.60) will have no forgeable negatively scoring rules. (ETA early-mid July) -- Duncan Findlay pgpO8jKiZXc3t.pgp Description: PGP signature
Re: Every spam is sacred: tagging mails because of their content or their supposed origin?
On Mon, Jun 16, 2003 at 10:03:45AM +0200, Josip Rodin wrote: > On Sun, Jun 15, 2003 at 11:19:10PM -0400, Duncan Findlay wrote: > > FWIW, the next version of spamassassin (2.60) will have no forgeable > > negatively scoring rules. (ETA early-mid July) > > Just out of curiosity, how will this be accomplished? The only negative rules will be: bayesian rules, bondedsender and habeas. Figuring how to autolearn ham (non-spam) is the only obstacle we still need to figure out. -- Duncan Findlay pgptieP4vqlZ2.pgp Description: PGP signature
Re: Every spam is sacred: tagging mails because of their content or their supposed origin?
On Mon, Jun 16, 2003 at 04:43:53PM -0400, Don Armstrong wrote: > On Mon, 16 Jun 2003, Duncan Findlay wrote: > > The only negative rules will be: bayesian rules, bondedsender and > > habeas. Figuring how to autolearn ham (non-spam) is the only obstacle > > we still need to figure out. > > Sure sounds like throwing the baby out with the bathwater... but I > presume you all are running statistics on email distributions... Eventually, spammers will forge any test they can. (This of course presumes that spamassassin is a big problem for spammers.) It's extreme, but necessary. All the spamassassin scores are generated with a genetic algorithm using results from about 150k spam and 150k non-spam. The scores will naturally be adjusted to compensate for the lack of negative scoring rules. Anyways, this is quite OT for debian-devel (although so is the vast majority of this thread). -- Duncan Findlay pgpeCXv0A64y5.pgp Description: PGP signature
Bug#469124: RFH: spamassassin -- Perl-based spam filter using text analysis
Package: wnpp Severity: normal I request assistance with maintaining the spamassassin package. I've been fairly slow to respond to bug reports and packaging issues, and I don't forsee this getting any better in the forseeable future. The Debian packaging efforts are coordinated in the collab-maint Alioth project Subversion tree. (See http://wiki.debian.org/Alioth/PackagingProject.) Discussion can be done throught the PTS. Be sure to read the documentation on svn-buildpackage and dpatch. If you're interested, please jump right in. Take a look at the bug list, and help forward bugs upstream (http://bugzilla.spamassassin.org), close bugs, or fix bugs as necessary. All Debian developers have access to the collab-maint tree to make changes directly (if you're not a DD, contact me). I'm happy to add interested people to the Uploaders: field once I start seeing some contributions. Please let me know if you have any questions, comments or concerns. Thanks in advance! Duncan Findlay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 10:51:46PM +0200, Jose Carlos Garcia Sogo wrote: > But the problem is that spamassassin 2 works in usual people MX systems > (which usually is your older desktop) while SA3 has a big problem in > that machines, making it unusable. > > And, BTW, since version 2.64 we have: > > - Rules backported from 3.0.0 > > So though SA3 can make other things better (bayesian and so), SA2 is > not so obsolete, and basically *works* in machines in which SA3 won't. I'm not really sure what you mean by rules backported from 3.0.0. Unfortunately, rules are fairly linked to releases. > (And my "home server" is a AMD K6-II 450, with 192MB RAM, not bad for my > own amount of daily mail) Perhaps you simply need to tune the -m option. Spamassassin has switched to a preforking model (similar to apache) rather than a spawning option, so the number specified by -m should be decreased. -- Duncan Findlay signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 10:37:04PM +0200, Steinar H. Gunderson wrote: > On Wed, Oct 06, 2004 at 10:01:12PM +0200, Sven Mueller wrote: > > ??? Since when does exim4 use SA by default? AFAIK, you have to > > specifically configure it to use it. Right? If so, there should be no > > reason to remove it or for it to conflict with SA3. > > Well, if I dist-upgrade my mail server so a new spamassassin comes in, my > mail setup breaks. Now, that is clearly broken, and an RC bug on some > package. I'm not really sure why or how your mail server breaks when a new spamassassin comes in. If you're talking about exiscan-acl included with exim4-daemon-heavy, it works fine with SpamAssassin 3. Otherwise, it must be a local modification, which I can't speak to unless I see it. > > If a program is a front-end for SA and only works if SA is installed, > > then it should keep up with any changes SA is doing to its API. > > Wrong. SA should not change its API in an incompatible fashion without also > bumping its soname (ie. the package name in this case), like any other > library. As far as I know, few programs depend on the Mail::SpamAssassin modules. Most choose to use the scripts instead. > > And SA3 API isn't _that_ much different from SA2.6 API for the most used > > interfaces. Actually, virtually any program using SpamAssassin through the modules will need to be changed. Most simply use the scripts, or spamc/spamd or the SPAMD protocol directly. (These are all fine.) > In that case, it should provide a backwards-compatible interface. This was contemplated, but deemed to be difficult and ugly. -- Duncan Findlay signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 01:22:02PM -0700, Don Armstrong wrote: > The major change that I'm aware of is the nonsensical change of 'hits' > to 'score'[1] in the output. Just provide both 'hits' and 'score' and > this particular problem will go away. [This was the major issue facing > spamass-milter, which is fixed in -7 by checking for the other if it > can't find the first.] In configuration, both 'hits' and 'score' are accepted as of right now (and this is likely to remain for a while). I don't think we were aware of much that actually parses output and searches for these strings (which are configurable anyways, AFAIK). > Don Armstrong > > 1: I'll grant that score is more logical than hit, but I really don't > see the point... The point is that we want SpamAssassin to be more user friendly, and the opportunity for making such changes is really limited to major releases. -- Duncan Findlay signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 06:43:47PM +0200, Tollef Fog Heen wrote: > * martin f krafft > > | What do you think? > > API changed generally means you bump soname. Why not for SA as well. > > Also, SA3 is useless, as it eats about half a gig of RAM on my > system. Per child. Umm... I'd like to see that Most of the time people misinterpret how much memory is using. The majority of it is shared memory, but is not reported as such by top (etc) since that only reports memory used by shared libraries. I suspect the actual memory used is a lot less than that. Furthermore, you should use the -m option to limit the number of children to something sane, like 5 or so. -- Duncan Findlay signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Wed, Oct 06, 2004 at 11:52:04AM +0200, martin f krafft wrote: > I really think spamassassin 3 should make it into Sarge, if at all > possible, and not be held up by depending packages which aren't up > to speed. I'm currently inclined to leave 2.64 in sarge (as has been my intention ever since uploading 3.0.0). While it would be nice to get spamassassin 3.0.0 in to sarge, it's too late and we'd probably need to wait until 3.0.1 anyways (3.0.0 seems to have a couple of issues that are fixed in .1). After reading the discussion, the only other option I'd consider at this moment would be putting a spamassassin3 package in sarge. Unfortunately, I don't really feel this would be particularly useful, for the same reasons spamassassin 2.64 won't be useful. SpamAssassin really needs to be kept more up to date than that. While SpamAssassin 3 will have more staying power than 2.64, it'll still go out of date well before sarge+1's release. I don't feel that people will bother upgrading from spamassassin to spamassassin3 (3.0.0) when 3.2.x is around. (I may be overestimating the speed at which spamassassin releases, but then again, woody has 2.20, which is so incredibly obsolete right now, I wonder if it does more harm than good.) The truth is a large portion of stable users rely on spamassassin backports. Packaging spamassassin3 right now is probably not all that useful. -- Duncan Findlay signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Thu, Oct 07, 2004 at 01:24:57PM +0200, Jesus Climent wrote: > On Thu, Oct 07, 2004 at 09:37:19AM +0100, Adam D. Barratt wrote: > > > > > > I'm not really sure what you mean by rules backported from > > > 3.0.0. Unfortunately, rules are fairly linked to releases. > > > > The above was a /direct/ quote from the 2.64-1 changelog: Sorry, I missed that. Only a few rules were actually backported, according to SVN. -- Duncan Findlay signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Thu, Oct 07, 2004 at 09:52:40AM +0200, Tollef Fog Heen wrote: > * Duncan Findlay > > | On Wed, Oct 06, 2004 at 06:43:47PM +0200, Tollef Fog Heen wrote: > | > * martin f krafft > | > > | > | What do you think? > | > > | > API changed generally means you bump soname. Why not for SA as well. > | > > | > Also, SA3 is useless, as it eats about half a gig of RAM on my > | > system. Per child. > | > | Umm... I'd like to see that > > 7122 root 15 0 660m 332m 4692 D 0.0 43.8 8:18.64 spamd > 7123 nobody15 0 287m 257m 4692 D 0.0 34.0 0:17.01 spamd > > | Furthermore, you should use the -m option to limit the number of > | children to something sane, like 5 or so. > > This is per child, as I wrote. A lot of that is shared, but not reported as such by top/ps due to changes in how the kernel reports shared memory. The kernel only reports memory that is used in shared libraries, I believe. More memory is shared between spamd and it's children. Other than that I don't know what to say. It doesn't seem like it should take up that much memory... FWIW, I can't really reproduce that. root 1525 0.0 1.2 27192 6696 ?-Oct05 0:00 /usr/sbin/spamd --create-prefs --max-children 5 --helper-home-dir -s local0 -d --pidfile=/var/run/spamd.pid root 1584 0.0 4.9 32944 25660 ? -Oct05 1:20 spamd child root 1585 0.0 5.0 34008 26168 ? -Oct05 1:25 spamd child root 1586 0.0 5.2 35172 26844 ? -Oct05 1:23 spamd child root 1587 0.0 4.9 32072 25332 ? -Oct05 1:46 spamd child root 1588 0.0 6.5 42180 33852 ? -Oct05 1:49 spamd child -- Duncan Findlay signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Fri, Oct 08, 2004 at 12:24:18PM +0200, Tollef Fog Heen wrote: > * Emilio Jesús Gallego Arias > > | For me sa work well: > > That doesn't help me. > > | Can you give some steps to reproduce such memory comsuption. > > Yeah, receive the mail/spam I get and you'll see it within twenty > minutes. Do you limit the size of the messages you sacn? -- Duncan Findlay signature.asc Description: Digital signature
Re: about volatile.d.o/n
On Fri, Oct 08, 2004 at 06:31:56PM +0200, Andreas Barth wrote: > Agreed. So, this means: Backport the necessary changes. Sometimes, it's > just not enough to only update the virus scanner definitions, because > new functionality is needed to scan the files (just consider that a very > new archive format gets so popular that it needs to be supported, just > like zip now). When spamassassin is upgraded, it's more than just the rules. Often the method of parsing the message is changed -- leading to better results, or support for different tests is added, etc. It would be very difficult to only backport the appropriate changes, and the result would be less stable than the version from which backporting was taking place. On the other hand, each new version makes minor changes to functionality. (Ignore 3.0.0 right now, it's got different issues all together.) To require backported changes would simply be a waste of effort and would defeat the purpose to a certain extent. > And, if there are changes that should be available on stable, but not be > the default (like e.g. the current spamassassin3), than they might get > in as new package, not disturbing the users of the old one, but giving > more choices. (Of course, even then, the package needs to be a bit more > mature than the curent spamassassin3, but that's a different thing. ;) > > > That is, some kind of "minimal change to > > preserve utility" rule, which might require the volatile-managers or > > whoever to be Real Programmers and not just compilers. Hmm.. -- Duncan Findlay signature.asc Description: Digital signature
Re: about volatile.d.o/n
On Fri, Oct 08, 2004 at 04:45:57PM -0700, Thomas Bushnell BSG wrote: > Duncan Findlay <[EMAIL PROTECTED]> writes: > > > When spamassassin is upgraded, it's more than just the rules. Often > > the method of parsing the message is changed -- leading to better > > results, or support for different tests is added, etc. It would be > > very difficult to only backport the appropriate changes, and the > > result would be less stable than the version from which backporting > > was taking place. On the other hand, each new version makes minor > > changes to functionality. (Ignore 3.0.0 right now, it's got different > > issues all together.) To require backported changes would simply be a > > waste of effort and would defeat the purpose to a certain extent. > > Nonsense. It would be harder work, and maybe there is nobody around > to do the hard work. But it is hardly impossible. Well, it's possible, but it wouldn't be stable. A version that consists only of backports is not going to have as many users, and as a result will have little testing before releasing to volatile.d.o. Unless you're saying you can find perfect programmers, a version consisting only of backports will be less stable than a new upstream version. I can understand the logic to a certain extent when there is a small set of changes, but it really doesn't work on a larger scale. > This is what stability is about. What you are calling for is > abandoning Debian's stability judgment to upstream's, in a situation > where upstream isn't making any stability promises at all. Not really. I'm just saying that there's necessarily a tradeoff and you can't have the best of both worlds. > So backport the appropriate changes only, and find programmers who can > do a good enough job not to screw it up and destabilize it. Given a large enough subset of upstream changes, any programmer will "screw it up", especially in the absence of many users testing. -- Duncan Findlay signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Tue, Nov 16, 2004 at 03:01:03PM +0100, Andreas Barth wrote: > > IMHO it only *has* to be fixed in sarge if it affects upgrades from > > 2.20, which is in stable. Otherwise, documentation on NEWS.Debian should be > > enough. It doesn't affect upgrades from 2.20 which have no Bayes at all. The only solution is documenting the issue. > I agree with you that fixing is only required if this might be a problem > for upgrades from woody. As this bug report is quite young, I think the > best thing really is to give the maintainer enough time to take a look > at it, and decide whether this needs to be fixed first (and if, how) or > not. I don't recommend 3.0.1 go into sarge. 3.0.2 will be released shortly, and that fixes a few more bugs that should make it mature enough. This bug, specifically, can only be solved by documentation as there is no reliable way for spamassassin to find every bayesian database; furthermore, it may be a violation of policy (? havent checked recently) or at least considered harmful for a maintainer script to change stuff in /home where most Bayes databases lie. Spamassassin tries to overcome this but automatically rebuilding while processing if necessary; however, this can be problematic as multiple processes try to access the same database while it's being synced, causing them to wait (often for a while). (IIRC) -- Duncan Findlay signature.asc Description: Digital signature
Re: mail bypass spamassassin
On Thu, Apr 11, 2002 at 06:52:10PM -0400, christophe barbé wrote: > I got a mail with sample.exe (2.4MB) attachment. This mail has not been > scanned by spamassassin. I don't understand why. I use a procmail rule > as below : spamassassin, by default, does not check messages larger than 250k. Messages larger than 250k take way too long to scan because of the regexps used, and large messages are rarely spam. -- Duncan Findlay pgpP3JMw8VVP7.pgp Description: PGP signature
Spamassassin 2.11 and razor 1.20
Unfortunately, there is a conflict between spamassassin 2.11 and razor 1.20, as some of you may know. Spamassassin 2.2 will be released shortly by upstream, and that version contains the fix for the issue. I do not wish to backport the fix, or upload a CVS version, as 2.2 should be coming in the next few days. Is there any way of keeping razor out of woody until spamassassin 2.2 can be uploaded? (I could file an RC bug, but is there a better solution?) As far as reports of mail loss, I don't believe this to be true, but I agree that the problem could corrupt mboxes, by adding superfluous lines. These lines could be grepped and removed; however. I may be wrong on this matter, please inform me if mail loss does actually occur. A workaround exists by either downgrading razor to 1.19 or uninstalling razor. Sorry for not informing the list earlier, this has been a very busy week. -- Duncan Findlay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: spamasassin/razor (do not upgrade)
On Thu, Apr 18, 2002 at 01:48:24PM -0700, Craig Dickson wrote: > begin Robert van der Meulen quotation: > > > Sorry, i was referring to 1.20-1 indeed. > > Interesting. 1.20-1 seemed to be working for me. However, just to be > safe, I've downgraded to 1.19-1 and marked the package "hold". > > Can we expect a fixed 1.20-2 shortly? I don't see one in Sid or incoming. > The problem is spamassassin, not razor. Sorry. Razor 1.20-1 and spamassassin 2.11-4 conflict. Spamassassin 2.20 should be released shortly, and I will upload it as soon as I can. Please hold razor at 1.19-1 iff you use spamassassin. If you just use razor, feel free to use 1.20-1. -- Duncan Findlay pgpTQpH1oEUMb.pgp Description: PGP signature
Re: Spamassassin 2.11 and razor 1.20
On Fri, Apr 19, 2002 at 01:14:07PM +0200, Robert van der Meulen wrote: > > Quoting Joey Hess ([EMAIL PROTECTED]): > > Duncan Findlay wrote: > > > Is there any way of keeping razor out of woody until spamassassin 2.2 can > > > be > > > uploaded? (I could file an RC bug, but is there a better solution?) > > > > You could simply make spamassassin conflict with the razor it doesn't > > work for, and somehow get it into woody first. Or coordinate with the > > razor author and get it to conflict with the versions of spamassassin it > > breaks. > > A couple of days should be just about enough ? Is this a valid reason to use > urgency=high on the next spamasassin upload ? > spamassassin 2.20 has been uploaded with urgency=medium. It should arrive to woody before razor does. -- Duncan Findlay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Deleting /var/cache/*
I deleted /var/cache/* today to free up some space on my /var partition. However, instead of applications re-creating the files as I expected, I recieved a bunch of error messages. apt/apt-get refused to do anything until I manually created the directory /var/cache/apt/archives/partial I also got a few messages from cron.daily: /etc/cron.daily/dwww: mkdir: cannot create directory `/var/cache/dwww/dwww-build.1008': No such file or directory run-parts: /etc/cron.daily/dwww exited with return code 1 /etc/cron.daily/man-db: fopen: No such file or directory mandb: can't create index cache /var/cache/man/1075: No such file or directory mandb: can't chmod /var/cache/man/index.bt: No such file or directory mandb: warning: can't update index cache /var/cache/man/index.bt: No such file or directory fopen: No such file or directory mandb: can't create index cache /var/cache/man/oldlocal/1075: No such file or directory mandb: can't chmod /var/cache/man/oldlocal/index.bt: No such file or directory mandb: warning: can't update index cache /var/cache/man/oldlocal/index.bt: No such file or directory fopen: No such file or directory mandb: can't create index cache /var/cache/man/X11R6/1075: No such file or directory mandb: can't chmod /var/cache/man/X11R6/index.bt: No such file or directory mandb: warning: can't update index cache /var/cache/man/X11R6/index.bt: No such file or directory Sure, these errors are relatively simple to fix, but I am wondering if they are bugs. So before I file them as such, I'd like to know is it a requirement of using /var/cache that directories and files be automatically re-created? According to FHS 5.2: Files located under /var/cache may be expired in an application specific manner, by the system administrator, or both. The application should always be able to recover from manual deletion of these files (generally because of a disk space shortage). No other requirements are made on the data format of the cache directories. True, the FHS does not specifically say that directories have to be recreated, but I would consider it a bug if they aren't. Anyone agree? -- Duncan Findlay
Re: Fwd: Please confirm your message
On Sun, Dec 01, 2002 at 07:19:47PM +0100, Gerrit Pape wrote: > On Sun, Dec 01, 2002 at 02:35:28PM +0100, Russell Coker wrote: > > The people who run such stupid filters misunderstand the way the > > Internet works. > > Maybe you should do a short research on the user of this mail handling > program before saying such. Do you really think that everyone should have to jump through hoops for the privilege of communicating with you? Are you that arrogant? > > If you have to send an extra confirmation message every time you send > > an email to someone you haven't communicated with before then it will > > increase the number of messages required by at least 50%. That is an > > unreasonable burden to place on other people. > > I wrote the software primarily for ezmlm mailing lists, please rethink > your statement with this precondition. Then, use it for mailing lists, not for your personal mail. On personal mail, it is entirely inappropriate, especially in situations like this where _you_ requested the e-mail. > On Sun, Dec 01, 2002 at 08:47:04AM -0500, Michael Stone wrote: > > Still too much. If someone initiates a communication, they should make > > sure they can get the reply. > > Yes that's true. I usually do this. I'm not responsible for the > Reply-To header in my message, the BTS mangled the headers and resent > the message; and it still appears to be from me. I've set > Mail-Followup-To correctly. I'm not interested in receiving private > copies of mail in public discussions; I know where I post, and keep up > with, in this case, the bug's history, and read debian-devel. I've noted > that you two don't want to communicate with me, be it. If you don't want the BTS mail, send it to /dev/null; don't blindly request confirmation. > On Sun, Dec 01, 2002 at 02:35:28PM +0100, Russell Coker wrote: > > PS If a spam filter blocks a message about an NMU then don't complain > > about not being warned... > > No. You receive a delivery notification, and you receive a bounce if the > delivery fails. You know that your message didn't reach the recipient. And the onus is on them to get pass your stupid filter? So in theory, I could set up my mail server to bounce mail I didn't like/agree with. So if someone e-mails me regarding a bug that I don't want to fix, I bounce it. If someone e-mails me about wanting to NMU my package, I bounce it, etc. And that way I'd be immune from people NMU'ing my package. That's BS. > On Sat, Nov 30, 2002 at 04:48:50PM +0100, Russell Coker wrote: > > For reference, I will not reply to such a message, but I will consider > > putting the entire domain in my spam filter if such messages continue. > > This is what could cause it. 'Stupid' content based spam filters > delivering false positives to /dev/null. Neither the sender nor the > recipient know about the delivery failure. What's stupid is people who are arrogant enough to think that everyone whom they communicate with should have to spend extra time (bandwidth, etc) getting their message through a filter. Plus, the assume guilty until proven innocent thing is ridiculous. What's also stupid is people who deliver messages found to be spam to /dev/null. What makes sense is to save all mail, and actually _look_ through messages tagged as spam to ensure that there are no False Positives. SpamAssassin can do this, and does it well. There are better solutions to the spam problem than yours. -- Duncan Findlay pgpFZWUxQM6wE.pgp Description: PGP signature
Re: Fwd: Please confirm your message
On Tue, Dec 03, 2002 at 09:53:56AM +1100, Brian May wrote: > On Tue, Dec 03, 2002 at 10:22:32AM +1300, Corrin Lakeland wrote: > > Personally I think bayesian based spam filters are a godsend. They're a > > bit > > naive in places such as being unigram or bigram based, but that'll probably > > get fixed in version two. And already they are still amazingly good. > > Are these packaged for Debian? The CVS version of SpamAssassin has a Bayesian type component to it. The latest CVS packages are available (and built daily by 10:00 UTC): deb http://people.debian.org/~duncf/debian/ unstable main Or you can wait till SpamAssassin 2.50 is released. Your call. IMHO, Spamassassin is better than purely bayes based filters since it only uses bayes as one component of the score, and uses many other rules to determine the overall level of spamminess. > Where can I find more information? http://www.spamassassin.org/ -- Duncan Findlay
Re: Debian conference in the US?
On Sat, May 24, 2003 at 09:57:50PM -0500, Adam Majer wrote: > PS. Personally, I would prefer to travel for a DebConf in > Cuba than in US. Really. Who wouldn't? You got the sun, the beaches and the ocean... what more could you ask for than a debconf on a beach? -- Duncan Findlay pgpeaqvWUV3fv.pgp Description: PGP signature
Re: lintian releases
On Thu, Sep 27, 2001 at 08:30:48AM +1000, Hamish Moffatt wrote: > On Wed, Sep 26, 2001 at 12:36:29PM -0500, Steve Greenland wrote: > > How is that sane? I'm parsing that as "(foo OR bar OR baz) AND foo", > > which is the same as "(bar OR baz) AND foo", right? > > Err, "(foo OR bar OR baz) AND foo" != "(bar or baz) AND foo", > because it can also be "foo AND foo" (= "foo"). > So essentially it is the same as "foo", bar and baz are irrelevant. Duncan Findlay
Re: A language by any other name
On Wed, Sep 26, 2001 at 05:32:08PM -0700, Bill Wohler wrote: > I think English should be an alias for en_US. > > Having the English think that British English is the lingua franca of > the computing world is the same as the French thinking that French > is the lingua franca of the world. It's only wishful thinking. > > British English is beautiful where it appears in poems, plays, and > novels by Shakespeare and Wilde and other brilliant English authors. > It certainly does NOT belong in the ls man page. > > Note that SAP is one of many computing companies who have > standardized on American English. They have folks from *Great > Britain* translating the German into American English. > > Similarly, I wish that Debian required that documentation and output > appear in American English as well. Inconsistent styles reduces the > professional feel of the product. > > Therefore, without emotion and with a pragmatic hand to guide me, I > feel that English should be an alias for en_US. > As a Canadian, I find it quite frustrating how Americans find that all English on the internet should be American. Further, I don't understand why Americans insist on removing the u in words like colours. But, putting my own radical beliefs aside, I think that English should definitely be an alias for en_GB, seeing how "American" really isn't "English" per se. I also think it's ridiculous that everybody be forced to write Debian documentation in American English. Debian is an international project, and only in the US is American English the standard. There are dozens of countries that use a dialect closer to British than American. BTW, you might think that Canadians use American English, after all, we are neighbours, but that's totally incorrect. I apologise, I have not been following this thread until now, so if I just said exactly what someone else said, that please feel free to ignore me. Duncan Findlay
Re: A language by any other name
On Wed, Sep 26, 2001 at 09:07:27PM -0400, Sean Middleditch wrote: > On Wed, 2001-09-26 at 20:50, Ben Burton wrote: > > > > > British English is beautiful where it appears in poems, plays, and > > > novels by Shakespeare and Wilde and other brilliant English authors. > > > It certainly does NOT belong in the ls man page. > > > > Why such emphasis? The idea is to spell words like "colour" instead of > > "color", not to write the ls man page in iambic pentameter. > > > > I am reminded of an email I saw some years ago with error messages in > > Haiku. > > > > I think I'd RTFM a lot more if the man pages *were* in Iambic > Pentameter... ~,^ I wouldn't -- I'd get kinda confused :-) Duncan
