On Mon, 19 Jun 2006, Logan Shaw wrote: > > Consider the case of a spammer whose software *does* retry, but > > retries every two or three minutes until delivery is accepted or > > PERMFAILed. I have seen this in my greylist logs. Do you really want > > SA + AV + whatever to completely process this message a half-dozen > > times before making a permanent decision at the end of the delay > > period? > > That's a possible problem. One solution is that there is > already a database that tells you when not to delay; this could > be extended to tell you when not to run content-based checking > again. So, you'd only have to run the expensive content-based > checks the first time you get a message from an unknown source.
Okay, I'll buy that. IP + MSGID, store the spam score and don't scan it again. One problem with that is you may lose extra spam points from a URL that goes into the URIBLs between the time the message is first scanned and when the greylist delay expires. Or you could limit it to two scans, one initial and one at delay expiration, and suppress the scans on intermediate delivery attempts. Another alternative is no timeout. If you are just saying "I want to see whether they will retry at all," then accept the message on the second delivery attempt whenever that occurs. Scan both times. The other greylist packages may have good reasons they don't do this, though. -- John Hardin KA7OHZ ICQ#15735746 http://www.impsec.org/~jhardin/ [EMAIL PROTECTED] FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 ----------------------------------------------------------------------- You are in a maze of twisty little protocols, all written by Microsoft. ----------------------------------------------------------------------
