> ...since a delay is mostly harmless...
Pete, you're an awesome programmer, and I stand in awe of Sniffer's sophistication and penetration.
Thanks.
However, I think your idea is strikingly out-of-touch with the way SMTP is used in 2003. We can howl to the heavens about its obsolescence, insecurity, unreliability, latency...but in the real world, SMTP is mission-critical and delivery is to be made as timely as possible. I know of not one client of ours--nor anyone in our own company--who would tolerate such a paradigm shift as half-day-plus delays, no matter how powerful the corollary anti-spam effects. 5- or 10-minute "processing delays" might be palatable, but would be unlikely to allow time for the global trending you suggest.
Well, I agree, and disagree...
Email (SMTP) is absolutely the most critical resource in most Internet installations... Keep in mind that known message sources would not be delayed - only new, unknown sources. This amounts in principle to an automatic management of QOS - giving some preference to traffic that is already established.
I'm really only suggesting that a feature like this might be made available - not necessarily enforced (though that may cure many ills - see below). This feature would allow each admin to adjust their system's response as appropriate for their balance of tolerance to spam/malware and tolerance to delay.
An installation with a low tolerance for delay might set that delay to 2 hours or even less. This is often within the range of delays that might normally be experienced due to queue run cycles and so forth... Some systems might establish different "quarantine periods" for different groups of users... for example setting a high quarantine period for the rank-and file of email addresses - those that would almost exclusively be receiving mail from already known senders... while setting no quarantine period for publicized support and/or sales mailboxes.
In this context one might almost make the argument that a message from an unknown sender to an unpublished email address has a very high likelihood of being spam on that basis alone... In a case like this a profylactic delay might be a much more desirable option than many others - such as a quarantine area that requires review.
What might be interesting is the ability to deliver messages to a web-readable MBX file, then relocate messages to originally intended subareas as they are "stamped" or "stomped." Of course, you have mucho associated disk I/O processing, locking issues, etc.
If you take this concept a bit further you'll see what I'm talking about. If the messages were delivered to a web-readable file of any kind then someone would presumably need to move them to the appropriate location at some point... in any case what you describe represents essentially the same kind of process in that some amount of delay is introduced into the delivery path for some messages.
As a tunable capability this mechanism _might_ be a strong tool to have available for some systems. As with any powerful tool it would have to be used carefully.
_M
PS: A quick analysis of data on Sobig.f suggests strongly that if mechanisms like this were widely deployed the impact would be reduced by a minimum of two orders of magnitude. The model suggests that the majority of spread would be from previously unseen IPs to most systems and that by the time the quarantine period was up for the initial onslaught most virus protection companies would have responded with updated filters - so the majority of infection propagation would be suppressed. It turns out that this model is extremely powerful for most email based worms/viruses. Of course the counter response to wide deployment of this mechanism is for viruses to begin utilizing normal delivery channels rather than smtp facilities created in infected machines - but that's another discussion.
--- [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.
