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
