Re: Exploring Greylisting - Initial Block Tim

In the relaydelay.conf file:

# This determines how many seconds we will block inbound mail that is
#   from a previously unknown [ip,from,to] triplet.  If it is set to
#   zero, incoming mail associations will be learned, but no deliveries
#   will be tempfailed.  Use a setting of zero with caution, as it
#   will learn spammers as well as legitimate senders.
#   If it is set to a negative number (like -1), then the mail will
#   be tempfailed the first time it is seen, but accepted thereafter.
$delay_mail_secs = 58 * 60;  # 58 Minutes

So the time is in seconda. I started out with the default in late testing and 
when I first went live. I got a lot of push back from folks about delaying 
mail for an hour or more - so I looked in the logs for the first days and 
asked here.  Most folks said 1,2, or 3 minutes max.

I ended up picking 55 SECONDS based on thinking of it and looking the logs. 
When I had it said for nearly an hour, I had SPAMmers retry for longer than 
that and get through. Looking at some that retried and gave up, I had SPAM 
appearing entries in the logs that retried a lot for the first few seconds and 
then gave up.  So as I said, with a lot of servers retrying at the 30 second 
and/or 1 minute point, just under a minute made sense.

Greylisting even with this low number, along with blacklists and the connect 
delay have wiped out 95% of so of our SPAM. The rest is so easy for the users 
just to ignore or delete that I am not going to even add "MimeDefang" or use 
SpamAssassin as I had planned. Everyone now is pretty happy, but I do have to 
produce a daily report of missed mail so users can tell me ones I can 
whitelist (faulty servers on the other end). I have a php script now (based on 
stuff from Paul Venezia on this list) I run for the local users so they can 
view the blocked messages for their accout "real time" if they want to.

I had to whitelist things like swa (this is the whitelist file that comes with 
the relaydelay.pl) that use unique mail froms and different servers. I have 
some other ones similar to what you specify from Bellsouth - the retries come 
on various IPs but the same from and to.

One thing to note - we have a small group of users here. So often when I 
whitelist I add the IP, exact from and exact to to the file (just like it is 
done automatically, but with no expire). I modified the xlist.pl script to do 
that. I figure no reason to give a free pass to every machine at that IP if I 
don't have to so the manually added, never expires triplet just takes the 
place of the auto added triplet that didn't work due to the other end's faulty 
mail server.

Dennis


>===== Original Message From [email protected] (Greylisting 
Users and Developers Discuss) =====
>Thanks for the feedback Denis.
>
>So you have a seconds resolution? Ok, we add a seconds resolution as well.
>
>Ok, I just thought that the 1 hour block time was too tight. Given the fact
>that we offer a retry frequency options to admins, I can't assume that a
>default of 1 hour is going to be "significant" majority.  In fact, we
>already have in planning to offer a more variable base retry frequency table
>based on error condition.
>
>I noticed bellsouth.net retries immediately within seconds on a pool of
>outgoing servers.  For this bellsouth.net test, I noticed it was trying
>nearly every few seconds from different class c servers. When exhausted, it
>seem to shift to a 5 mins retry from the same group of class c servers.
>Eventually when the triplet matched one of the early attempts, it took 13
>minutes before it was accepted. So obviously this requires a Class C masking
>match logic. :-)
>
>Thanks again for your feedback
>
>--
>Hector Santos, Santronics Software, Inc.
>http://www.santronics.com
>
>
>----- Original Message -----
>From: "Dennis Wynne" <[email protected]>
>To: "Greylisting Users and Developers Discuss"
><[email protected]>
>Sent: Thursday, March 02, 2006 4:13 PM
>Subject: Re: [Greylist-users] Exploring Greylisting - Initial Block Time
>
>
>Glad you asked before you went live.  I am now around 55 seconds for mine
>and most folks that I asked said 1-3 minutes. One of my customers is running
>5 on their server. I started with the nearly one hour default and ran that
>way for a bit - until I asked the list what to run.
>
>What I have found from studying the logs - most SPAMmers never retry so you
>have 100% success blocking those, a few retry a bunch right away (within
>seconds of the first hit) - any setting longer than 30-40 seconds gets
>those, almost NONE that I ever saw that would retry after 1 minute would
>give up before 1 hour.  So setting it longer than a minute or two is going
>to block almost 0 SPAM and just going to delay the good mail for longer.
>
>Most mail servers seem to retry after 1 minute (or at 30 seconds and 1
>minute) so setting it for under 1 minute gets the mail on the 2nd or 3rd
>try.
>
>Dennis
>
>===== Original Message from [email protected] (Greylisting
>Users and Developers Discuss) at 3/02/06 1:54 pm
>>Hi, I'm new to the list.
>>
>>I have been exploring greylisting for our SMTP package.
>>
>>I have a question regarding the recommended 1 hour initial block time.
>>
>>I don't see the direct correlation of the block time with associating good
>>or bad SMTP clients.  The RFC has a recommendation, but that's just it - a
>>recommendation.  There is no fixture on a retry pattern, atleast I don't
>see
>>it.
>>
>>Isn't the primary goal satisfied by simply addressing the nearly 100% bad
>>actors that do not follow 421 response codes?
>>
>>I have been exploring this with no block time limit. I'm close to putting
>>this out to beta testing and I'm wondering what default I should use.  It
>>seems to me that from an operations standpoint, we are a lot "safer" to not
>>have initial 1 hour block limit.  For our test site, I see just a
>>significant amount of good systems retrying within minutes or seconds.
>>
>>I'm aware each site will have its own experiences.  Most of customers are
>>commercial oriented so this is one reason we were reluctant to offer
>>Greylisting in the past.
>>
>>Overall, for our test site, I'm seeing around 64-68% success rate
>>(non-retries/total).  Do you think we might see a higher success rate with
>a
>>1 hour block time at the expense of raising some support issues with "good"
>>people trying to send mail with less than 1 hour retry frequencies?
>>
>>
>>Comments?  Experiences?
>>
>>Thanks
>>
>>--
>>Hector Santos, Santronics Software, Inc.
>>http://www.santronics.com
>>
>>
>>
>>
>>_______________________________________________
>>Greylist-users mailing list
>>[email protected]
>>http://lists.puremagic.com/cgi-bin/mailman/listinfo/greylist-users
>
>
>_______________________________________________
>Greylist-users mailing list
>[email protected]
>http://lists.puremagic.com/cgi-bin/mailman/listinfo/greylist-users
>
>
>_______________________________________________
>Greylist-users mailing list
>[email protected]
>http://lists.puremagic.com/cgi-bin/mailman/listinfo/greylist-users