I meant to also add that I recently had many hours of planned downtime on my MTA in my absolute lowest ham window - late Saturday evening through early Sunday morning. I saw very little spam increase once the MTA was back up.
This tells me that the spammers have not yet implemented full MTAs that retry their queued spam. An MTA that tells them to try again later (greylisting) would work well for me. If greylisting that was configurable by hours was available to me, I might turn it off during business hours for maximum "safety". I would also want a feature to gather addresses/domains/IPs from my outbound mail to create an autowhitelist*. Andrew 8) * http://eservicesforyou.com/ John Tolmachoff, do you still sell AutoWhite? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Friday, February 11, 2005 6:49 AM To: Darin Cox Subject: Re[4]: [Declude.JunkMail] domain name a name On Friday, February 11, 2005, 9:28:28 AM, Darin wrote: DC> Hi Pete, DC> Right... but the first few typically slip through before they're DC> added to your filters (like they would for anyone)...so we add them DC> on the first report to us as well. I'll raise the feature request again --- as soon as I get my flameproof suit on: Declude should have a test/feature to delay a message by x hours if the sender is not recognized. This gives all filtering mechanisms time to adapt to new spam sources. Once the delay time has expired the message is passed through as if it were new so that the presumably updated BLs, filters, etc will have the ability to filter the message (if needed). To revive and put to rest past arguments about this: Big reason not to do this: It is unforgivable and in all other ways a bad idea to delay any message by any amount of time and huge amounts of money or even lives may be lost if this happens. To which I contend... If this is the first time you have ever received a message from a particular source then there is no expectation yet for the time to delivery and email systems in general may impose end-to-end delays of between minutes to hours depending upon many unknown factors at any time (queues, down servers, down connectivity, graylisting (force retry at first connect)). Since only _new_ connections would be effected, this feature would go almost un-noticed in the vast majority of cases. All other email sources, where there is an expectation, would be passed at full speed with normal filtering. Also, IF you happen to be in a position where you really can't afford to impose any delays on new messages then: A) You probably aren't filtering anyway since that would be dangerous [ a conflict in policy ] and B) You _can_ turn it off ;-) Those are my thoughts on that ( once again ). _M /M retreats to underground bunker & activates shields at full power. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
