[spamdyke-users] munin plugin
For those using munin, I've uploaded on MuninExchange a spamdyke plugin : http://muninexchange.projects.linpro.no/?searchcid=21pid=171phid=240 tested with munin debian package, works fine (plugin based on the postfix plugin, awful shell code but it works :) have a nice day -- Sébastien ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] More robust wildcards in recipient-whitelist-file?
I'm pretty sure that square brackets are not valid email address characters. Given this, maybe some sort of scheme where [] would delineate wildcards. Regular expressions may not be so easy, since [] are meaningful inside them, but perhaps something simple like and asterisk representing zero or more any char, and a question mark representing a single any char. Like this: [EMAIL PROTECTED] would match: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] but not [EMAIL PROTECTED] and [EMAIL PROTECTED] would match: [EMAIL PROTECTED] but not [EMAIL PROTECTED] etc. Marc - Original Message - From: Sam Clippinger [EMAIL PROTECTED] To: spamdyke users spamdyke-users@spamdyke.org Sent: Monday, October 29, 2007 12:18 PM Subject: Re: [spamdyke-users] More robust wildcards inrecipient-whitelist-file? Yes, starting a line with @ is the only available wildcard. I thought about doing more, just like you're asking about, but I got hung up on the complexities. Email addresses allow so many characters that it's hard to find a good way to indicate a wildcard. I was also afraid that no matter what I tried to implement, it wouldn't work for all situations -- the best solution would be to just use full regular expressions. Then I became concerned that using regular expressions would cause problems if someone just filled the file with email addresses and they wound up being matched as regexps. That's where my thinking ended and I went with the current solution. What do you think? I'm open to suggestions. -- Sam Clippinger Marc Van Houwelingen wrote: Thanks for adding the recipient-whitelist-file feature. I have a quick question: Is starting a line with @ the only wildcard ability? What I would like to do is have something like this: #--recipient-blacklist-file:--- @mydomain.com #-- #--recipient-whitelist-file:--- [EMAIL PROTECTED] #-- The intention is for spamdyke to block all email coming in for that domain, except anything matching [EMAIL PROTECTED] (eg [EMAIL PROTECTED], [EMAIL PROTECTED], etc) Is this possible now, or perhaps in future versions? ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] More robust wildcards in recipient-whitelist-file?
Marc Van Houwelingen ha scritto: I'm pretty sure that square brackets are not valid email address characters. Given this, maybe some sort of scheme where [] would delineate wildcards. Regular expressions may not be so easy, since [] are meaningful inside them, but perhaps something simple like and asterisk representing zero or more any char, and a question mark representing a single any char. I'm not sure about the usefulness of this kind of functionalities in spamdyke. After all, there are a lot of patches that implements regexp feature in baldmailfrom/badmail to, directly plugged in qmail-smtpd. I know that it require a patched qmail but, in 2007 , Who's still use a vanilla qmail ? Would be better to focus on new features instead of implementing some that is already in qmail . This is my 2 cents . ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] More robust wildcards in recipient-whitelist-file?
Actually, brackets are legal in email addresses. The full list of legal characters is (as far as I know): a-z A-Z 0-9 @ / : . # [ ] - \ _ = , ! On my keyboard, that doesn't leave much and I can't guarantee the remaining characters aren't legal either. I'm not sure I want to use a tilde as a wildcard simply because it's available -- it's not very intuitive. This just occurred to me -- what about creating a new flag to allow regular expressions? For example, recipient-whitelist-file would use the existing logic but recipient-whitelist-file-regexp would allow regular expressions and wildcards. That way, nearly everyone would continue using the existing system but if someone needed more flexibility they could create a second file and use the new flag. Or does that sound too complicated? -- Sam Clippinger Marc Van Houwelingen wrote: I'm pretty sure that square brackets are not valid email address characters. Given this, maybe some sort of scheme where [] would delineate wildcards. Regular expressions may not be so easy, since [] are meaningful inside them, but perhaps something simple like and asterisk representing zero or more any char, and a question mark representing a single any char. Like this: [EMAIL PROTECTED] would match: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] but not [EMAIL PROTECTED] and [EMAIL PROTECTED] would match: [EMAIL PROTECTED] but not [EMAIL PROTECTED] etc. Marc - Original Message - From: Sam Clippinger [EMAIL PROTECTED] To: spamdyke users spamdyke-users@spamdyke.org Sent: Monday, October 29, 2007 12:18 PM Subject: Re: [spamdyke-users] More robust wildcards inrecipient-whitelist-file? Yes, starting a line with @ is the only available wildcard. I thought about doing more, just like you're asking about, but I got hung up on the complexities. Email addresses allow so many characters that it's hard to find a good way to indicate a wildcard. I was also afraid that no matter what I tried to implement, it wouldn't work for all situations -- the best solution would be to just use full regular expressions. Then I became concerned that using regular expressions would cause problems if someone just filled the file with email addresses and they wound up being matched as regexps. That's where my thinking ended and I went with the current solution. What do you think? I'm open to suggestions. -- Sam Clippinger Marc Van Houwelingen wrote: Thanks for adding the recipient-whitelist-file feature. I have a quick question: Is starting a line with @ the only wildcard ability? What I would like to do is have something like this: #--recipient-blacklist-file:--- @mydomain.com #-- #--recipient-whitelist-file:--- [EMAIL PROTECTED] #-- The intention is for spamdyke to block all email coming in for that domain, except anything matching [EMAIL PROTECTED] (eg [EMAIL PROTECTED], [EMAIL PROTECTED], etc) Is this possible now, or perhaps in future versions? ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
[spamdyke-users] another subject...
qsheff hasn't been updated in about a year, and the last released version will kill your mail server (literally) with e-mail eating bugs. if someone was willing to take this under their wing and maybe just rip out the functionality other than anti-virus, that would be cool ;) in all seriousness, it looks to me like shortly clamav or one of the other tools will be updated and qsheff won't be able to check for viruses anymore... qsheff remains the only program of its type that I know of which can keep up with a busy mail server - the rest all seem to be implemented through perl or python, which kills the performance of the system thoughts? sam, are you interested in a one-two punch or do you plan to add antivirus to your daemonized version? this fan of spamdyke would love to know :) -- -- Cheers, Steve ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] More robust wildcardsin recipient-whitelist-file?
I was looking here: http://en.wikipedia.org/wiki/E-mail_address, which does not list the brackets. Either way, the regexp flag sounds perfect. It may be a bit complicated, but of course does not have to be used. - Original Message - From: Sam Clippinger [EMAIL PROTECTED] To: spamdyke users spamdyke-users@spamdyke.org Sent: Tuesday, October 30, 2007 11:40 AM Subject: Re: [spamdyke-users] More robust wildcardsin recipient-whitelist-file? Actually, brackets are legal in email addresses. The full list of legal characters is (as far as I know): a-z A-Z 0-9 @ / : . # [ ] - \ _ = , ! On my keyboard, that doesn't leave much and I can't guarantee the remaining characters aren't legal either. I'm not sure I want to use a tilde as a wildcard simply because it's available -- it's not very intuitive. This just occurred to me -- what about creating a new flag to allow regular expressions? For example, recipient-whitelist-file would use the existing logic but recipient-whitelist-file-regexp would allow regular expressions and wildcards. That way, nearly everyone would continue using the existing system but if someone needed more flexibility they could create a second file and use the new flag. Or does that sound too complicated? -- Sam Clippinger Marc Van Houwelingen wrote: I'm pretty sure that square brackets are not valid email address characters. Given this, maybe some sort of scheme where [] would delineate wildcards. Regular expressions may not be so easy, since [] are meaningful inside them, but perhaps something simple like and asterisk representing zero or more any char, and a question mark representing a single any char. Like this: [EMAIL PROTECTED] would match: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] but not [EMAIL PROTECTED] and [EMAIL PROTECTED] would match: [EMAIL PROTECTED] but not [EMAIL PROTECTED] etc. Marc - Original Message - From: Sam Clippinger [EMAIL PROTECTED] To: spamdyke users spamdyke-users@spamdyke.org Sent: Monday, October 29, 2007 12:18 PM Subject: Re: [spamdyke-users] More robust wildcards inrecipient-whitelist-file? Yes, starting a line with @ is the only available wildcard. I thought about doing more, just like you're asking about, but I got hung up on the complexities. Email addresses allow so many characters that it's hard to find a good way to indicate a wildcard. I was also afraid that no matter what I tried to implement, it wouldn't work for all situations -- the best solution would be to just use full regular expressions. Then I became concerned that using regular expressions would cause problems if someone just filled the file with email addresses and they wound up being matched as regexps. That's where my thinking ended and I went with the current solution. What do you think? I'm open to suggestions. -- Sam Clippinger Marc Van Houwelingen wrote: Thanks for adding the recipient-whitelist-file feature. I have a quick question: Is starting a line with @ the only wildcard ability? What I would like to do is have something like this: #--recipient-blacklist-file:--- @mydomain.com #-- #--recipient-whitelist-file:--- [EMAIL PROTECTED] #-- The intention is for spamdyke to block all email coming in for that domain, except anything matching [EMAIL PROTECTED] (eg [EMAIL PROTECTED], [EMAIL PROTECTED], etc) Is this possible now, or perhaps in future versions? ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] More robust wildcardsin recipient-whitelist-file?
OK, I'll add that to my TODO list. I guess I need to figure out how to parse regexps. :) -- Sam Clippinger Marc Van Houwelingen wrote: I was looking here: http://en.wikipedia.org/wiki/E-mail_address, which does not list the brackets. Either way, the regexp flag sounds perfect. It may be a bit complicated, but of course does not have to be used. - Original Message - From: Sam Clippinger [EMAIL PROTECTED] To: spamdyke users spamdyke-users@spamdyke.org Sent: Tuesday, October 30, 2007 11:40 AM Subject: Re: [spamdyke-users] More robust wildcardsin recipient-whitelist-file? Actually, brackets are legal in email addresses. The full list of legal characters is (as far as I know): a-z A-Z 0-9 @ / : . # [ ] - \ _ = , ! On my keyboard, that doesn't leave much and I can't guarantee the remaining characters aren't legal either. I'm not sure I want to use a tilde as a wildcard simply because it's available -- it's not very intuitive. This just occurred to me -- what about creating a new flag to allow regular expressions? For example, recipient-whitelist-file would use the existing logic but recipient-whitelist-file-regexp would allow regular expressions and wildcards. That way, nearly everyone would continue using the existing system but if someone needed more flexibility they could create a second file and use the new flag. Or does that sound too complicated? -- Sam Clippinger Marc Van Houwelingen wrote: I'm pretty sure that square brackets are not valid email address characters. Given this, maybe some sort of scheme where [] would delineate wildcards. Regular expressions may not be so easy, since [] are meaningful inside them, but perhaps something simple like and asterisk representing zero or more any char, and a question mark representing a single any char. Like this: [EMAIL PROTECTED] would match: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] but not [EMAIL PROTECTED] and [EMAIL PROTECTED] would match: [EMAIL PROTECTED] but not [EMAIL PROTECTED] etc. Marc - Original Message - From: Sam Clippinger [EMAIL PROTECTED] To: spamdyke users spamdyke-users@spamdyke.org Sent: Monday, October 29, 2007 12:18 PM Subject: Re: [spamdyke-users] More robust wildcards inrecipient-whitelist-file? Yes, starting a line with @ is the only available wildcard. I thought about doing more, just like you're asking about, but I got hung up on the complexities. Email addresses allow so many characters that it's hard to find a good way to indicate a wildcard. I was also afraid that no matter what I tried to implement, it wouldn't work for all situations -- the best solution would be to just use full regular expressions. Then I became concerned that using regular expressions would cause problems if someone just filled the file with email addresses and they wound up being matched as regexps. That's where my thinking ended and I went with the current solution. What do you think? I'm open to suggestions. -- Sam Clippinger Marc Van Houwelingen wrote: Thanks for adding the recipient-whitelist-file feature. I have a quick question: Is starting a line with @ the only wildcard ability? What I would like to do is have something like this: #--recipient-blacklist-file:--- @mydomain.com #-- #--recipient-whitelist-file:--- [EMAIL PROTECTED] #-- The intention is for spamdyke to block all email coming in for that domain, except anything matching [EMAIL PROTECTED] (eg [EMAIL PROTECTED], [EMAIL PROTECTED], etc) Is this possible now, or perhaps in future versions? ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Morerobust wildcardsin recipient-whitelist-file?
Thanks. Possibly worth mentioning: it appears that parentheses are, in fact, illegal characters for an email address. - Original Message - From: Sam Clippinger [EMAIL PROTECTED] To: spamdyke users spamdyke-users@spamdyke.org Sent: Tuesday, October 30, 2007 1:01 PM Subject: Re: [spamdyke-users] Morerobust wildcardsin recipient-whitelist-file? OK, I'll add that to my TODO list. I guess I need to figure out how to parse regexps. :) -- Sam Clippinger Marc Van Houwelingen wrote: I was looking here: http://en.wikipedia.org/wiki/E-mail_address, which does not list the brackets. Either way, the regexp flag sounds perfect. It may be a bit complicated, but of course does not have to be used. - Original Message - From: Sam Clippinger [EMAIL PROTECTED] To: spamdyke users spamdyke-users@spamdyke.org Sent: Tuesday, October 30, 2007 11:40 AM Subject: Re: [spamdyke-users] More robust wildcardsin recipient-whitelist-file? Actually, brackets are legal in email addresses. The full list of legal characters is (as far as I know): a-z A-Z 0-9 @ / : . # [ ] - \ _ = , ! On my keyboard, that doesn't leave much and I can't guarantee the remaining characters aren't legal either. I'm not sure I want to use a tilde as a wildcard simply because it's available -- it's not very intuitive. This just occurred to me -- what about creating a new flag to allow regular expressions? For example, recipient-whitelist-file would use the existing logic but recipient-whitelist-file-regexp would allow regular expressions and wildcards. That way, nearly everyone would continue using the existing system but if someone needed more flexibility they could create a second file and use the new flag. Or does that sound too complicated? -- Sam Clippinger Marc Van Houwelingen wrote: I'm pretty sure that square brackets are not valid email address characters. Given this, maybe some sort of scheme where [] would delineate wildcards. Regular expressions may not be so easy, since [] are meaningful inside them, but perhaps something simple like and asterisk representing zero or more any char, and a question mark representing a single any char. Like this: [EMAIL PROTECTED] would match: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] but not [EMAIL PROTECTED] and [EMAIL PROTECTED] would match: [EMAIL PROTECTED] but not [EMAIL PROTECTED] etc. Marc - Original Message - From: Sam Clippinger [EMAIL PROTECTED] To: spamdyke users spamdyke-users@spamdyke.org Sent: Monday, October 29, 2007 12:18 PM Subject: Re: [spamdyke-users] More robust wildcards inrecipient-whitelist-file? Yes, starting a line with @ is the only available wildcard. I thought about doing more, just like you're asking about, but I got hung up on the complexities. Email addresses allow so many characters that it's hard to find a good way to indicate a wildcard. I was also afraid that no matter what I tried to implement, it wouldn't work for all situations -- the best solution would be to just use full regular expressions. Then I became concerned that using regular expressions would cause problems if someone just filled the file with email addresses and they wound up being matched as regexps. That's where my thinking ended and I went with the current solution. What do you think? I'm open to suggestions. -- Sam Clippinger Marc Van Houwelingen wrote: Thanks for adding the recipient-whitelist-file feature. I have a quick question: Is starting a line with @ the only wildcard ability? What I would like to do is have something like this: #--recipient-blacklist-file:--- @mydomain.com #-- #--recipient-whitelist-file:--- [EMAIL PROTECTED] #-- The intention is for spamdyke to block all email coming in for that domain, except anything matching [EMAIL PROTECTED] (eg [EMAIL PROTECTED], [EMAIL PROTECTED], etc) Is this possible now, or perhaps in future versions? ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users ___ spamdyke-users mailing list spamdyke-users@spamdyke.org
Re: [spamdyke-users] another subject...
On Tuesday 30 October 2007, Sam Clippinger wrote: I'm not familiar with qsheff, so I hadn't given any thought to trying to replace it. Personally, I use qmail-scanner (qmail-scanner.sourceforge.net). Yes, but the issue we have with qmail-scanner is that our e-mail system moves around 1.2M messages a day (~40,000 mailboxes) and under that kind of load, qmail-scanner rolls tits-up and dies because it has all the overhead of Perl starting up and loading extensions. qsheff is written in C and self-contained binary compiled with -Os is about 25KB. It incorporates direct access to CLAMAV through its library and so supports clamd. The last working version of qsheff is 2.1-r1 and I have the archive if anyone is interested in taking it under their wing. Don't really mean to hijack the list, I see qsheff as the 2nd step to an existing spamdyke solution for e-mail. Ideally if someone took it on, it could be made to complement spamdyke even better. Note to anyone thinking of trying it: do not use 2.1-r2 or you will lose mail. The last working version is 2.1-r1. You have been warned. :) -- Cheers, Steve ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] another subject...
Steve Cole ha scritto: Yes, but the issue we have with qmail-scanner is that our e-mail system moves The last working version is 2.1-r1. You have been warned. :) Have you tried the r3 ? have fun, Davide ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
