Re: [spamdyke-users] 0byte graylist entries
Hello Peter, In the end, what worked well for me was: find /var/qmail/./ -type f -size 0c -mtime +3 -print which someone else suggested Thank you for taking the time to respond. Kind Regards, Christoph From: spamdyke-users-boun...@spamdyke.org [mailto:spamdyke-users-boun...@spamdyke.org] On Behalf Of Peter Palmreuther Sent: 30 December 2013 22:36 To: spamdyke users Subject: Re: [spamdyke-users] 0byte graylist entries Hello Christoph, Am 17.12.2013 um 11:36 schrieb emailitis.com http://emailitis.com off...@emailitis.com mailto:off...@emailitis.com : I would like to delete any files that are 0 bytes in size AND are over 3 days old. I tried to be clever: find /var/qmail/graylist/. -type f -size 0 -mtime +3 -print (missed out the -delete until I had checked, luckily as it happens). but that lists all those that are greater than 3 days and ignores the -size 0 in there. Have you tried find /var/.../ -type f -empty -mtime +3 ? -- Regards, Peter ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
Hello Christoph, Am 17.12.2013 um 11:36 schrieb emailitis.com off...@emailitis.com: I would like to delete any files that are 0 bytes in size AND are over 3 days old. I tried to be clever: find /var/qmail/graylist/beadonbrook.com/. -type f -size 0 -mtime +3 –print (missed out the –delete until I had checked, luckily as it happens). but that lists all those that are greater than 3 days and ignores the “-size 0” in there. Have you tried find /var/.../ -type f -empty -mtime +3 ? -- Regards, Peter___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
Hi Gary, I love your easy to execute scripts, thank you. I would like to delete any files that are 0 bytes in size AND are over 3 days old. I tried to be clever: find /var/qmail/graylist/beadonbrook.com/. -type f -size 0 -mtime +3 -print (missed out the -delete until I had checked, luckily as it happens). but that lists all those that are greater than 3 days and ignores the -size 0 in there. Can you help with how best to do that? Kind Regards, Christoph From: spamdyke-users-boun...@spamdyke.org [mailto:spamdyke-users-boun...@spamdyke.org] On Behalf Of Gary Gendel Sent: 23 November 2013 02:09 To: spamdyke users Subject: Re: [spamdyke-users] 0byte graylist entries My graylists do get constantly pruned but others seem to have old ones remaining. Then again, my graylist-max-secs is set to 1296000 (one day) which is probably shorter than most. On 11/22/13, 8:15 PM, BC wrote: Interesting. I've been doing it this way - should I stop? # time to delete old, empty graylist entries older than 15 days (empty files empty directories) find /var/qmail/antispam/graylist/ -type f -mtime +15 -print -delete find /var/qmail/antispam/graylist/ -empty -type d -mtime +15 -print -delete I run these in that order. Seems to do as I ask... On 11/22/2013 10:09 AM, Eric Shubert wrote: On 11/19/2013 04:46 AM, Gary Gendel wrote: Spamdyke does clean up these files periodically (as set by graylist-max-secs) I don't believe this is entirely true. Spamdyke will honor/see these expirations only if/when another email is sent after this time has elapsed, in which case the graylist process starts anew. Over time, un-resent records accumulate, which can take its toll on inodes. This is why I wrote the qtp-prune-graylist script: http://qtp.qmailtoaster.com/trac/browser/bin/qtp-prune-graylist :) Come to think of it, I should package that script with the spamdyke rpm. Oh, I should mention that you can find rpms for spamdyke at http://mirrors.qmailtoaster.com/. They're presently in the /testing directory, and will migrate to /current (stable) once everything's been tested. The spamdyke package should already be solid though. Very soon you'll be able to use yum to install it as well, once the qmailtoaster-release package (containing the yum repo stuff for QMT) is available. Note for posterity: the qtp web site is being migrated/integrated with the QMailToaster organization at GitHub: https://github.com/QMailToaster Look for this script there if the qtp.qmailtoaster.com site is gone. It might be in the spamdyke package there. :) ___ spamdyke-users mailing list spamdyke-users@spamdyke.org mailto: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] 0byte graylist entries
There's a units parameter along with the size. My man page doesn't indicate a default value. I'd try: -size 0c On 12/17/2013 03:36 AM, emailitis.com wrote: Hi Gary, I love your easy to execute scripts, thank you. I would like to delete any files that are 0 bytes in size AND are over 3 days old. I tried to be clever: find /var/qmail/graylist/beadonbrook.com/. -type f -size 0 -mtime +3 –print (missed out the –delete until I had checked, luckily as it happens). but that lists all those that are greater than 3 days and ignores the “-size 0” in there. Can you help with how best to do that? Kind Regards, Christoph *From:*spamdyke-users-boun...@spamdyke.org [mailto:spamdyke-users-boun...@spamdyke.org] *On Behalf Of *Gary Gendel *Sent:* 23 November 2013 02:09 *To:* spamdyke users *Subject:* Re: [spamdyke-users] 0byte graylist entries My graylists do get constantly pruned but others seem to have old ones remaining. Then again, my graylist-max-secs is set to 1296000 (one day) which is probably shorter than most. On 11/22/13, 8:15 PM, BC wrote: Interesting. I've been doing it this way - should I stop? # time to delete old, empty graylist entries older than 15 days (empty files empty directories) find /var/qmail/antispam/graylist/ -type f -mtime +15 -print -delete find /var/qmail/antispam/graylist/ -empty -type d -mtime +15 -print -delete I run these in that order. Seems to do as I ask... On 11/22/2013 10:09 AM, Eric Shubert wrote: On 11/19/2013 04:46 AM, Gary Gendel wrote: Spamdyke does clean up these files periodically (as set by graylist-max-secs) I don't believe this is entirely true. Spamdyke will honor/see these expirations only if/when another email is sent after this time has elapsed, in which case the graylist process starts anew. Over time, un-resent records accumulate, which can take its toll on inodes. This is why I wrote the qtp-prune-graylist script: http://qtp.qmailtoaster.com/trac/browser/bin/qtp-prune-graylist :) Come to think of it, I should package that script with the spamdyke rpm. Oh, I should mention that you can find rpms for spamdyke at http://mirrors.qmailtoaster.com/. They're presently in the /testing directory, and will migrate to /current (stable) once everything's been tested. The spamdyke package should already be solid though. Very soon you'll be able to use yum to install it as well, once the qmailtoaster-release package (containing the yum repo stuff for QMT) is available. Note for posterity: the qtp web site is being migrated/integrated with the QMailToaster organization at GitHub:https://github.com/QMailToaster Look for this script there if the qtp.qmailtoaster.com site is gone. It might be in the spamdyke package there. :) ___ spamdyke-users mailing list spamdyke-users@spamdyke.org mailto: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 -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
I don't see a real problem here. I think the -mtime parameter on directories causes empty directories to stick around longer than need be though. The script is a bit nicer in my mind. It processes each domain individually, and optionally gives statistics regarding what it did, without listing every single file/directory it deleted. Note, the stats take an additional find to count the total number of graylist entries, so it runs a little longer than when it's run silently. Having said that, I've come to the conclusion that graylisting isn't worth it to me. I disabled graylisting several months ago, and haven't really noticed any less effectiveness. Measuring the effectiveness of graylisting properly is very difficult, and it's a pain for users (myself included) at times. With all of the other filters spamdyke provides, I don't think the cost of graylisting is worth the benefit. Of course, YMMV. -- -Eric 'shubes' On 11/22/2013 06:15 PM, BC wrote: Interesting. I've been doing it this way - should I stop? # time to delete old, empty graylist entries older than 15 days (empty files empty directories) find /var/qmail/antispam/graylist/ -type f -mtime +15 -print -delete find /var/qmail/antispam/graylist/ -empty -type d -mtime +15 -print -delete I run these in that order. Seems to do as I ask... On 11/22/2013 10:09 AM, Eric Shubert wrote: On 11/19/2013 04:46 AM, Gary Gendel wrote: Spamdyke does clean up these files periodically (as set by graylist-max-secs) I don't believe this is entirely true. Spamdyke will honor/see these expirations only if/when another email is sent after this time has elapsed, in which case the graylist process starts anew. Over time, un-resent records accumulate, which can take its toll on inodes. This is why I wrote the qtp-prune-graylist script: http://qtp.qmailtoaster.com/trac/browser/bin/qtp-prune-graylist :) Come to think of it, I should package that script with the spamdyke rpm. Oh, I should mention that you can find rpms for spamdyke at http://mirrors.qmailtoaster.com/. They're presently in the /testing directory, and will migrate to /current (stable) once everything's been tested. The spamdyke package should already be solid though. Very soon you'll be able to use yum to install it as well, once the qmailtoaster-release package (containing the yum repo stuff for QMT) is available. Note for posterity: the qtp web site is being migrated/integrated with the QMailToaster organization at GitHub:https://github.com/QMailToaster Look for this script there if the qtp.qmailtoaster.com site is gone. It might be in the spamdyke package there. :) ___ 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] 0byte graylist entries
On 11/23/2013 8:55 AM, Eric Shubert wrote: Having said that, I've come to the conclusion that graylisting isn't worth it to me. I disabled graylisting several months ago, and haven't really noticed any less effectiveness. Measuring the effectiveness of graylisting properly is very difficult, and it's a pain for users (myself included) at times. With all of the other filters spamdyke provides, I don't think the cost of graylisting is worth the benefit. Of course, YMMV. Curious you bring that up. In perusing the logs, it (very subjectively) looks like r_dns lookups are blocking 95% of the spam, RBL is getting about 4% and graylisting is only being invoked about 1% of the time. But what is the "cost of graylisting"? Graylisting delays a legit email by X amount of minutes. Is that the pain of which you are talking? ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
On 11/23/2013 09:05 AM, BC wrote: On 11/23/2013 8:55 AM, Eric Shubert wrote: Having said that, I've come to the conclusion that graylisting isn't worth it to me. I disabled graylisting several months ago, and haven't really noticed any less effectiveness. Measuring the effectiveness of graylisting properly is very difficult, and it's a pain for users (myself included) at times. With all of the other filters spamdyke provides, I don't think the cost of graylisting is worth the benefit. Of course, YMMV. Curious you bring that up. In perusing the logs, it (very subjectively) looks like r_dns lookups are blocking 95% of the spam, RBL is getting about 4% and graylisting is only being invoked about 1% of the time. That feels about right to me, again very subjectively. The tough part about measuring graylisting is that of the 1% of the times it's invoked how many were spam? It's pretty hard to tell. I don't know of anyone who's measured this accurately. I suppose the pruning script could be modified (quite easily in fact) to give a count of how many empty files it removed. I think that would be an accurate measure. I'm a little surprised I didn't think of that the last time I edited the script. I'll see about making that change when I put the script in the spamdyke rpm (and on github). But what is the cost of graylisting? Graylisting delays a legit email by X amount of minutes. Is that the pain of which you are talking? Yes. I realize that the impact of the delay is infrequent, but when it happens, it's really annoying, and it impacts productivity. In my case, it usually happens when an email confirmation or notification of some sort is required to do something. This is the absolute worst time for there to be a delay, as it interrupts that process. As a user, I was very happy to have graylisting turned off. As an email administrator, I am tired of trying to explain how delaying delivery of email is necessary to help reduce spam. Graylisting is simply not a good solution because of the negative impact on the users. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
On 11/23/2013 9:39 AM, Eric Shubert wrote: But what is the "cost of graylisting"? Graylisting delays a legit email by X amount of minutes. Is that the pain of which you are talking? Yes. I realize that the impact of the delay is infrequent, but when it happens, it's really annoying, and it impacts productivity. In my case, it usually happens when an email confirmation or notification of some sort is required to do something. This is the absolute worst time for there to be a delay, as it interrupts that process. Haha. Now that is a good point and I've been annoyed by that as well. Perhaps I'll try turning off graylisting for a while and see if it makes much difference. Thanks! ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
BC wrote: Yes. I realize that the impact of the delay is infrequent, but when it happens, it's really annoying, and it impacts productivity. In my case, it usually happens when an email confirmation or notification of some sort is required to do something. This is the absolute worst time for there to be a delay, as it interrupts that process. If you have control over the server, then you should be able to whitelist the domain from which you expect the confirmation email to come. An alternative might be to create a special form of your email address for anything likely to require a confirmation or verification (something like 'youraddress+subscripti...@yourdomain.com'?) and add that to Spamdyke's recipient whitelist so that anything sent to it doesn't get graylisted. That's more risky, because it strips off spamdyke's protection for anything that might get sent to that address (and experience has shown that sooner or later spammers _will_ discover your email address, even if you use it only for things that you think are safe), but it might resolve your problem in the short term. Angus ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
On 11/23/2013 09:39 AM, Eric Shubert wrote: I suppose the pruning script could be modified (quite easily in fact) to give a count of how many empty files it removed. I think that would be an accurate measure. I'm a little surprised I didn't think of that the last time I edited the script. I'll see about making that change when I put the script in the spamdyke rpm (and on github). The modified script is available here: https://github.com/QMailToaster/pkgs/blob/master/spamdyke/sd-prune-graylist I'd be interested to see some results if someone would care to post their counts. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
For what it's worth, I agree. Graylisting was designed to stop spam coming from spambots on infected home PCs -- because they're not real mail servers, they won't retry their deliveries. But the rDNS and blacklist filters seem to stop almost all deliveries from home PCs these days, so graylisting almost becomes redundant. (It's always fascinated me that the authors of those spambots didn't implement a retry feature -- it would have been so simple to do...) It seems to me the most effective spam these days is coming from compromised email accounts -- a spammer gets someone's password and pumps thousands of messages through their mail server with the user's credentials. I've added some additional filters to spamdyke's next version to limit allowed sender addresses after authentication -- the address can be required to exactly match the authentication username or just the domain can be required to match. Next version coming Real Soon Now(tm)! :) -- Sam Clippinger On Nov 23, 2013, at 10:39 AM, Eric Shubert wrote: On 11/23/2013 09:05 AM, BC wrote: On 11/23/2013 8:55 AM, Eric Shubert wrote: Having said that, I've come to the conclusion that graylisting isn't worth it to me. I disabled graylisting several months ago, and haven't really noticed any less effectiveness. Measuring the effectiveness of graylisting properly is very difficult, and it's a pain for users (myself included) at times. With all of the other filters spamdyke provides, I don't think the cost of graylisting is worth the benefit. Of course, YMMV. Curious you bring that up. In perusing the logs, it (very subjectively) looks like r_dns lookups are blocking 95% of the spam, RBL is getting about 4% and graylisting is only being invoked about 1% of the time. That feels about right to me, again very subjectively. The tough part about measuring graylisting is that of the 1% of the times it's invoked how many were spam? It's pretty hard to tell. I don't know of anyone who's measured this accurately. I suppose the pruning script could be modified (quite easily in fact) to give a count of how many empty files it removed. I think that would be an accurate measure. I'm a little surprised I didn't think of that the last time I edited the script. I'll see about making that change when I put the script in the spamdyke rpm (and on github). But what is the cost of graylisting? Graylisting delays a legit email by X amount of minutes. Is that the pain of which you are talking? Yes. I realize that the impact of the delay is infrequent, but when it happens, it's really annoying, and it impacts productivity. In my case, it usually happens when an email confirmation or notification of some sort is required to do something. This is the absolute worst time for there to be a delay, as it interrupts that process. As a user, I was very happy to have graylisting turned off. As an email administrator, I am tired of trying to explain how delaying delivery of email is necessary to help reduce spam. Graylisting is simply not a good solution because of the negative impact on the users. -- -Eric 'shubes' ___ 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] 0byte graylist entries
Thank you, Sam. spamdyke is a wonderful spam blocker! On 11/23/2013 2:43 PM, Sam Clippinger wrote: For what it's worth, I agree. Graylisting was designed to stop spam coming from spambots on infected home PCs -- because they're not "real" mail servers, they won't retry their deliveries. But the rDNS and blacklist filters seem to stop almost all deliveries from home PCs these days, so graylisting almost becomes redundant. (It's always fascinated me that the authors of those spambots didn't implement a retry feature -- it would have been so simple to do...) It seems to me the most "effective" spam these days is coming from compromised email accounts -- a spammer gets someone's password and pumps thousands of messages through their mail server with the user's credentials. I've added some additional filters to spamdyke's next version to limit allowed sender addresses after authentication -- the address can be required to exactly match the authentication username or just the domain can be required to match. Next version coming Real Soon Now(tm)! :) -- Sam Clippinger ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
Thanks Gary. That makes total sense. Unfortunately the file definitely wasn't protected in any way, so this incident is still a bit of a mystery. On a related matter, however, am I correct in thinking that if a graylisted sender resends after the -min interval but fails to pass another filter (which on my systems includes DENIED_OTHER which can indicate a full mailbox or a spamassassin/clamav fail), their graylisting file will not be updated - i.,e. they could still have a 0 byte graylist file, as though they never resent? Or am I imagining that I read something like this in the docs? This isn't what happened in the incident I'm talking about - I'm just thinking in general terms. Faris. (please excuse the HTML in my reply) It's my understanding (which may be faulty) that spamdyke always creates a 0 byte file the first time it gets mail from the domain. When it sees another email from that domain (after the prerequisite graylist-min-secs delay) then it puts the sending server into the file and allows the mail to go through as long as mail comes from that exact server. This is why you sometimes see multiple servers listed in the graylist file. Spamdyke does clean up these files periodically (as set by graylist-max-secs) My guess is that this file was protected, preventing spamdyke from doing it's job. This could happen if someone changed the owner of the file or it's permissions. Gary ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
Faris, I thought there was a spamdyke flowchart somewhere, but my mind must be playing tricks because I couldn't find it. Logically, it would seem to me that order would be: Check all whitelists, if found then accept the mail Check all blacklists, if found then reject the mail It it passes the above checks then do graylisting. If it accepts the mail then it sends it on to qmail for further processing. Since qmail is where the spamassassin, etc. hooks are, my understanding is that the graylist would be updated before any DENIED_OTHER issues. I haven't checked this hypothesis with experimentation or documentation so YMMV. Gary On 11/22/2013 05:24 AM, Faris Raouf wrote: Thanks Gary. That makes total sense. Unfortunately the file definitely wasn't protected in any way, so this incident is still a bit of a mystery. On a related matter, however, am I correct in thinking that if a graylisted sender resends after the --min interval but fails to pass another filter (which on my systems includes DENIED_OTHER which can indicate a full mailbox or a spamassassin/clamav fail), their graylisting file will not be updated -- i.,e. they could still have a 0 byte graylist file, as though they never resent? Or am I imagining that I read something like this in the docs? This isn't what happened in the incident I'm talking about -- I'm just thinking in general terms. Faris. (please excuse the HTML in my reply) It's my understanding (which may be faulty) that spamdyke always creates a 0 byte file the first time it gets mail from the domain. When it sees another email from that domain (after the prerequisite graylist-min-secs delay) then it puts the sending server into the file and allows the mail to go through as long as mail comes from that exact server. This is why you sometimes see multiple servers listed in the graylist file. Spamdyke does clean up these files periodically (as set by graylist-max-secs) My guess is that this file was protected, preventing spamdyke from doing it's job. This could happen if someone changed the owner of the file or it's permissions. Gary ___ 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] 0byte graylist entries
On 11/19/2013 04:46 AM, Gary Gendel wrote: Spamdyke does clean up these files periodically (as set by graylist-max-secs) I don't believe this is entirely true. Spamdyke will honor/see these expirations only if/when another email is sent after this time has elapsed, in which case the graylist process starts anew. Over time, un-resent records accumulate, which can take its toll on inodes. This is why I wrote the qtp-prune-graylist script: http://qtp.qmailtoaster.com/trac/browser/bin/qtp-prune-graylist :) Come to think of it, I should package that script with the spamdyke rpm. Oh, I should mention that you can find rpms for spamdyke at http://mirrors.qmailtoaster.com/. They're presently in the /testing directory, and will migrate to /current (stable) once everything's been tested. The spamdyke package should already be solid though. Very soon you'll be able to use yum to install it as well, once the qmailtoaster-release package (containing the yum repo stuff for QMT) is available. Note for posterity: the qtp web site is being migrated/integrated with the QMailToaster organization at GitHub: https://github.com/QMailToaster Look for this script there if the qtp.qmailtoaster.com site is gone. It might be in the spamdyke package there. :) -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
I think the list you're looking for is here: http://www.spamdyke.org/documentation/FAQ.html#FEATURE1 And you're correct about the order of operation -- the graylist filter is completely finished before the message is passed to qmail, which means it passed graylisting and was later stopped by qmail (logged with DENIED_OTHER). -- Sam Clippinger On Nov 22, 2013, at 5:36 AM, Gary Gendel wrote: Faris, I thought there was a spamdyke flowchart somewhere, but my mind must be playing tricks because I couldn't find it. Logically, it would seem to me that order would be: Check all whitelists, if found then accept the mail Check all blacklists, if found then reject the mail It it passes the above checks then do graylisting. If it accepts the mail then it sends it on to qmail for further processing. Since qmail is where the spamassassin, etc. hooks are, my understanding is that the graylist would be updated before any DENIED_OTHER issues. I haven't checked this hypothesis with experimentation or documentation so YMMV. Gary On 11/22/2013 05:24 AM, Faris Raouf wrote: Thanks Gary. That makes total sense. Unfortunately the file definitely wasn’t protected in any way, so this incident is still a bit of a mystery. On a related matter, however, am I correct in thinking that if a graylisted sender resends after the “–min” interval but fails to pass another filter (which on my systems includes DENIED_OTHER which can indicate a full mailbox or a spamassassin/clamav fail), their graylisting file will not be updated – i.,e. they could still have a 0 byte graylist file, as though they never resent? Or am I imagining that I read something like this in the docs? This isn’t what happened in the incident I’m talking about – I’m just thinking in general terms. Faris. (please excuse the HTML in my reply) It's my understanding (which may be faulty) that spamdyke always creates a 0 byte file the first time it gets mail from the domain. When it sees another email from that domain (after the prerequisite graylist-min-secs delay) then it puts the sending server into the file and allows the mail to go through as long as mail comes from that exact server. This is why you sometimes see multiple servers listed in the graylist file. Spamdyke does clean up these files periodically (as set by graylist-max-secs) My guess is that this file was protected, preventing spamdyke from doing it's job. This could happen if someone changed the owner of the file or it's permissions. Gary ___ 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] 0byte graylist entries
Interesting. I've been doing it this way - should I stop? # time to delete old, empty graylist entries older than 15 days (empty files empty directories) find /var/qmail/antispam/graylist/ -type f -mtime +15 -print -delete find /var/qmail/antispam/graylist/ -empty -type d -mtime +15 -print -delete I run these in that order. Seems to do as I ask... On 11/22/2013 10:09 AM, Eric Shubert wrote: On 11/19/2013 04:46 AM, Gary Gendel wrote: Spamdyke does clean up these files periodically (as set by graylist-max-secs) I don't believe this is entirely true. Spamdyke will honor/see these expirations only if/when another email is sent after this time has elapsed, in which case the graylist process starts anew. Over time, un-resent records accumulate, which can take its toll on inodes. This is why I wrote the qtp-prune-graylist script: http://qtp.qmailtoaster.com/trac/browser/bin/qtp-prune-graylist :) Come to think of it, I should package that script with the spamdyke rpm. Oh, I should mention that you can find rpms for spamdyke at http://mirrors.qmailtoaster.com/. They're presently in the /testing directory, and will migrate to /current (stable) once everything's been tested. The spamdyke package should already be solid though. Very soon you'll be able to use yum to install it as well, once the qmailtoaster-release package (containing the yum repo stuff for QMT) is available. Note for posterity: the qtp web site is being migrated/integrated with the QMailToaster organization at GitHub: https://github.com/QMailToaster Look for this script there if the qtp.qmailtoaster.com site is gone. It might be in the spamdyke package there. :) ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
My graylists do get constantly pruned but others seem to have old ones remaining. Then again, my graylist-max-secs is set to 1296000 (one day) which is probably shorter than most. On 11/22/13, 8:15 PM, BC wrote: Interesting. I've been doing it this way - should I stop? # time to delete old, empty graylist entries older than 15 days (empty files empty directories) find /var/qmail/antispam/graylist/ -type f -mtime +15 -print -delete find /var/qmail/antispam/graylist/ -empty -type d -mtime +15 -print -delete I run these in that order. Seems to do as I ask... On 11/22/2013 10:09 AM, Eric Shubert wrote: On 11/19/2013 04:46 AM, Gary Gendel wrote: Spamdyke does clean up these files periodically (as set by graylist-max-secs) I don't believe this is entirely true. Spamdyke will honor/see these expirations only if/when another email is sent after this time has elapsed, in which case the graylist process starts anew. Over time, un-resent records accumulate, which can take its toll on inodes. This is why I wrote the qtp-prune-graylist script: http://qtp.qmailtoaster.com/trac/browser/bin/qtp-prune-graylist :) Come to think of it, I should package that script with the spamdyke rpm. Oh, I should mention that you can find rpms for spamdyke at http://mirrors.qmailtoaster.com/. They're presently in the /testing directory, and will migrate to /current (stable) once everything's been tested. The spamdyke package should already be solid though. Very soon you'll be able to use yum to install it as well, once the qmailtoaster-release package (containing the yum repo stuff for QMT) is available. Note for posterity: the qtp web site is being migrated/integrated with the QMailToaster organization at GitHub:https://github.com/QMailToaster Look for this script there if the qtp.qmailtoaster.com site is gone. It might be in the spamdyke package there. :) ___ 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] 0byte graylist entries
On 11/22/2013 7:09 PM, Gary Gendel wrote: My graylists do get constantly pruned but others seem to have old ones remaining. Then again, my graylist-max-secs is set to 1296000 (one day) which is probably shorter than most. That looks like 15 days to me. ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
Whoops! I read the comment which was obviously wrong. :O On 11/22/13, 9:13 PM, BC wrote: On 11/22/2013 7:09 PM, Gary Gendel wrote: My graylists do get constantly pruned but others seem to have old ones remaining. Then again, my graylist-max-secs is set to 1296000 (one day) which is probably shorter than most. That looks like 15 days to me. ___ 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] 0byte graylist entries
Can someone remind me please: under what circumstances would a spamdyke-created graylist file be 0 bytes? I used to know this but it has totally escaped my memory. This came to light when we saw a sender who appeared to be permanently graylisted when sending to a specific recipient (but not to another recipient, where the sender was graylisted for the appropriate amount of time then let through as expected). On investigation, I found a 0 byte graylist file for the problem sender/recipient pair dating back to October. Deleting it resulted in the email being delivered normally to the recipient shortly after. The sender, incidentally, was a human, sending from a normal smtp server with rDNS and IP visible in the logs. Thanks, Faris. ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] 0byte graylist entries
It's my understanding (which may be faulty) that spamdyke always creates a 0 byte file the first time it gets mail from the domain. When it sees another email from that domain (after the prerequisite graylist-min-secs delay) then it puts the sending server into the file and allows the mail to go through as long as mail comes from that exact server. This is why you sometimes see multiple servers listed in the graylist file. Spamdyke does clean up these files periodically (as set by graylist-max-secs) My guess is that this file was protected, preventing spamdyke from doing it's job. This could happen if someone changed the owner of the file or it's permissions. Gary On 11/19/2013 05:29 AM, Faris Raouf wrote: Can someone remind me please: under what circumstances would a spamdyke-created graylist file be 0 bytes? I used to know this but it has totally escaped my memory. This came to light when we saw a sender who appeared to be permanently graylisted when sending to a specific recipient (but not to another recipient, where the sender was graylisted for the appropriate amount of time then let through as expected). On investigation, I found a 0 byte graylist file for the problem sender/recipient pair dating back to October. Deleting it resulted in the email being delivered normally to the recipient shortly after. The sender, incidentally, was a human, sending from a normal smtp server with rDNS and IP visible in the logs. Thanks, Faris. ___ 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
