> 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 understand the idea, but I still disagree strongly about its viability.
Ok. I freely admit there are many situations where the concept would not work. It is clear this would not work for you and presumably the users you service. I completely understand.
I am personally involved with systems ranging from family and church groups that wish only to receive email from people who have their PL (Private List) code, to companies that refuse any kind of virus or email filtering out of fear/frustration that they might miss an important message. However, most folks (in my experience) seem to be somewhere in between, and for many of them this new mechanism would be a good choice.
> 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...
Not on systems we manage. If 2 hours were the average delivery delay, e-mail would not have achieved mission-critical status. Like I said before, 5-10 minutes can be written off. 2 hours is *always* remarked upon by users. With sufficient technical explanation, smoothing over, or obfuscation, users can tolerate such *occasional* shocks and still keep their faith in SMTP. The more often it happens, and especially if such delays are a *feature*, the less people will use SMTP (or your services).
Without reopening the debate on wether this would work for your system(s), I suggest that you might not have a clear picture of how this would function in practice. Indeed the average delivery would be nearly identical to what you currently experience for the vast majority of email customers. In practice the delay would only be present in the case of a new contact on the very first message. All other experiences after that would have no delay. For most (at least in my experience) a delay in this very first message would generally not be perceived at all because there is generally no expectation of turnaround time when making an initial contact or introduction. (certainly, again, there are exceptions).
Additionally, in many business cases the clearing of the first message from the first contact within an organization would clear the delay for all subsequent contacts within that organization due to the key being on the source IP of the messages (generally the MTA of the new contact organization). Certainly there are exceptions and opportunities for additional delay instances in some cases (multiple MTAs - mobile users - etc) however these would be so "far and few between" that they would likely never be perceived by anyone not specifically testing for the case.
One final note in this segment - regarding 2 hours. The queue cycle time on your systems (and indeed on our systems) may be quite fast so that 2 hours would be detected as a problem to be fixed :-)... however there are many systems that regularly experience much longer delays when delivering messages across the net, and there are many factors that are involved... Granted this is not most systems... but again I will restate that the delay in this case would be imposed only on the very first message from an entirely new source... that is one message out of thousands in most scenarios.
Anyway - my choice of 2 hours was completely off the top of my head and meant only to be illustrative, not precise.
> 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...
"Almost exclusively" is not "exclusively," and the difference is HUGE and deal-killing, in my take. It's not just "publicized" addresses that receive mail from new, vitally important senders. That's not true in the real world.
I will grant, wholeheartedly that there are many cases where an implementation like this would be unworkable. I also recognize many cases where it would be not only workable but even desirable. We may disagree on the where the majority lies - but that is not ultimately important. What Scott has done so well is to create a system that is flexible enough to fit the needs of many different installations. I merely recommend this feature as one that might prove useful for some.
> 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...
??? What do you mean by "unpublished," actually?
Some organizations have a range of email addresses that are widely published for outside contact with the remainder of their email addresses closely guarded. They only provide these addresses to individuals with whom they have business and rarely, if ever, expect messages from anyone outside those circles. Many such addresses are not expected to ever receive email from outside the organization except perhaps from family members or other well established contacts -
Clients, peers, vendors, and so-forth are expected email sources for these addresses and tend to be well established, however other contacts would almost exclusively be entirely new and likely handled by referral or by personal contact. 1. A customer recommends their rep to a friend... that friend's first message might be delayed, but since it is introductory the delay would not be noticed. 2. An employee gives a card to a new contact, or otherwise gives out their email address... the first email coming from that contact would be delayed - in many cases this initial delay would not be a problem. Remember that all subsequent messages would be as close to "real-time" as the equipment would allow.
The majority of new contacts for this kind of organization would be sourced through their widely published email addresses (which would generally not impose any delays). Messages coming into these addresses would usually be screened by some handlers and then referred to the correct person(s) and/or department(s) internally. Indeed this scenario is often enforced as a strategy for handling incoming traffic.
> 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...
No, that wasn't what I meant. I meant a "purgatory" MBX readable *by the recipient* that is also managed by a background janitorial process that either "stamps" a message as legit and moves it to the originally intended subarea (not always Main), or "stomps" a message as spam and
That is certainly another way this could be implemented.
deletes it. What this would allow is that closely attended mailboxes will always be able to receive all mail nearly as quickly as currently possible (with the extra step of scanning the purgatory mailbox if
I might recommend that if a mailbox is going to be so closely monitored it may not be a good candidate for the delay in the first place... but your "visible purgatory" option sounds like a good middle ground for these cases.
> 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.
I see it as having the most utility between, say, the hours of midnight and 6 a.m....hours when lots of legit mail (bulletins and the like) comes in, accompanied by lots of spam--yet none of the legit mail needs to be read until the start of the working day.
Perhaps that's another feature that should be considered by Declude - the ability to change elements of the configuration according to a schedule... I can see the easiest way to do this would be to simply swap in the correct configuration file(s) using scheduled tasks, ... but there may be room for a built-in mechanism if enough of Scott's customers have such a need.
As for the new-source-quarantine feature, it should probably be implemented in a few different parts... One part is a simple test to indicate wether the source IP is on the known list. Another part is an action that can put the message either into a queue with a suitable delay attached. Perhaps another action to add or drop a "known source". With these elements in place it seems that a wide range of possible implementations might be achieved.
Anyway, it's just a thought.
_M
--- [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.
