QUOTE(Wazoo @ Jun 24 2005, 08:41 AM)
I think where we're at .. you submit a spam .. parser kicks in ... various "threads" are started ...
header stucture analyzed
body looked for
chain test starts on the header
'logical' source address found - internal/external database lookups started
body analyzed for URLs
body URLs found - internal/external database lookups started
now, remember, the parsing 'process' is still sitting there, waiting for a response from all of the sub-processes fired up .... (and this leads us into that area of the internal/external database lookups timing out)
eventually/hopefully all the lookup sub-processes come back with results ... so we're sitting there with a minimum of five storage locations tied up with that spam .. the spam itself, the Tracking URL, the spew source, the spamvertised site, and the "computer notepad" that's keeping all of this stuff tied together ... all that data gets fed into the "handling" side of the "reporting" section ...
Now we've got to tickle the SpamCopDNSBL counter for the source IP, generate the e-mails for "all" of the target e-mail addresses found by the parser ... this generates the stuff found when you hit the "Preview" button ...
At the point you hit the "Send" button, then decision are made where to "send" the e-mail ... stuff going out gets sent to the SMTP engine, stuff that goes to "special" addresses gets handled internally based on those internal factors (some ISPs want groups, some want a special format, and as above, some go to special internal accounts for other purposes) .. and those items already identified as going to ISPs that specifically requested/selected not to be informed make their trip to the /dev/null bit-bucket. Again, the intent is to let the computer do its thing, empty the "notepad" of collected data and clear all the flags set to "done" ...
All the space, resources, attention that was focused on your last spam submittal are now free to handle the next incoming spam submittal.
header stucture analyzed
body looked for
chain test starts on the header
'logical' source address found - internal/external database lookups started
body analyzed for URLs
body URLs found - internal/external database lookups started
now, remember, the parsing 'process' is still sitting there, waiting for a response from all of the sub-processes fired up .... (and this leads us into that area of the internal/external database lookups timing out)
eventually/hopefully all the lookup sub-processes come back with results ... so we're sitting there with a minimum of five storage locations tied up with that spam .. the spam itself, the Tracking URL, the spew source, the spamvertised site, and the "computer notepad" that's keeping all of this stuff tied together ... all that data gets fed into the "handling" side of the "reporting" section ...
Now we've got to tickle the SpamCopDNSBL counter for the source IP, generate the e-mails for "all" of the target e-mail addresses found by the parser ... this generates the stuff found when you hit the "Preview" button ...
At the point you hit the "Send" button, then decision are made where to "send" the e-mail ... stuff going out gets sent to the SMTP engine, stuff that goes to "special" addresses gets handled internally based on those internal factors (some ISPs want groups, some want a special format, and as above, some go to special internal accounts for other purposes) .. and those items already identified as going to ISPs that specifically requested/selected not to be informed make their trip to the /dev/null bit-bucket. Again, the intent is to let the computer do its thing, empty the "notepad" of collected data and clear all the flags set to "done" ...
All the space, resources, attention that was focused on your last spam submittal are now free to handle the next incoming spam submittal.