> This is a good argument for the delayed-scan-and-deliver > feature I suggested previously. The porn guys you are > probably talking about we call the "mad-lib pornsters". Every > day or so they will come out with a brand new set of domains > delivering a wide array of porn traffic. > Actually, our robots usually manage to pick up quite a bit of > it, but they have huge bandwidth behind them so they get > quite a bit of content out before the updated rules can go in place.
Pete, That's a great idea but I'm guessing we could do this with an External program, SQL DB/txt file, and Declude. Scott, Check my logic on this... For the first rule we would run the external filter DELAYSCANANDDELIVER. The external .exe checks the sender IP against the database and either issues exit code 0 (process) 1 (STOPALLTESTS) If the external .exe doesn't find an IP w/ proper timeset offset in the database then it would move the Imail Q.SMD files to a hold folder, add the IP with timestamp to the database. The question for Scott is how would Declude/Imail react when the Q.SMD file disappears during the processing? Is this what you had in mind Pete? --- [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.
