Wow any of those scripts available for sale? 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew
Sent: Wednesday, February 23, 2005 9:27 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] SmarterMail Held email recovery

Aha!  That's pretty nifty, Kevin.

Well, *if* SmarterMail doesn't have the ability to re-queue without
scanning, I'd suggest that you could add a bit more development to your
web application to accomodate automatic counterweighting of re-queued
messages.

You're a programmer, so I don't have to detail a technique for inserting
a magic cookie into the header, and have Declude check for the cookie
and counterweight/whitelist appropriately.  But heck, I figured it was
worth mentioning here.

Andrew 8)

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kevin Bilbee
Sent: Wednesday, February 23, 2005 5:55 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] SmarterMail Held email recovery


I do not monitor my hold directory manually. I have a program the sends
and email to all the users that have held email from the previous day
with a recovery link for each message. The user has the option to
recover the mesage or not. If they recover the message it is requeued
and then delivered. A copy of the message source is also sent to our
abuse@ email address to be analyzed and adjusted or to notify the admin
of the sending server of the problem.

Most of the messages that get held with our configuration fail due to
SFP, HELOBOGUS, and RDNS otherwise I have very few false positives from
filters to adjust for. I do not adjust for IP4 black list failures a
server would have to be in 2 or 3 black lists to be held.



Kevin Bilbee






> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Colbeck, 
> Andrew
> Sent: Wednesday, February 23, 2005 5:39 PM
> To: Declude.JunkMail@declude.com
> Subject: RE: [Declude.JunkMail] SmarterMail Held email recovery
>
>
> Well, I guess our goals differ.
>
> So although with IMail+Declude you can re-queue without scanning (your
> way) as well as re-queue with scanning (my way), I choose to re-queue 
> with scanning AND fix the reason why the message was held.
>
> Re-queuing with scanning forces me to fix it, and I also try to fix it

> so that it is also fixed for future messages.
>
> So, while we wait for an official answer to your question (Hello,
> Declude?) can you tell us why you want to re-queue without scanning?
>
> Andrew 8)
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Bilbee
> Sent: Wednesday, February 23, 2005 5:04 PM
> To: Declude.JunkMail@declude.com
> Subject: RE: [Declude.JunkMail] SmarterMail Held email recovery
>
>
> SmarterMail executes declude allover again.
>
> >
> > I never simply re-queue for delivery a message that was held.  I 
> > always re-queue such that Declude would scan it again.
>
> When you requeue a message with Imail the only thing you need to do it

> move the D and Q files to the spool folder, they will not be rescanned

> by declude.
>
> >
> > Which implies that I must also do something about my Declude 
> > configuration to counterweight this and future messages from the 
> > same sender, e.g. with a REVDNS or a REMOTEIP negative weight.
>
> By countreweighting a messages that failed would only cause it to not 
> fail the first time. I want to take a message that failed and was held

> and requeue it for delivery. When requeueing the message it should not

> be scanned again by declude.
>
>
> > p.s. With IMail, I re-queue a message for scanning and delivery by 
> > moving the D*.SMD to the spool folder, and then moving the Q*.SMD 
> > file
>
> > to the spool\overflow folder. I also edit the D*.SMD file before I 
> > move it, to remove any previous header additions, so that on the 
> > next Declude scan, it gets only the "corrected" headers.
>
> This is not necessary. See above!
>
>
>
> Kevin Bilbee
>
>
>
> ---
> [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.
---
[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 scanned for viruses by Declude Virus]



---
[This E-mail scanned for viruses by Declude Virus]

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