I agree, the mechanics are simple. The difficulties lie in gathering the information in the database and gauging how long to wait before re-testing, and how to get fresh results.
For example, DNS cacheing will mean that you get the same results from your IP4R tests if you do them only a short time later. Much the same applies to Message Sniffer, whose updates currently average about 6 hours apart. I've no idea how fast SURBL is actually updated with a given URI, but I believe they make hourly updates (for the SpamCop derived one, at least). Andrew 8) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Friday, February 11, 2005 10:55 AM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] domain name a name I don't think that I am really interested in this personally, but you could probably fairly easily write a script that acted as an external test in Declude that would check the special HOLD directory for files older than X number of minutes, move the D* files back into the spool and call Declude with the location of the Q* file. You would probably want to limit the number of reprocessed E-mails for each attempt to a small number so that you don't overwhelm your server. You could also just simply dump them into an overflow directory and have Declude take care of the reprocessing priority itself. I'm guessing that this could be done in less than 100 lines of VBScript and it would be rather straightforward to code. Matt Colbeck, Andrew wrote: >Pete I agree with you. Graylisting or greylisting would be a great add >on to Declude. > >I've hoped for this in an MTA, but it doesn't look like CPHZ will go >that way, and since Ipswitch only adopts antispam measures that Declude >already has <heh>, it won't be coming from them. SmarterMail may well >be more receptive to suggestions. > >The current Declude architecture could do it however, as evidenced by >the nifty logic which implements the Overflow folder. Instead of the >MTA rejecting the message with a 5xx error, Declude would tuck away the >new message Q*.SMD and D*.SMD in a folder, and re-scan the messages in >that folder that have aged sufficiently and take the usual actions. > >This could also be a relatively easy 3rd party add-on, and is made a >little easier now that Declude 2.0 supports a HOLD with a specified >folder name. > >For those who want to learn more about greylisting, I suggest this: > >http://projects.puremagic.com/greylisting/ > >Andrew 8) > >-----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. > > > > -- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ ===================================================== --- [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.
