I personaly agree completely with Pete's arguments. I've asked over a year
ago the first time for custom hold folders. The benefit of "keep and check
again later" is only one offered by custom hold folders. Fortunately v2 now
has custom hold folders.

I've also mentioned months ago what Matt said: requeuing and call Declude
with a VB-Script.

I personaly would have this functionality not to Delay a lot of legit mails
in order to catch also a few spam messages that slip trough. 
The idea is to bring out of the review range as much messages as possible.
Independently if reviewing is done by one operator or on client side. The
goal is to have as less messages as possible in this range. Both Operators
and clients are human and after days of seeing only spam in the review
folder, this humans will stop watching attentive for legit messages.

In order to avoid FP's I believe we all have configured our review range
pretty conservative and usualy find 0,00x % of false positives durring
review. So the delayed messages are at 99,99x% spam, and so it's absolutely
no problem if they are delayed several hours (cached DNS, Filter-Updates,
...)

If this idea it's worth would only show up a practical test with a report
what percentage of the review range would recieve a higher weight after some
hours...

Markus





> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Darin Cox
> Sent: Friday, February 11, 2005 8:19 PM
> To: Declude.JunkMail@declude.com
> Subject: Re: Re[4]: [Declude.JunkMail] domain name a name
> 
> Hmmm...some of our customers are constantly in contact with 
> new personnel, even new businesses, that they work with in a 
> consulting role.  This absolutely would not work for them, as 
> the delays would be unacceptable.  In their case, they'd 
> rather see a few of the Rx spam messages get through than 
> have a delay on new ham.  Wouldn't work for me either for 
> similar reasons.
> 
> Though it's certainly an idea if it can be turned off on a 
> per-domain, possibly even per-user basis.  A few of our 
> customers might go for it, but most would rather deal with 
> the 0.5% that slip through.
> 
> Darin.
> 
> 
> ----- Original Message -----
> From: "Pete McNeil" <[EMAIL PROTECTED]>
> To: "Darin Cox" <Declude.JunkMail@declude.com>
> Sent: Friday, February 11, 2005 9:49 AM
> Subject: Re[4]: [Declude.JunkMail] domain name a name
> 
> 
> On Friday, February 11, 2005, 9:28:28 AM, Darin wrote:
> 
> DC> Hi Pete,
> 
> DC> Right... but the first few typically slip through before 
> they're added
> to
> DC> your filters (like they would for anyone)...so we add 
> them on the first
> DC> report to us as well.
> 
> I'll raise the feature request again --- as soon as I get my
> flameproof suit on:
> 
> Declude should have a test/feature to delay a message by x hours if
> the sender is not recognized. This gives all filtering mechanisms time
> to adapt to new spam sources. Once the delay time has expired the
> message is passed through as if it were new so that the presumably
> updated BLs, filters, etc will have the ability to filter the message
> (if needed).
> 
> To revive and put to rest past arguments about this:
> 
> Big reason not to do this: It is unforgivable and in all other ways a
> bad idea to delay any message by any amount of time and huge amounts
> of money or even lives may be lost if this happens.
> 
> To which I contend...
> 
> If this is the first time you have ever received a message from a
> particular source then there is no expectation yet for the time to
> delivery and email systems in general may impose end-to-end delays of
> between minutes to hours depending upon many unknown factors at any
> time (queues, down servers, down connectivity, graylisting (force
> retry at first connect)).
> 
> Since only _new_ connections would be effected, this feature would go
> almost un-noticed in the vast majority of cases. All other email
> sources, where there is an expectation, would be passed at full speed
> with normal filtering.
> 
> Also, IF you happen to be in a position where you really can't afford
> to impose any delays on new messages then: A) You probably aren't
> filtering anyway since that would be dangerous [ a conflict in policy
> ] and B) You _can_ turn it off ;-)
> 
> Those are my thoughts on that ( once again ).
> 
> _M
> 
> /M retreats to underground bunker & activates shields at full power.
> 
> 
> 
> ---
> [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.
> 
> ---
> [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.
> 

---
[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.

Reply via email to