Re: [cjwatson@debian.org: Re: Fwd: Processing of ferret_3.0-2_i386.changes]
On Tue, Sep 23, 2003 at 12:14:02AM +0100, James Troup wrote: > The queue daemon can no longer handle PGP 2.x keys; I don't know why > and since a) the number of developers still using these kind of keys > for uploads can be counted on the fingers of a mutilated hand, b) > there are alternative methods of uploads available to the few who do, > c) queued is in perl and d) has plenty of other more vicious bugs, I > haven't done anything about it. If anyone else cares to fix it, feel > free to send me a tested patch. Well, we all know how vigorously active Brian White has been since around the time GPG hit 1.0... He may not have even heard that the RSA patent expired, or about that court case...what was it? "_Bush v. Gore_"? -- G. Branden Robinson| The key to being a Southern Debian GNU/Linux | Baptist: It ain't a sin if you [EMAIL PROTECTED] | don't get caught. http://people.debian.org/~branden/ | -- Anthony Davidson signature.asc Description: Digital signature
Re: IMPORTANT: your message to html-tidy
On Mon, Sep 22, 2003 at 05:09:30PM -0500, david nicol wrote: | Shamless plug: sign up for totally spam-free forwarding address | at http://pay2send.com Ewww! *recoils in disgust* "You don't pay to send, we make others pay to send to you." - if this system become widespread, then you surely /would/ have to pay to send to others. In terms of spam prevention, this has no advantages over TMDA that I can think of, but it seems like a bloody good way to piss off people sending you sending you unsolicited but nevertheless legitimate email[1]. Also, like TMDA and similar systems, it does nothing to help spam that comes from e.g. Debian mailing lists. Cameron. [1] Where the definition of "legitimate email" may vary from person to person.
Re: Virus emails
On ma, 2003-09-22 at 17:53, Matthias Urlichs wrote: > The list of hardware required to stop this spam unfortunately seems to > include a time machine. Oh, that's not required at all. A simple couch will do. The couch will require a team of psychiatrists surrounding it, of course. They will then interview, for extended periods of time, whoever sends spam, writes viruses, or runs an insecure computer attached to the Internet. After the healing process is done, the culprits can then rejoin society as productive and wholesome individuals. I favor this approach over simple applications of violence, such as using an axe on any computer infected by a virus. -- http://liw.iki.fi/liw/photos/swordmaiden/
Re: Virus emails
On Tuesday 23 September 2003 01:45, Bernd Eckenfels wrote: > On Tue, Sep 23, 2003 at 12:28:44AM +0200, Mike Hommey wrote: > > Maybe I'm wrong, but I think an MTA rejecting a mail because of oversized > > body doesn't have to get the whole body before rejecting the mail. Based > > on this, it should be possible to reject the mail before it gets fully > > transfered to the server. > > Well, you can reject on the size argument, if you see one, and if it is not > faked. Otherwise you have to read up to x bytes until you can drop the > conncetion. > > But this has nothing to do with the worms, unless you want to limit your > mails to max 10k :) In case of spam and virus checking you have to read at > least the headers, and most likely a lot of the body (till you know the > attachement type) Indeed, but you don't have to get the whole 150KB of mail... Mike -- "I have sampled every language, french is my favorite. Fantastic language, especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'enculé de ta mère. It's like wiping your ass with silk! I love it." -- The Merovingian, in the Matrix Reloaded
(forw) How to deal with debconf translations and templates
modifications when using po-debconf (was: Re: Fwd: French translation for PHPWiki) Reply-To: X-message-flag: Outlook is a good virus spreading tool. It can send mail, too. X-Republicain: 1 vendïmiaire an CCXII (Raisin) Below is a message which may be of some interest for developers who are not used to debconf/po-debconf translation stuff. Matthew Palmer, maintainer of the phpwiki package, asked to Frederic Zulian (f1sxo), who translated phpwiki's tempaltes to french for some adive about how to deal properly with modifications he plans to do on the original english templates Below is the answer I made...which gives some clues about all this po-debconf stuff. This may have some interest for some of you...or this may sound rather trivial to others..ï:-) (both agreed for me to forward this publicly) - Forwarded message from Christian Perrier <[EMAIL PROTECTED]> - Date: Tue, 23 Sep 2003 07:07:22 +0200 From: Christian Perrier <[EMAIL PROTECTED]> To: f1sxo <[EMAIL PROTECTED]>, Christian Perrier <[EMAIL PROTECTED]>, Matthew Palmer <[EMAIL PROTECTED]> Subject: Re: Fwd: French translation for PHPWiki Frederic forwarded your mail to me.. > OK, I changed the templates file provided by the po-debconf patch - but I > didn't change the templates.pot file. How do I regenerate that, then, so I > can send the updated version to you? > > I'm an absolute babe-in-the-woods when it comes to translation work. Sorry. Just put Frïdïric's original fr.po file in debian/po. Then run debconf-updatepo from debian. NEVER manually modify files in debian/po, especially templates.pot and POTFILES.inunless you really knwo what you are doing. After running debconf-updatepo, have a look at debian/po/fr.po : you will see that strings you modified in the original templates file will be marked "fuzzy". This means that the translated version has been identified as not corresponding to the new english version. Fuzzying strings is very easy: any change, even minor (double space replaced by one space) will fuzzy the corresponding translation. When a template has at least one fuzzy string, debconf will NOT use the translation. This prevents outdated translations to be used. After running debconf-updatepo, just send Frederic the new fr.po file: he will make the appropriate corrections and then send the file back to you --> just replace your old file with that one and voila. When you build your package, provided you use debhelper, dh_installdebconf will run debconf-updatepo anyway...so you don't have to run it manually. However, this is a Good Thing to run it before building your package and then check the translationsÂ: for i in debian/po/*.po do echo $i msgfmt -o /dev/null --statistics $i done If some of these show anything else thanÂ: NN translated messages but something like: 1 translated message, 3 fuzzy translations. Then it needs some update. You may look at the Last-Translator field and then ask this individual for an update by sending him the new XX.po file. You may build a package with fuzzied or untranslated strings in some translation files. This won't break your package.but trying to deal with these translations before bilding is IMHO Good Practice (but don't wait too much for translators anyway...) (Matthew, Frederic, do you mind if I forward this to debian-devel.? This may be of some interest for other developers. I may remove the "babe-in-the-woods" comment, if you like...:-))) - End forwarded message - --
Re: Virus emails
On Tue, Sep 23, 2003 at 12:28:44AM +0200, Mike Hommey wrote: > Maybe I'm wrong, but I think an MTA rejecting a mail because of > oversized body doesn't have to get the whole body before rejecting the > mail. You can issue a permanent error only after you have received the body.
Re: Virus emails
Hi, Is there something similar for exim (woody version)? I don't care too much about the incoming bandwidth, but more about the resources that the spam and virus checks consume, especially during these spam virus waves. So I could add a (hopefully) cheap check at MTA level to reject these mails until the wave is over. Joachim Am Di, 2003-09-23 um 04.29 schrieb Graham Wilson: > On Mon, Sep 22, 2003 at 04:53:16PM +0200, Matthias Urlichs wrote: > > Hi, Mike Hommey wrote: > > > helps catching 95%... But the bandwidth is still used... I'm still > > > looking for a pure MTA solution... > > > > A pure MTA solution would still need to scan the body and thus would still > > eat your bandwidth. > > i have postfix's body_checks setup to reject lines that match the > following regular expression (this is the first line of the base64 > encoded virus): > > /^TVqQAAME\/\/8AALgAQAAA$/ > > i'm not sure when postfix closes the connection, whether its after > recieving a matching line, or after the client is done sending data. if > the former though, this would be a good "pure" mta solution that doesn't > conserve too much bandwidth. > > as to effectiveness, i've blocked 664 messages since saturday afternoon. > i still get some swen messages through, but they have had the virus > stripped already, so the message is considerably smaller. -- Joachim "nomeata" Breitner e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189 Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V? PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z? Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge. Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Virus emails
On Mon, Sep 22, 2003 at 07:34:58PM -0400, H. S. Teoh wrote: > I've resorted to blocking port 25 to subnets from which these spams > originate. Currently I have about 45 subnets (/24 and a few /16) on my > blacklist, and so far 409 connections have been dropped. The sad thing about this is that there are parts of the Internet that aren't subnet'ed properly. My mail server happens to be in the same /16 as about two hundred entirely different locations, so whenever someone gets one of those from whatever lamer in some shithole 900km away from me, my IPs get blocked as well. Our NOC, collateral damage, and life in general for that matter, suck. :) -- 2. That which causes joy or happiness.
Re: Virus emails
On Mon, Sep 22, 2003 at 08:46:15PM -0700, Steve Lamb wrote: > On Mon, 22 Sep 2003 22:44:50 -0400 > "H. S. Teoh" <[EMAIL PROTECTED]> wrote: > > Another major source is rr.com, which not only gives me tons of Swen, but > > also other spam in general. I've blacklisted rr.com in /etc/hosts.deny, > > but obviously I'm missing something obvious, 'cos rr.com spam still gets > > through unless I block them on the firewall. > > rr.com pisses me off. They RBL other ISP provider's customer blocks so > we can't complain about their mess. Pathetic. Apparently rr.com has a reputation for being a spamhaus since years ago, in spite of their advertisements to the contrary. [snip] > > What are the exim rules you used to catch these things? > > exiscan-acl calling clamav and dropping it with a 550. A full log line > would be: > > 2003-09-22 07:38:05 1A1RpB-0007Xd-Of H=(smtp21.singnet.com.sg) > [165.21.101.201] F=<[EMAIL PROTECTED]> rejected after DATA: This > message contains a viru s or other malware (Worm.Gibe.F). I see. Thanks for the info, I'll look it up. [snip] > > For me, I just created a special iptables chain in the NAT table and wrote > > a script to put DROP rules into it. Then I have a rule in PREROUTING that > > diverts all port 25 traffic to that chain (so that other stuff doesn't > > incur too much overhead---the chain is quite long and growing rapidly). > > True. I'm just doing a blanket blacklist since I figure if they're > infected with this, what else will they hit? So far, I haven't got anything except port 25 connections from infected hosts. But then again, I have very few open ports on my machine, so who knows. > > If you want to automate this more, you could write a spamassassin rule > > that matches Swen mails, then use procmail to filter it (match against the > > rule name in X-Spam-Status) through a script that grabs the IP address and > > enters it into the firewall. > > Except it never hits SA nor do I even have procmail installed. Can't > stand the ugly beast. It never hits SA? Almost all Swen mails I got were caught by my bogofilter + SA setup. (It only missed like 2-3 out of at least 5000 per day.) [snip] > > But according to my observations from today, it's not a big deal if the > > first few messages get through---all my firewall rules were hand-added > > (only partially automated with some scripts), and they still catch a lot > > of subsequent crap. From the looks of it, infected machines are liable to > > repeatedly resend messages to the same target. The fact that you *did* > > blackhole the IP or subnet probably saves you from a lot of subsequent > > crap. > > True. Right now I'm just adding IPs by awking out the IPs, cleaning off > the brackets and tacking it onto the end of shorewall's blacklist. I've resorted to blocking wide subnets. 202.248.37.0/24 alone has had 3858 hits since yesterday, and still counting. Last night alone (about the past 8 hours or so) the firewall blocked about 6000+ port 25 connections, and shows no sign of slowing down. In fact, the rate seems to be increasing from the per minute scale and approaching the per second scale. [snip] > Ahhh, here's an interesting tidbit. From shorewall's status. > > Chain blacklst (2 references) > pkts bytes target prot opt in out source destination >40 2400 DROP all -- * * 128.118.141.31 0.0.0.0/0 >48 2880 DROP all -- * * 128.118.141.35 0.0.0.0/0 > 0 0 DROP all -- * * 128.83.126.136 0.0.0.0/0 > 1087 52176 DROP all -- * * 129.79.1.71 0.0.0.0/0 > 686 32928 DROP all -- * * 129.79.1.72 0.0.0.0/0 > > This in interesting. Some of these are hitting me a LOT and others have > not hit at all. I guess this means I can drop the ones with a 0 count, reset > the counts and let it go. This would, in theory, weed out the cleaned up > hosts while leaving in the infected, no? [snip] I noticed this also. However, I found that some of the subnets I blocked "rested" for several hours, and then started bombarding me again. So I'm leaving the rules in for at least a couple o' days before cleaning out those with 0 count. T -- To err is human; to forgive is not our policy. -- Samuel Adler
Re: Virus emails
On Tue, Sep 23, 2003 at 02:31:22PM +0200, Josip Rodin wrote: > On Mon, Sep 22, 2003 at 07:34:58PM -0400, H. S. Teoh wrote: > > I've resorted to blocking port 25 to subnets from which these spams > > originate. Currently I have about 45 subnets (/24 and a few /16) on my > > blacklist, and so far 409 connections have been dropped. > > The sad thing about this is that there are parts of the Internet that aren't > subnet'ed properly. My mail server happens to be in the same /16 as about > two hundred entirely different locations, so whenever someone gets one of > those from whatever lamer in some shithole 900km away from me, my IPs get > blocked as well. Our NOC, collateral damage, and life in general for that > matter, suck. :) [snip] Which is why I've mostly refrained from /16's unless there are a lot of different addresses therein that have been infected. Although I admit to having a /8 for 212.* since there is just an amazing variety of addresses in that block that flood me with Swen. Ah, that ipv6 would be widely adopted soon... T -- LINUX = Lousy Interface for Nefarious Unix Xenophobes.
Re: Virus emails
Lars Wirzenius writes: > I favor this approach over simple applications of violence, such as using > an axe on any computer infected by a virus. Psychiatry just for sending viruses? I don't know. Seems pretty extreme to me. Are you sure simple beatings would not suffice? -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Virus emails
On Tue, Sep 23, 2003 at 08:39:02AM -0400, H. S. Teoh wrote:
> > > What are the exim rules you used to catch these things?
> >
> > exiscan-acl calling clamav and dropping it with a 550. A full log
> > line would be:
> >
> > 2003-09-22 07:38:05 1A1RpB-0007Xd-Of H=(smtp21.singnet.com.sg)
> > [165.21.101.201] F=<[EMAIL PROTECTED]> rejected after DATA: This
> > message contains a viru s or other malware (Worm.Gibe.F).
>
> I see. Thanks for the info, I'll look it up.
exim4-daemon-heavy includes the Exiscan patch that allows one to scan for
malformed MIME, viruses and spam during the SMTP dialogue.
Install clamav-daemon and in the general settings block add:
av_scanner = clamd:/var/run/clamd.ctl
And in the ACL block after DATA, you put something like:
deny message = Message contains malware ($malware_name)
demime = *
malware = *
Works wonders.
There are also similar low-level interfaces to SpamAssassin: one is via a
sa-exim.so that is loaded via the local_scan() interface,
local_scan_path = .../somewhere/sa-exim-3.0.so
And another one is via an exiscan ACL setting for it (also in the DATA ACL),
deny message = Classified as spam (score $spam_score)
condition = ${if <{$message_size}{80k}{1}{0}}
condition = ${if <{$spam_score_int}{120}{1}{0}}
spam = nobody
(that 120 is 12.0 in SA terms)
For now I'm using the SA-Exim method because even though it's clumsy (needs
the .so file compiled from source so distribution isn't as trivial as an
apt-get invocation), I used it before the Exiscan patch was available and it
was reliable. (I'd welcome suggestions from other users about this issue.)
> > > If you want to automate this more, you could write a spamassassin rule
> > > that matches Swen mails, then use procmail to filter it (match against the
> > > rule name in X-Spam-Status) through a script that grabs the IP address and
> > > enters it into the firewall.
> >
> > Except it never hits SA nor do I even have procmail installed. Can't
> > stand the ugly beast.
>
> It never hits SA?
Because his antivirus ACL kills it before that.
--
2. That which causes joy or happiness.
Re: Virus emails
Steve Lamb dijo [Mon, Sep 22, 2003 at 07:21:05PM -0700]: > Gunnar Wolf <[EMAIL PROTECTED]> wrote: > > [1] http://www.ietf.org/rfc/rfc0821.txt > > And what does RFC2821 have to say about it? I would not trust every MTA to implement newer versions of the RFC - However, it is up to you to decide ;-) -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Bug#212399: ITP: libdate-leapyear-perl -- Simple module to determine whether or not a year is a leapyear
Package: wnpp Version: unavailable; reported 2003-09-23 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libdate-leapyear-perl Version : 1.7.1 Upstream Author : Rich Bowen <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Date-Leapyear/ * License : Artistic Description : Simple module to determine whether or not a year is a leapyear This is a simple, non-OO module to determine whether or not a year is a leap year. It exports one function, isleap, which returns 1 or 0, which determines whether a year is leap or not This is a relatively simple module, but it's a distinct component necessary for libdate-ical-perl, which in turn is used by one of the upstream examples for libtest-class-perl (and is thus a Suggests: on it, and should be furfilled.) Unless there are any objections from debian-devel, this will be in new/ later today. - -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux starlite 2.4.19-686 #1 Mon Nov 18 23:59:03 EST 2002 i686 Locale: LANG=C, LC_CTYPE=C -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/cHULZNh5D+C4st4RAo0XAJ4t0CwRAIIaDjaGi9A7+LlgU0f9rgCfae0z 7nd1X6Cs1KlmAZ6aNWYKTiU= =v1HG -END PGP SIGNATURE-
Re: Virus emails
You are aware Mutt is perfectly capable of responding to the list. Learn it, love it, USE IT! On Tue, 23 Sep 2003 10:20:46 -0500 Gunnar Wolf <[EMAIL PROTECTED]> wrote: > Steve Lamb dijo [Mon, Sep 22, 2003 at 07:21:05PM -0700]: > > Gunnar Wolf <[EMAIL PROTECTED]> wrote: > > > [1] http://www.ietf.org/rfc/rfc0821.txt > > And what does RFC2821 have to say about it? > I would not trust every MTA to implement newer versions of the RFC - > However, it is up to you to decide ;-) Well that's the thing, isn't it. At some point we will have to work with that document and not legacy documents. Besides, you're operating under the impression that spamming software follow either. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpUaCpPytag6.pgp Description: PGP signature
Re: Virus emails
On Tue, 23 Sep 2003 08:39:02 -0400 "H. S. Teoh" <[EMAIL PROTECTED]> wrote: > On Mon, Sep 22, 2003 at 08:46:15PM -0700, Steve Lamb wrote: > > Except it never hits SA nor do I even have procmail installed. Can't > > stand the ugly beast. > It never hits SA? Almost all Swen mails I got were caught by my bogofilter > + SA setup. (It only missed like 2-3 out of at least 5000 per day.) Exiscan-ACL gets the message before Spamassassin does. So the checks are: Exiscan-ACL says Malformed MIME? Reject. Clamav says Malware (virus, worms, trojans, etc)? Reject. Spamassassin says its spam? Reject. > I noticed this also. However, I found that some of the subnets I blocked > "rested" for several hours, and then started bombarding me again. So I'm > leaving the rules in for at least a couple o' days before cleaning out > those with 0 count. Hrm, well the cycle of when to remote and reset could be tuned for daily or weekly operation. :) -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpzy3zr8Pr0U.pgp Description: PGP signature
Re: Virus emails
On Tue, 23 Sep 2003 16:45:55 +0200 Josip Rodin <[EMAIL PROTECTED]> wrote: > For now I'm using the SA-Exim method because even though it's clumsy (needs > the .so file compiled from source so distribution isn't as trivial as an > apt-get invocation), I used it before the Exiscan patch was available and it > was reliable. (I'd welcome suggestions from other users about this issue.) Same here though I am sticking with SA-Exim because it saves the mail in a certain range so I can throw it at the Bayesian classifier. It also has the option of teergrubing. It's generally accepted that for robust handling of Spam SA-Exim is the better route. For simple handling as well as virus scanning Exiscan-ACL is the better route. Lots of people just use both. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpczfRvlVnu7.pgp Description: PGP signature
Re: Virus emails
Steve Lamb dijo [Tue, Sep 23, 2003 at 10:29:51AM -0700]: > Gunnar Wolf <[EMAIL PROTECTED]> wrote: > > Steve Lamb dijo [Mon, Sep 22, 2003 at 07:21:05PM -0700]: > > > Gunnar Wolf <[EMAIL PROTECTED]> wrote: > > > > [1] http://www.ietf.org/rfc/rfc0821.txt > > > > And what does RFC2821 have to say about it? > > > I would not trust every MTA to implement newer versions of the RFC - > > However, it is up to you to decide ;-) > > Well that's the thing, isn't it. At some point we will have to work with > that document and not legacy documents. Besides, you're operating under the > impression that spamming software follow either. Ok... You got me on this one - I just went and checked the document. It is, however, quite a recent document (April 2001), and there are still too many people using older software. I prefer having the old, trusted phylosophy - Be strict on what you send, relaxed on what you receive. Now, I am not reading the whole document just to check this out. Skimming it, I found many reasons for the 'DATA' command to return a 4xx or 5xx error code, but didn't find a reason to interrupt the client. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Virus emails
On Tue, Sep 23, 2003 at 10:43:30AM -0700, Steve Lamb wrote: > > For now I'm using the SA-Exim method because even though it's clumsy (needs > > the .so file compiled from source so distribution isn't as trivial as an > > apt-get invocation), I used it before the Exiscan patch was available and it > > was reliable. (I'd welcome suggestions from other users about this issue.) > > Same here though I am sticking with SA-Exim because it saves the mail > in a certain range so I can throw it at the Bayesian classifier. I usually don't have large enough partitions to hold all the spam (!) > It also has the option of teergrubing. I'm a bit scared of turning it on, didn't (see|read) enough documentation for it. > It's generally accepted that for robust handling of Spam SA-Exim is the > better route. For simple handling as well as virus scanning Exiscan-ACL > is the better route. Lots of people just use both. Isn't that pretty wasteful? -- 2. That which causes joy or happiness.
Re: Virus emails
On Tue, 23 Sep 2003 21:07:46 +0200 Josip Rodin <[EMAIL PROTECTED]> wrote: > On Tue, Sep 23, 2003 at 10:43:30AM -0700, Steve Lamb wrote: > > Same here though I am sticking with SA-Exim because it saves the mail > > in a certain range so I can throw it at the Bayesian classifier. > I usually don't have large enough partitions to hold all the spam (!) Certain range. Here it is things scored between 5 and 8. 5 is where things are considered spam. 8 is where I reject things outright. 12 is where autolearn is set. I want to send things in that range to the Bayesian classifier so the score would creep up hopefully to the point of being rejected. Comes out to about 1-2 a day. > > It also has the option of teergrubing. > I'm a bit scared of turning it on, didn't (see|read) enough documentation > for it. Simple concept, if a message scores high enough (25 is default) you just string the connection out for 5 minutes. > > It's generally accepted that for robust handling of Spam SA-Exim is the > > better route. For simple handling as well as virus scanning Exiscan-ACL > > is the better route. Lots of people just use both. > Isn't that pretty wasteful? Depends on what you consider wasteful. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpAfnIiHxhgH.pgp Description: PGP signature
Bug#212439: ITP: libdate-ical-perl -- Perl extension for ICalendar date objects
Package: wnpp Version: unavailable; reported 2003-09-23 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libdate-ical-perl Version : 1.72 Upstream Author : Rich Bowen <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Date-ICal/ * License : GPL / Artistic Description : Perl extension for ICalendar date objects Date::ICal talks the ICal date format, and is intended to be a base class for other date/calendar modules that know about ICal time format also. This is to satisfy a Suggests: in libtest-class-perl - -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux starlite 2.4.19-686 #1 Mon Nov 18 23:59:03 EST 2002 i686 Locale: LANG=C, LC_CTYPE=C -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/cK96ZNh5D+C4st4RAmfVAJ9FCNp4OdL/86+57FmyzPeKobSLHACff1Qi +q9xXYJRvIPa24rucvH8U4A= =FxhI -END PGP SIGNATURE-
Rotation of /var/log/mail.log
Hello, fellow developers ! While /var/log/mail.log is rotated nicely on my (woody) boxes, I have no idea which package is responsible for that. Any suggestions ? That would help me to solve bug #212237. Any help is welcome. Thanks Racke -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team
Re: Rotation of /var/log/mail.log
On Tue, Sep 23, 2003 at 11:18:27PM +0200, [EMAIL PROTECTED] wrote: > While /var/log/mail.log is rotated nicely on my (woody) boxes, > I have no idea which package is responsible for that. > Any suggestions ? /etc/cron.weekly/sysklogd This script rotates all the files which are output from running: /usr/sbin/syslogd-listfiles --weekly > That would help me to solve bug #212237. If you make sure there is an entry for mail in /etc/syslog.conf then these files will be output from the 'syslogd-listfiles' and rotated correctly. Alternatively you could drop a file in /etc/logrotate.d/ to force the issue. I hope that helps; and thanks for the great work with courier. Steve -- www.steve.org.uk
Re: Rotation of /var/log/mail.log
On Tue, Sep 23, 2003 at 11:18:27PM +0200, [EMAIL PROTECTED] wrote: > While /var/log/mail.log is rotated nicely on my (woody) boxes, > I have no idea which package is responsible for that. > Any suggestions ? logrotate. -- gram signature.asc Description: Digital signature
Re: Rotation of /var/log/mail.log
On Tue, 23 Sep 2003 23:18:27 +0200 [EMAIL PROTECTED] wrote: > > While /var/log/mail.log is rotated nicely on my (woody) boxes, > I have no idea which package is responsible for that. > Any suggestions ? > > That would help me to solve bug #212237. Perhaps /etc/cron.weekly/sysklogd, from package sysklogd? -- Carlos Sousa http://vbc.dyndns.org/
Re: Rotation of /var/log/mail.log
Steve Kemp said on Tue, Sep 23, 2003 at 10:45:11PM +0100: > > While /var/log/mail.log is rotated nicely on my (woody) boxes, > > I have no idea which package is responsible for that. > > Any suggestions ? > > /etc/cron.weekly/sysklogd > > This script rotates all the files which are output from running: > > /usr/sbin/syslogd-listfiles --weekly > > > That would help me to solve bug #212237. > > If you make sure there is an entry for mail in /etc/syslog.conf then > these files will be output from the 'syslogd-listfiles' and rotated > correctly. > Alternatively you could drop a file in /etc/logrotate.d/ to force > the issue. Please do this instead. I'm not sure why sysklogd does it's own rotation, but most other stuff uses logrotate, and it works well. M pgp597srBnu1y.pgp Description: PGP signature
Re: Rotation of /var/log/mail.log
On Tue, 23 Sep 2003 22:45:11 +0100 Steve Kemp <[EMAIL PROTECTED]> wrote: > On Tue, Sep 23, 2003 at 11:18:27PM +0200, [EMAIL PROTECTED] wrote: > > > While /var/log/mail.log is rotated nicely on my (woody) boxes, > > I have no idea which package is responsible for that. > > Any suggestions ? > > /etc/cron.weekly/sysklogd > > This script rotates all the files which are output from running: > > /usr/sbin/syslogd-listfiles --weekly Ah, ok. I tried to find it by grepping /etc, but to no avail. > > > That would help me to solve bug #212237. > > If you make sure there is an entry for mail in /etc/syslog.conf then > these files will be output from the 'syslogd-listfiles' and rotated > correctly. > Alternatively you could drop a file in /etc/logrotate.d/ to force > the issue. I wonder if both rotating methods may conflict ... Thank you very much for your prompt help ! Bye Racke -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team
Re: Rotation of /var/log/mail.log
On Tue, Sep 23, 2003 at 02:59:02PM -0700, Mark Ferlatte wrote: > Please do this instead. I'm not sure why sysklogd does it's own > rotation[...] Because sysklogd doesn't have a fixed set of log files. -- - mdz
Re: Rotation of /var/log/mail.log
Matt Zimmerman said on Tue, Sep 23, 2003 at 07:43:04PM -0400: > On Tue, Sep 23, 2003 at 02:59:02PM -0700, Mark Ferlatte wrote: > > > Please do this instead. I'm not sure why sysklogd does it's own > > rotation[...] > > Because sysklogd doesn't have a fixed set of log files. It does have a _default_ set of log files, which should be rotated by default. Apache doesn't have a fixed set of log files, either, but it uses logrotate just fine. As far as that goes, so does the syslog-ng syslogd replacement. It doesn't seem unreasonable to expect that if you change log file locations that you should/would have to change logrotation configuration, and having syslogd be seperate and special is just adding confusion without much gain. M pgp58Vz68q1vv.pgp Description: PGP signature
Re: Rotation of /var/log/mail.log
On Tue, Sep 23, 2003 at 04:46:01PM -0700, Mark Ferlatte wrote: > Matt Zimmerman said on Tue, Sep 23, 2003 at 07:43:04PM -0400: > > On Tue, Sep 23, 2003 at 02:59:02PM -0700, Mark Ferlatte wrote: > > > > > Please do this instead. I'm not sure why sysklogd does it's own > > > rotation[...] > > > > Because sysklogd doesn't have a fixed set of log files. > > It does have a _default_ set of log files, which should be rotated by default. > Apache doesn't have a fixed set of log files, either, but it uses logrotate > just fine. As far as that goes, so does the syslog-ng syslogd replacement. > > It doesn't seem unreasonable to expect that if you change log file locations > that you should/would have to change logrotation configuration, and having > syslogd be seperate and special is just adding confusion without much gain. sysklogd tries to be better; it adapts to the current configuration rather than leaving it up to the user to update a logrotate.d file if they change the configuration. -- - mdz
Re: Rotation of /var/log/mail.log
On Tue, Sep 23, 2003 at 07:43:04PM -0400, Matt Zimmerman wrote: > > Please do this instead. I'm not sure why sysklogd does it's own > > rotation[...] > Because sysklogd doesn't have a fixed set of log files. I prefer to have a default logrotate script which has some "missingok,notifempty" statements, because it is quite unlikely that all syslog files should be rotate in the same manner and with the same permissions. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Rotation of /var/log/mail.log
On Tue, Sep 23, 2003 at 07:51:51PM -0400, Matt Zimmerman wrote: > sysklogd tries to be better; it adapts to the current configuration rather > than leaving it up to the user to update a logrotate.d file if they change > the configuration. # If you want to rotate other logfiles daily, edit # this script. An easy way is to add them manually # or to add -a to syslogd-listfiles and add some grep # stuff. and fails... Greetings bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
