Re: Domainkeys - Conflicting msg headers?
On 6/12/2006 8:58 AM, Magnus Holmgren wrote: On Monday 23 January 2006 15:50, Matt Kettler took the opportunity to write: Glen Carreras wrote: * 0.0 DK_SIGNED Domain Keys: message has an unverified signature * -0.0 DK_VERIFIED Domain Keys: signature passes verification From looking at the domainkeys plugin, that's normal, and the description is a bit misleading. DK_SIGNED means the message is signed. Period. The follow-on text is trying to explain that DK_SIGNED has not verified the signature, it has merely detected one is present, so the signature may or may not be valid. DK_VERIFIED means the signature passed verification. Based on the code, this will never happen unless the message also matches DK_SIGNED. I suggest that the description for DK_SIGNED be changed slightly to Domain Keys: message has a (not yet verified) signature. Already changed in 3.2: describe DK_SIGNED Domain Keys: message has a signature describe DK_VERIFIEDDomain Keys: signature passes verification describe DK_POLICY_SIGNSOME Domain Keys: policy says domain signs some mails describe DK_POLICY_SIGNALL Domain Keys: policy says domain signs all mails describe DK_POLICY_TESTING Domain Keys: policy says domain is testing DK Daryl
RE: Low scoring since 3.1.1 upgrade
Thanks Jeff, much better now :-) That's a great site, will definitely be having a look around there for other useful resources. Thanks again, Chris. -Original Message- From: Jones, Chris L: IT (LDN) Sent: 12 June 2006 10:53 To: 'Jeff Chan' Subject: RE: Low scoring since 3.1.1 upgrade Thanks Jeff, I'll give it go :-) -Original Message- From: Jeff Chan [mailto:[EMAIL PROTECTED] Sent: 12 June 2006 10:48 To: Jones, Chris L: IT (LDN) Cc: [EMAIL PROTECTED]; users@spamassassin.apache.org Subject: Re: Low scoring since 3.1.1 upgrade Try using the SARE stocks rule: http://www.rulesemporium.com/rules.htm#stocks Jeff C. -- Jeff Chan mailto:[EMAIL PROTECTED] http://www.surbl.org/ For more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons.
Re: The Future of Email is SQL
Jim C. Nasby wrote: On Sat, Jun 10, 2006 at 01:23:35PM -0600, wrote: I would defer to the smart people to figure out the details. However I do wonder if the actual body content of the message would be best stored in a file and the SQL used to store anything and everything you would want to index. That would keep the SQL file size down if that's an issue. However, SQL databases might have to be changed to accomodate the needs to store email. I think this is what I was getting at early in the thread. I would think that a 5 MB body would do better on file but I don't know enough in regards to DBs to even make a call. A good rule of thumb about storing something in the database is: are you going to search that data? If you're going to search the text of an email body, that makes it a more likely candidate for storing it in the database (though there are ways to do this searching while storing the file externally). SQL databases suck dead dogs through a straw on full text searches. The language specification isn't designed for it. Database vendors offer support for it in various mutually-incompatible ways. It's easy to precalc search indices for maildir and produce fast search results; mairix is one such tool that I know of, there are no doubt many other solutions available. David -- Much of the propaganda that passes for news in our own society is given to immobilising and pacifying people and diverting them from the idea that they can confront power. -- John Pilger
Re: New spam type - sender domain quickly deleted
On Montag, 12. Juni 2006 10:03 Jamie L. Penman-Smithson wrote: On 12 Jun 2006, at 07:53, Michael Monnerie wrote: yesterday I've got some new kind of spam: X-Envelope-From: [EMAIL PROTECTED] Received: from abruxateatro.com (unknown [210.245.161.31]) by power2u.goelsen.net (Postfix) with SMTP id for _; Sun, 11 Jun 2006 18:25:57 +0200 (CEST) X-Envelope-From: [EMAIL PROTECTED] Received: from acidstufftv.com (unknown [210.245.161.31]) by power2u.goelsen.net (Postfix) with SMTP id for _; Sun, 11 Jun 2006 18:25:58 +0200 (CEST) These domains don't exist now, but obviously did yesterday. Did anybody else see such SPAM? How can I check if a domain ever existed? Is anybody working on a check for new domains, so that you could say if a domain is newer than 2 days, temporary reject? abruxateatro.com still exists in DNS. although it looks like just a domain parked site: Oh, I got fooled by: # whois abruxateatro.com NO DOMAIN (1) So, that domain at least exists. Could there be a check for whether a domain has an MX record, and if not give it some points? Would make sense, I guess, because normally e-mail is two-way... And what about the acidstufftv.com domain? mfg zmi -- // Michael Monnerie, Ing.BSc- http://it-management.at // Tel: 0660/4156531 .network.your.ideas. // PGP Key: lynx -source http://zmi.at/zmi3.asc | gpg --import // Fingerprint: 44A3 C1EC B71E C71A B4C2 9AA6 C818 847C 55CB A4EE // Keyserver: www.keyserver.net Key-ID: 0x55CBA4EE pgpScopC8jHzg.pgp Description: PGP signature
RE: For those who are considering a Barracuda Network Device serv er
Title: RE: For those who are considering a Barracuda Network Device server -Original Message- From: Brent Kennedy [mailto:[EMAIL PROTECTED]] Sent: Monday, June 12, 2006 9:02 PM To: users@spamassassin.apache.org Subject: RE: For those who are considering a Barracuda Network Device server I took a look at them as a way to possibly go to a gui spam server because some of the other admins at my company are not linux gurus by any stretch, but these lacked some of the necessary functionality that would give me cause to actually pay for one. Course.. If anyone doesn't know.. Use webmin, it's a great alternative to doing things via command line... Especially if your not a linux guy like most of this list. Need a secure connection, just use the webmin ssl feature. Interesting point there, and I'm about to go a little off topic. IMHO, an Admins job should be to learn anything that does the job right. I've forgot 1/3 the stuff I've done. Who can honestly be a guru at much of anything these days? One day you're working on a VMS system, the next day SCO. Or working with 5 different versions of Windoze servers, and 11ty billion applications. Hacking _javascript_, to coding excel macros. Working on a CISCO router or checkout out a CSU/DSU unit. Managed switchs, converting IPChains to IPTables, PHP coding, to replacing some nit wits mouse. (Does anyone really remember those crazy undocumented steps in win NT 4.0 to properly upgrade DUN?) My lost point here is that a good admin can RTFM, post some questions, and figure out enough of some new app to get it running good and secure. Then retain half of it and move on to the next project. IMHO, for every 1 thing I'm a 'guru' at, there is 200 things I have yet to even touch. Cliffs: Don't be afraid to learn something new, and use the darn console! Webmin won't always be there for you! ;) Chris Santerre SysAdmin and SARE/URIBL ninja http://www.uribl.com http://www.rulesemporium.com
Question about SpamAssassin
Does SpamAssassin have it's own whitelist / blacklist if yes where is it located? when is the configuration file to enable this feature? -- View this message in context: http://www.nabble.com/Question-about-SpamAssassin-t1781206.html#a4849823 Sent from the SpamAssassin - Users forum at Nabble.com.
Re: Question about SpamAssassin
On Tue, June 13, 2006 10:21 am, slyandjen said: Does SpamAssassin have it's own whitelist / blacklist Of course. if yes where is it located? /etc/mail/spamassassin/local.cf or /home/$USER/.spamassassin/user_prefs when is the configuration file to enable this feature? Anything you add in those files will be active when Spamassassin is restarted (I think that's when as I restart it whenever I make changes; Please anyone, correct me if I'm wrong. It would be nice not to restart if it's unnecessary). HTH, Karl -- View this message in context: http://www.nabble.com/Question-about-SpamAssassin-t1781206.html#a4849823 Sent from the SpamAssassin - Users forum at Nabble.com. -- karl _/ _/ _/ _/_/_/ __o _/ _/ _/ _/_/ _-\._ _/_/_/ _/_/_/ (_)/ (_) _/ _/ _/ _/ .. _/ _/ arl _/_/_/ _/ earson[EMAIL PROTECTED] --- Senior Consulting Sys/DB Analyst http://consulting.ourldsfamily.com --- My Thoughts on Terrorism In America right after 9/11/2001: http://www.ourldsfamily.com/wtc.shtml --- A right is not what someone gives you; it's what no one can take from you. -Ramsey Clark ---
Re: Domainkeys - Conflicting msg headers?
At 22:57 12-06-2006, Daryl C. W. O'Shea wrote: Already changed in 3.2: describe DK_SIGNED Domain Keys: message has a signature [snip] It's DomainKeys and not Domain Keys. Regards, -sm
Re: New spam type - sender domain quickly deleted
... On Montag, 12. Juni 2006 10:03 Jamie L. Penman-Smithson wrote: On 12 Jun 2006, at 07:53, Michael Monnerie wrote: yesterday I've got some new kind of spam: X-Envelope-From: [EMAIL PROTECTED] Received: from abruxateatro.com (unknown [210.245.161.31]) by power2u.goelsen.net (Postfix) with SMTP id for _; Sun, 11 Jun 2006 18:25:57 +0200 (CEST) X-Envelope-From: [EMAIL PROTECTED] Received: from acidstufftv.com (unknown [210.245.161.31]) by power2u.goelsen.net (Postfix) with SMTP id for _; Sun, 11 Jun 2006 18:25:58 +0200 (CEST) These domains don't exist now, but obviously did yesterday. Did anybody else see such SPAM? How can I check if a domain ever existed? Is anybody working on a check for new domains, so that you could say if a domain is newer than 2 days, temporary reject? abruxateatro.com still exists in DNS. although it looks like just a domain parked site: Oh, I got fooled by: # whois abruxateatro.com NO DOMAIN (1) So, that domain at least exists. Could there be a check for whether a=20 domain has an MX record, and if not give it some points? Would make=20 sense, I guess, because normally e-mail is two-way... And what about the acidstufftv.com domain? mfg zmi =2D-=20 // Michael Monnerie, Ing.BSc- http://it-management.at // Tel: 0660/4156531 .network.your.ideas. // PGP Key: lynx -source http://zmi.at/zmi3.asc | gpg --import // Fingerprint: 44A3 C1EC B71E C71A B4C2 9AA6 C818 847C 55CB A4EE // Keyserver: www.keyserver.net Key-ID: 0x55CBA4EE ... Sloppy (and maybe even blackhat) registrars (belgiumdomains.com, capdom.com and domaindoorman.com). You don't need a 'MX' - fallback to 'A' is still part of the standards. Both sites have non-parked pages (or did in the past) - See: http://whois.domaintools.com/abruxateatro.com and http://whois.domaintools.com/acidstufftv.com Paul Shupak [EMAIL PROTECTED] % whois -h whois.completewhois.com abruxateatro.com Completewhois.Com Whois Server, Version 0.91a33, compiled on May 28, 2006 Please see http://www.completewhois.com/help.htm for command-line options Use of this server and any information obtained here is allowed only if you follow our policies at http://www.completewhois.com/policies.htm [DOMAIN whois information for ABRUXATEATRO.COM ] Domain Name: ABRUXATEATRO.COM Namespace: ICANN Unsponsored Generic TLD - http://www.icann.org TLD Info: See IANA Whois - http://www.iana.org/root-whois/com.htm Registry: VeriSign, Inc. - http://www.verisign-grs.com Registrar: Whois data parsing problem, no registrar information found Whois Server: rs.internic.net Name Server[from dns, whois ip]: DNS4.K--SERVICE.COM 66.45.237.186 Name Server[from dns, dns ip]: DNS4.K--SERVICE.COM 64.20.33.131 Name Server[from dns, whois ip]: DNS2.K--SERVICE.COM 66.45.237.186 Name Server[from dns, dns ip]: DNS2.K--SERVICE.COM 64.20.39.27 Name Server[from dns, whois ip]: DNS.K--SERVICE.COM 66.45.237.186 Name Server[from dns, dns ip]: DNS.K--SERVICE.COM 64.20.33.4 Domain ABRUXATEATRO.COM not found in registry whois server. But this domain appears to be delegated in dns. This is either an error with registrar whois database or it is possible this domain was recently registered and whois data is not yet available. Completewhois domain information above should list current nameservers as has been found in dns, for more information regarding this domain, please do whois lookup on these nameservers or IPs [RS.INTERNIC.NET] ... % jwhois acidstufftv.com [Querying whois.internic.net] [Redirected to whois.domaindoorman.com] [Querying whois.domaindoorman.com] [whois.domaindoorman.com] This whois service shows the information for .COM, .NET and .ORG domains The fact that your query returns NOT FOUND does not necessarily mean that the domain may be available for registration. To search all domains, please go to the shared registry whois located at: http://www.internic.net/whois.html Registrant: Wang Lee (ACIDSTUFFTV-COM-DOM) Olympia Plaza 255 King's Road North Point, Hong Kong +852.30149162 +852.30149162 [EMAIL PROTECTED] Domain Name: ACIDSTUFFTV.COM Status: PROTECTED Administrative Contact: Wang Lee [EMAIL PROTECTED] Olympia Plaza 255 King's Road North Point, Hong Kong +852.30149162 Fax- +852.30149162 Technical Contact, Zone Contact: Wang Lee [EMAIL PROTECTED] Olympia Plaza 255 King's Road North Point, Hong Kong +852.30149162 Fax- +852.30149162 Record last updated on 12-Jun-2006. Record expires on 12-Jun-2007. Record created on 12-Jun-2006. Domain servers in listed order: Name Server: DNS4.K--SERVICE.COM Name Server:
Re: New spam type - sender domain quickly deleted
So, that domain at least exists. Could there be a check for whether a=20 domain has an MX record, and if not give it some points? Would make=20 sense, I guess, because normally e-mail is two-way... And what about the acidstufftv.com domain? Hi Michael, I think the rules say to send to the MX, if it exists, or to a host by the name of the domain, So if neither exists, this would be the one-way syituation. Other than adding poiunts in that case, I feel it is perfectly valid to reject such mails at the MTA level. After all, you are taking responsibility for a delivery, although you know you could not send a bounce message if needed. Wolfgang Hamann
RE: For those who are considering a Barracuda Network Device serv er
Mr. Santerre said: Interesting point there, and I'm about to go a little off topic. IMHO, an Admins job should be to learn anything that does the job right. Well, for some value of 'right' - definitions vary, and often what management considers 'right' differs from mine. However: I've forgot 1/3 the stuff I've done. Who can honestly be a guru at much of anything these days? One day you're working on a VMS system, the next day SCO. Or working with 5 different versions of Windoze servers, and 11ty billion applications. Hacking Javascript, to coding excel macros. Working on a CISCO router or checkout out a CSU/DSU unit. Managed switchs, converting IPChains to IPTables, PHP coding, to replacing some nit wits mouse. (Does anyone really remember those crazy undocumented steps in win NT 4.0 to properly upgrade DUN?) My lost point here is that a good admin can RTFM, post some questions, and figure out enough of some new app to get it running good and secure. Then retain half of it and move on to the next project. Knowledge has a half-life, methinks. Use it or lose it. Exceptions for the most painful sets of education - they tend to stick around longer. IMHO, for every 1 thing I'm a 'guru' at, there is 200 things I have yet to even touch. Cliffs: Don't be afraid to learn something new, and use the darn console! Webmin won't always be there for you! ;) Chris Santerre SysAdmin and SARE/URIBL ninja http://www.uribl.com http://www.rulesemporium.com Amen. Forsooth. Verily. My mantra - I don't really know much, but I know how to look it up. Kurt
Re: Question about SpamAssassin
From: [EMAIL PROTECTED]
On Tue, June 13, 2006 10:21 am, slyandjen said:
Does SpamAssassin have it's own whitelist / blacklist
Of course.
if yes where is it located?
/etc/mail/spamassassin/local.cf
or
/home/$USER/.spamassassin/user_prefs
when is the configuration file to enable this feature?
Anything you add in those files will be active when Spamassassin is restarted
(I think that's when as I restart it whenever I make changes; Please anyone,
correct me if I'm wrong. It would be nice not to restart if it's unnecessary).
If you use spamd you can -HUP it.
{^_^}
Re: SA tags above header info
Magnus Holmgren wrote: One remark I haven't seen yet is that the DomainKey-Signature: field can include an h tag, which specifies which header fields are included in the signature. If that tag is included (and I think it usually is(?)) and there aren't already any X-Spam-* fields that have been signed, then it should be safe to add SA's header lines below, just like before. If the h tag isn't present, adding it shouldn't change the verfication status, but I don't think it's allowed. You can't alter the signature. The signature tags are all used in calculation of the key. Always prepending SA's header lines clearly is the easiest thing to do. (Yes, I think it looks ugly, too.) Me too, but it's probably just because I'm used to it. Always adding new headers to the top has the additional benefit that it's easier to see which relay added what. Personally, I now prefer the headers being prepended over them being appended. There was about a week or two where I wasn't sure about it though. Daryl
Re: New spam type - sender domain quickly deleted
On Dienstag, 13. Juni 2006 20:53 List Mail User wrote: You don't need a 'MX' - fallback to 'A' is still part of the standards. Pfff - I'm so long in the business and never got aware of this. Possibly because until now every(body|domain) has had MX records. http://whois.domaintools.com/abruxateatro.com Thanks for the hint to that domaintools site, quite nice! It shows about 228.000 hosts being on that one IP address, and the domain was registered by a Hong Kong guy. Funny I got german spam through it, which also was a new type. Luckily, and update of ZMI_GERMAN was quickly done. I just wanted to see if we could do other things against... mfg zmi -- // Michael Monnerie, Ing.BSc- http://it-management.at // Tel: 0660/4156531 .network.your.ideas. // PGP Key: lynx -source http://zmi.at/zmi3.asc | gpg --import // Fingerprint: 44A3 C1EC B71E C71A B4C2 9AA6 C818 847C 55CB A4EE // Keyserver: www.keyserver.net Key-ID: 0x55CBA4EE pgpI8CZwnKVvH.pgp Description: PGP signature
Re: For those who are considering a Barracuda Network Device serv er
On Dienstag, 13. Juni 2006 17:43 Chris Santerre wrote: Webmin won't always be there for you! Amen. LOL, some very good words that could be heard at the end of an episode of outer limits. *g* mfg zmi -- // Michael Monnerie, Ing.BSc- http://it-management.at // Tel: 0660/4156531 .network.your.ideas. // PGP Key: lynx -source http://zmi.at/zmi3.asc | gpg --import // Fingerprint: 44A3 C1EC B71E C71A B4C2 9AA6 C818 847C 55CB A4EE // Keyserver: www.keyserver.net Key-ID: 0x55CBA4EE pgpP07EuT4k9U.pgp Description: PGP signature
Re: The Future of Email is SQL
On Jun 9, 2006, at 1:19 PM, Marc Perkel wrote: After considerable experimenting and thinking things through I thought I'd start a thread on the future of email to start planting the seeds of where MTA development needs to go. I'm convinced that someday soon we will all realize that MBOX and MAILDIR are obsolete technologies and that the future is going to be SQL based storage. Have you looked at dbmail? IMAP on top of MySQL.
Re: The Future of Email is SQL
On Jun 9, 2006, at 3:16 PM, Rob McEwen wrote: MS Exchange... one big Database Exactly... And that is one reason why I wouldn't touch this SQL idea with a 10 foot pole.. the fact that Exchange works this way only proves my point... I hear all the time about Exchange servers crashing and the administrator having to rebuild the database while the mail server is down for the next 10 hours. The bottom line is that using a SQL DB backend as mail storage is putting all your eggs in one basket. Not really. With MySQL you can mirror and stripe data across multiple back end servers. You lose one of the back end storage nodes? No big deal. Just get a new one up and running before you lose all of its mirrors. Though, I would agree that using MS Exchange would be a bad idea.
Re: Re[2]: The Future of Email is SQL
On Jun 9, 2006, at 9:49 PM, Sanford Whiteman wrote: If we are talking about making a SQL application that is usable for a multitude of people then why lock them into something. That's the easiest way to drive them away from supporting it. Word. Perl can play nice with plenty of RDBMSs. If this discussion belongs here at all, I can't see how RDBMS partisanship is going to take it anywhere good. I had been thinking about how feasible it would be to re-implement dbmail in perl.. and maybe a decent perl MTA to put in front of it too (something that will work with sendmail milters...). Then you could be pretty database agnostic. Just whatever perl wants to put back there.
Re: The Future of Email is SQL
John Rudd wrote: On Jun 9, 2006, at 1:19 PM, Marc Perkel wrote: After considerable experimenting and thinking things through I thought I'd start a thread on the future of email to start planting the seeds of where MTA development needs to go. I'm convinced that someday soon we will all realize that MBOX and MAILDIR are obsolete technologies and that the future is going to be SQL based storage. Have you looked at dbmail? IMAP on top of MySQL. I'm aware of it. What I'm hoping for is a MySQL backend for Dovecot. Timo has done some work in that direction. I'm hoping that after the 1.0 release that he works on it again. I think I can create some sort of Exim frontend if Timo adds it to dovecot.
Re: The Future of Email is SQL
John Rudd wrote: I had been thinking about how feasible it would be to re-implement dbmail in perl.. and maybe a decent perl MTA to put in front of it too (something that will work with sendmail milters...). Then you could be pretty database agnostic. Just whatever perl wants to put back there. I think that a local delivery program could be written fairly easily that Exim or any other existing MTA could pipe messages into for delivery. So one wouldn't have to rewrite the MTA but just use existing MTAs and just change the delivery mechanism. Eventually I think that MTAs would integrate MySQL delivery. My guess is that it's easier to deliver to MySQL than MBOX or MAILDIR because MySQL does all the work for you. You just pass the data and let MySQL do that magic. I'm also thinking that if SQL is used for mail storage that the SQL folks will evolve their databases to handle the needs of the email community. So those who point to Exchange as a disaster, I look at it as a first step. Something to take the good ideas and improve on them.
Re: The Future of Email is SQL
This is still visionary so take it for what it's worth. People are more familiar with MAILDIR and MBOX because they are files. You can read them with VI and PICO and FGREP and all the stuff that we are familiar with. MySQL is also easy but might require new tools and some learning. Once you become familiar with it them everything is just as easy. One could expoir and import to and from maildir and mbox, so that doesn't go away. With MySQL there are a lot of problems that go away. MySQL is a magic port that does everything for you. It doesn't care about what filesystem you're using, what OS you are running, what kinds of file locks or NFS mounts, or if you're using Reiser for maildir speed or if you have enough inodes. All that stuff goes away. MBOX and MAILDIR have no indexing. You can add indexes externally but there are no standards for that. With MySQL you can index anything and everything. You can add fields to the message, any fiels, as many as you want, and they too can be keys and indexes. With maildir and mbox you can't really do that. With MySQL you can access the data with any MySQL application. And the access is consistent no matter what programming language you use, what OS you use, anything. It's all SQL. So if you want a web interface you just write a PHP app. Spamassassin for example has migrated from GB files to MySQL for the AWL and bayes and we all can see how this has improved performance and ease of implementation. Before SQL having 5 servers sharing the same bayes is difficult. With SQL it's trivial. The SQL does it all for you. They do the magic so you don't have to. The indexing is a real key feature. If I have a key based on the sending host or index all the received lines, I could delete all messages that had an IP in any received line almost instantly. I can do it thousands of times faster than mbox or maildir because it's indexed. Indexing gives you incredible power and the SQL engine does all that for you. That SA and the IMAP and the MTA and the Web GUI - everything - all taking to a standard database - all integrated - all comnpatible. So - like I said - this is visionary stuff. Think SQL - think outside the box.
Going in circles with Postfix
Stuck in a loop.
New to SpamAssassin
Installed per
http://www.geekly.com/entries/archives/0155.htm
steps 1 through 8
(at step 3 I was confused about the use of sendmail which was moved to
sendmail.sendmail
when postfix was installed and also installed was sendmail.postfix - I
chose sendmail.sendmail
because sendmail.postfix resulted in an error message)
(at step 7 I do not understand the : (colon)- no reference to ; in
man 5 master - tried with and without
the : in step 7 - same results
#
---
smtp inet n - n - - smtpd
-o content_filter=spamfilter:
#
---)
apparently I am stuck in a never ending loop as shown in maillog
(and a complaint from sendmail about use of -f)
Jun 13 22:47:50 kp2a postfix/postfix-script: starting the Postfix mail
system
Jun 13 22:47:50 kp2a postfix/master[19055]: daemon started -- version
2.2.8, configuration /etc/postfix
Jun 13 22:47:50 kp2a postfix/qmgr[19058]: A998F10C8CAE: from=,
size=122823, nrcpt=1 (queue active)
Jun 13 22:47:50 kp2a spamd[17507]: spamd: connection from kp2a.vi
[127.0.0.1] at port 48988
Jun 13 22:47:50 kp2a spamd[17507]: spamd: setuid to spamfilter succeeded
Jun 13 22:47:50 kp2a spamd[17507]: spamd: processing message
[EMAIL PROTECTED] for spamfilter:509
Jun 13 22:47:51 kp2a sendmail[19063]: k5E2lpPd019063:
Authentication-Warning: kp2a.vi: spamfilter set sender to
[EMAIL PROTECTED] using -f
Jun 13 22:47:51 kp2a spamd[17507]: spamd: clean message (-1.4/5.0) for
spamfilter:509 in 0.8 seconds, 120383 bytes.
Jun 13 22:47:51 kp2a spamd[17507]: spamd: result: . -1 -
ALL_TRUSTED,AWL,SPF_HELO_PASS
scantime=0.8,size=120383,user=spamfilter,uid=509,required_score=5.0,rhost=kp2a.vi,raddr=127.0.0.1,rport=48988,mid=[EMAIL PROTECTED],autolearn=unavailable
Jun 13 22:47:51 kp2a spamd[17504]: prefork: child states: II
Jun 13 22:47:51 kp2a sendmail[19063]: k5E2lpPd019063:
[EMAIL PROTECTED], size=120387, class=0, nrcpts=1,
msgid=[EMAIL PROTECTED], [EMAIL PROTECTED]
Jun 13 22:47:51 kp2a postfix/smtpd[19064]: connect from kp2a.vi[127.0.0.1]
Jun 13 22:47:51 kp2a postfix/smtpd[19064]: 9B1E810C8CAC:
client=kp2a.vi[127.0.0.1]
Jun 13 22:47:51 kp2a postfix/cleanup[19066]: 9B1E810C8CAC:
message-id=[EMAIL PROTECTED]
Jun 13 22:47:51 kp2a postfix/qmgr[19058]: 9B1E810C8CAC: from=,
size=123238, nrcpt=1 (queue active)
this last entry is the start of an identical cycle - except file is
bigger now?
help!
Versions:
Linux kp2a.vi 2.6.16-1.2122_FC5smp #1 SMP i686 athlon i386
GNU/Linux
Mail-SpamAssassin-3.1.3 [EMAIL PROTECTED] ~]$ perl -v
This is perl, v5.8.8 built for i386-linux-thread-multi
postfix.i386 2:2.2.8-1.2 installed
Running processes:
[EMAIL PROTECTED] postfix]# ps auxw | grep spam*
root 17504 0.0 2.4 30416 25124 ?Ss 20:04 0:01
/usr/bin/spamd -d -c -m5 -H -
r /var/run/spamd.pid
509 17507 0.5 4.2 49488 44072 ?R20:04 1:01 spamd child
root 18818 0.0 2.2 30416 23424 ?S22:43 0:00 spamd child
postfix 19388 0.0 0.1 6176 1780 ?S23:01 0:00 pipe -n
spamfilter -t unix fl
ags=Rq user=spamfilter argv=/usr/bin/postfixfilter -f${sender} --
${recipient}
postfix 19393 0.5 0.2 6324 2284 ?S23:01 0:00 smtpd
-n smtp -t inet -u -s 2
-o content_filter spamfilter:
postfix 19396 0.0 0.1 6176 1776 ?S23:01 0:00 pipe -n
spamfilter -t unix fl
ags=Rq user=spamfilter argv=/usr/bin/postfixfilter -f${sender} --
${recipient}
509 19403 0.0 0.1 4596 1280 ?R23:01 0:00
/usr/bin/spamc
Re: The Future of Email is SQL
On Jun 13, 2006, at 7:52 PM, Marc Perkel wrote: John Rudd wrote: and maybe a decent perl MTA to put in front of it too (something that will work with sendmail milters...). I think that a local delivery program could be written fairly easily that Exim or any other existing MTA could pipe messages into for delivery. So one wouldn't have to rewrite the MTA but just use existing MTAs and just change the delivery mechanism. It's not a matter of have to. It's a matter of want to.
Re: The Future of Email is SQL
John Rudd wrote: On Jun 13, 2006, at 7:52 PM, Marc Perkel wrote: John Rudd wrote: and maybe a decent perl MTA to put in front of it too (something that will work with sendmail milters...). I think that a local delivery program could be written fairly easily that Exim or any other existing MTA could pipe messages into for delivery. So one wouldn't have to rewrite the MTA but just use existing MTAs and just change the delivery mechanism. It's not a matter of have to. It's a matter of want to. Well - I'm a member of the Exim cult - but if something better comes along I might convert. :)
Re: The Future of Email is SQL
Thank you for a very well thought out *open* message. I would guess that most of these reasons are why DBMail was started 5 years ago ;) I'm gonna response with some pro-DBMail stuff... just because it's in my head and pretty much addresses all of Marc's comments below. Marc Perkel wrote: This is still visionary so take it for what it's worth. People are more familiar with MAILDIR and MBOX because they are files. You can read them with VI and PICO and FGREP and all the stuff that we are familiar with. MySQL is also easy but might require new tools and some learning. Once you become familiar with it them everything is just as easy. One could expoir and import to and from maildir and mbox, so that doesn't go away. DBMail has both a maildir import and export. With MySQL there are a lot of problems that go away. MySQL is a magic port that does everything for you. It doesn't care about what filesystem you're using, what OS you are running, what kinds of file locks or NFS mounts, or if you're using Reiser for maildir speed or if you have enough inodes. All that stuff goes away. One of the great aspects of DBMail... SQL Clustering and replication independent of the OS. Cyrus and other great IMAP server have only recently gotten this working in Alpha versions. Otherwise it would require very expensive storage solutions to get any kind of failover or realtime replication. With DBMail/MySQL just setup another cheap server and configure replication done. MBOX and MAILDIR have no indexing. You can add indexes externally but there are no standards for that. With MySQL you can index anything and everything. You can add fields to the message, any fiels, as many as you want, and they too can be keys and indexes. With maildir and mbox you can't really do that. Many of the filesystem storage solutions do have indexing, but in file hashes. Zimbra has gone so far as to have a filesystem store with MySQL indexes for speed. As you point out these are not standard and don't scale unless they are on an expensive storage solution. With MySQL you can access the data with any MySQL application. And the access is consistent no matter what programming language you use, what OS you use, anything. It's all SQL. So if you want a web interface you just write a PHP app. There are a number of PHP and other scripts that access SQL directly for everything from webmail to administration... works great and very easy to work with. Spamassassin for example has migrated from GB files to MySQL for the AWL and bayes and we all can see how this has improved performance and ease of implementation. Before SQL having 5 servers sharing the same bayes is difficult. With SQL it's trivial. The SQL does it all for you. They do the magic so you don't have to. The indexing is a real key feature. If I have a key based on the sending host or index all the received lines, I could delete all messages that had an IP in any received line almost instantly. I can do it thousands of times faster than mbox or maildir because it's indexed. Indexing gives you incredible power and the SQL engine does all that for you. That SA and the IMAP and the MTA and the Web GUI - everything - all taking to a standard database - all integrated - all comnpatible. So - like I said - this is visionary stuff. Think SQL - think outside the box. It is visionary in that it is not the norm, but again DBMail does all of this very well and has been production quality for quite some time. This is a great thread, but as far as starting a new project I'd just go with what is already working. DBMail is built in C, so very speedy. Someone mentioned rewriting an IMAP server in perl... not sure if I'd go that way from a speed standpoint, but would certainly be interesting. If you are looking for another approach Zimbra is written entirely in Java and Open. It uses only MySQL indexes, but would be very straight forward to replace its existing MailStore Class with one that writes to MySQL rather than the filesystem. -- Kevin Baker begin:vcard fn:Kevin Baker n:Baker;Kevin email;internet:[EMAIL PROTECTED] tel;work:858-454-5532 version:2.1 end:vcard
