In the past, on this list, it's been suggested that having too many RBL entries was causing too long a delay in accepting mail.
I note that an increasingly popular anti-spam tactic these days is to add an SMTP Delay. Some server admins report a 40% drop in spam with a 30-second delay. So... Is this delay right at the very start, before accepting an initial SMTP connection? Or is it just a delay after the connection is established but before the mail is accepted -- like the delay introduced by the use of too many RBLs? Either way, I'm wondering if I might be better off adding more RBLs to my SIMS server. Will less patient spammers quickly give up and go away? Does SIMS in fact wait for responses from each RBL that is queried? If so, I'm thinking that it might be possible to write a short delay daemon that I can run on my OS X box, whose only purpose is to respond to a RBL lookup with a not-blacklisted response -- after a delay of 30 seconds. I then add the address of this daemon to my RBL list and thereby implement a 30-second delay which SIMS is otherwise not capable of. (Or would caching of responses cause this to fail?) Is there a way to add a SMTP delay to SIMS or to achieve the same effect? Will adding more RBL entries help to reduce spam (quite apart from additional RBL hits) by introducing a delay? Finally, will adding a delay just cause spammers to move more quickly to secondary MXs for my domains? ############################################################# This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
