...@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
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
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
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
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
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
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
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
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
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
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
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 --
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
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
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
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
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
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
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.
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
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
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
22 matches
Mail list logo
