RE: [Declude.JunkMail] Experience with 4.x

[Jay Sudowski - Handy Networks LLC]

Sounds like you have a very intensive setup.  We run minimal filter
tests, one virus scanner and Sniffer.  When we have experienced spool
backups, I've tinkered with the number of threads and found 80 seems to
result in the best message throughput for our particular configuration.
Any lower and we were not using the available resources, and any higher
the stress on the system resulted in message processing slow downs.  If
we're facing a particularly bad queue backup, I will disable Sniffer and
can further increase the number of threads without any impact on the
overall time to process a single message.  For our customers, a small
amount of spam leakage is far better than delayed email.

We process about 200,000 - 250,000 messages per day, and the majority of
those are during normal business hours.  As you can imagine, any small
disruption to normal queue processing can result in a fairly large queue
backup - a 30 minute issue during normal business hour can result in
10,000 queued messages.

-Jay

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matt
Sent: Wednesday, May 24, 2006 9:34 AM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] Experience with 4.x

Jay,

It's not about moving along, it's about limiting the CPU to only 100%, 
or at least not piling it on when it gets there.  I could be wrong in 
assuming that 1 thread = 1 message (hopefully I will be corrected if 
so), but 30 average messages being processed at once will most 
definitely peg my processors, and adding more threads when you are at 
100% will actually slow down performance.

Another note, not all systems are configured equally.  A vanilla install

of Declude would likely handle 4 times the number of messages that mine 
does since I run 4 external filters, two virus scanners, and something 
like 100 Declude filters (though they mostly get skipped with 
SKIPIFWEIGHT and END statements as they are targeted).  Running a single

virus scanner and RBL's is just a fraction of the load.  With my 
pre-scanning gateways blocking more than 90% of all traffic (about half 
of that is dictionary attacks and most of the rest is done with 
'selective greylisting'), I can scale one server to handle over 20,000 
addresses, possibly as many as 40,000 (doesn't host the accounts 
though), so despite the heavy config, it is optimized.

But back to the real topic...I'm just guessing that 30 messages/threads 
is the limit for my box, but I'm sure that it isn't as high as 80, 
though setting it at 80 would be of no consequence outside of a 
prolonged heavy load caused by something like a backup of my spool.  It 
would be a bigger mistake to set it too low.

Matt



Jay Sudowski - Handy Networks LLC wrote:

>30 threads seems awfully low.  We set ours to 80 on a dual xeon box
with a separate drive for spool/logging and we move right along without
any issues.
>
>Thanks!
>-
>Jay Sudowski // Handy Networks LLC
>Director of Technical Operations
>Providing Shared, Reseller, Semi Managed and Fully Managed Windows 2003
Hosting Solutions
>Tel: 877-70 HANDY x882 |  Fax: 888-300-2FAX
>www.handynetworks.com
>
>From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matt
>Sent: Tuesday, May 23, 2006 3:25 PM
>To: Declude.JunkMail@declude.com
>Subject: Re: [Declude.JunkMail] Experience with 4.x
>
>Andrew,
>
>Thanks for your notes and their history.
>
>I'm using the following settings right now:
>THREADS30
>WAITFORMAIL500
>WAITFORTHREADS200
>WAITBETWEENTHREADS100
>WINSOCKCLEANUPOFF
>INVITEFIXON
>AUTOREVIEWON
>There are a few reasons for trying these values.
>THREADS 30 - I'm pretty confident that dual 3.2 Ghz Xeons and RAID can
only handle 30 threads with average messages.  In reality, one single
message can spike the system to 100%, but these are uncommon.  I figure
that if I open this up too wide and I am dealing with a backup or
something, launching more threads when at 100% CPU utilization will
actually slow the system down.  This was the same with 2.x and before.
There is added overhead to managing threads and you don't want that to
happen on top of 100% CPU utilization.  I am going to back up my server
later tonight to see if I can't find what the magic number is since I
don't want to be below that magic number, and it would probably be best
to be a little above it.
>
>WAITFORMAIL 500 - On my server, this never kicks in, but if it did, it
wouldn't make sense to delay for too long because I could build up
messages.  A half second seems good.
>
>WAITFORTHREADS 200 - This apparently kicks in only when I reach my
thread limit; sort of like a throttle.  I don't want it to be too long
because this should only happen when I am hammered, but it is wise not
to keep hammering when you are at 100%.  Sort of a mixed bag choice
here.
>
>WAITBETWEENTHREADS 100 - I see this setting as being the biggest issue
with sizing a server.  Setti

Re: [Declude.JunkMail] Experience with 4.x

[Matt]

Erik,

I have the primary Alligate Gateway installed on the same box as
IMail/Declude, but on different ports.  My IMail doesn't actually host
any real users, it's just a container for Declude and storage for the
lowest scoring spam.  The idea is to dump as much illegitimate stuff as
possible during the SMTP envelope through the use of the 'pre-scanning'
gateway, and then do the heavy lifting with Declude.  The one-box
solution saves money, and the gateway also saves money since it reduces
the burden of heavy lifting by reducing the volume.

Matt



Erik wrote:

  Matt, is your Delcude gatewayed?  Or is it running on the same server as
Imail?

-Erik


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Matt
Sent: Wednesday, May 24, 2006 5:58 PM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] Experience with 4.x


I indicated earlier that it looked like a relative 10% improvement 
(about the difference between 35% and 32% hourly average CPU 
utilization).  I would think that this comes primarily from not needing 
to start the old declude executable every time, and the improvement 
might be more substantial on a system with a overtaxed disk.  I don't 
think the code is any more efficient as far as actual scanning goes.  
Besides that, it's typically the virus scanners and external tests that 
eat up most of the CPU on a Declude system and not Declude itself, and 
those things haven't changed.

I'm guessing that it might perform much better when redlined though if 
you tweak it right.  I believed that old Declude when getting rammed 
with overflow seemed to not perform linearly with normal performance 
with free CPU, but instead dropped, probably due to having a lot of CPU 
wait time overhead (there's probably a more accurate term for this).  
The new Declude can be more effectively controlled so as to not bog down 
the system as much.  So performance here might be 2x or more when 
redlined under optimal conditions.  This effect would be maximized if 
Declude would tie launching threads to a CPU monitor instead of a fixed 
number with no real clue as to what is perfect under any particular 
situation.

Matt




Nick Hayer wrote:

  
  
Hi Matt,

So you see any substantive performance improvement over 2x?

-Nick

Matt wrote:



  Jay,

It's not about moving along, it's about limiting the CPU to only
100%, or at least not piling it on when it gets there.  I could be 
wrong in assuming that 1 thread = 1 message (hopefully I will be 
corrected if so), but 30 average messages being processed at once 
will most definitely peg my processors, and adding more threads when 
you are at 100% will actually slow down performance.

Another note, not all systems are configured equally.  A vanilla
install of Declude would likely handle 4 times the number of messages 
that mine does since I run 4 external filters, two virus scanners, 
and something like 100 Declude filters (though they mostly get 
skipped with SKIPIFWEIGHT and END statements as they are targeted).  
Running a single virus scanner and RBL's is just a fraction of the 
load.  With my pre-scanning gateways blocking more than 90% of all 
traffic (about half of that is dictionary attacks and most of the 
rest is done with 'selective greylisting'), I can scale one server to 
handle over 20,000 addresses, possibly as many as 40,000 (doesn't 
host the accounts though), so despite the heavy config, it is optimized.

But back to the real topic...I'm just guessing that 30
messages/threads is the limit for my box, but I'm sure that it isn't 
as high as 80, though setting it at 80 would be of no consequence 
outside of a prolonged heavy load caused by something like a backup 
of my spool.  It would be a bigger mistake to set it too low.

Matt



Jay Sudowski - Handy Networks LLC wrote:

  
  
30 threads seems awfully low.  We set ours to 80 on a dual xeon box
with a separate drive for spool/logging and we move right along 
without any issues.

Thanks!
-
Jay Sudowski // Handy Networks LLC
Director of Technical Operations
Providing Shared, Reseller, Semi Managed and Fully Managed Windows
2003 Hosting Solutions
Tel: 877-70 HANDY x882 |  Fax: 888-300-2FAX
www.handynetworks.com

From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]] On Behalf Of Matt
Sent: Tuesday, May 23, 2006 3:25 PM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] Experience with 4.x

Andrew,

Thanks for your notes and their history.

I'm using the following settings right now:
THREADS30
WAITFORMAIL500
WAITFORTHREADS200
WAITBETWEENTHREADS100
WINSOCKCLEANUPOFF
INVITEFIXON
AUTOREVIEWON
There are a few reasons for trying these values.
THREADS 30 - I'm pretty confident that dual 3.2 Ghz Xeons and RAID
can only handle 30 threads with average messages.  In reality, one 
single message can spike the system to 100%, but these a

RE: [Declude.JunkMail] How to get support from sniffer....

[Chuck Schick]

Pete:

Thanks.

Was worried my messages were not getting through.

Chuck Schick
Warp 8, Inc.
(303)-421-5140
www.warp8.com

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil
Sent: Wednesday, May 24, 2006 1:22 PM
To: Chuck Schick
Subject: Re: [Declude.JunkMail] How to get support from sniffer


Chuck, I stepped away for a while (started work today at midnight).

I've found your FPs and I will address them immediately.

I note you did not leave a message on the support line (that I can see).

I'll take the rest of this off list.

Thanks,

_M


On Wednesday, May 24, 2006, 2:12:39 PM, Chuck wrote:

CS> It appears in the sniffer rulebase updated yesterday one of the 
CS> rules trips the getrich test on sniffer when emails are sent from or 
CS> to our domain name. I have identified the rule and made a panic rule 
CS> entry.  But it appears the problem is more wide spread.  I have sent 
CS> messages to [EMAIL PROTECTED], [EMAIL PROTECTED], and 
CS> have submitted several examples to [EMAIL PROTECTED] with 
CS> absolutely no response.  I am concerned that my emails are not 
CS> getting through because of the bad rule - when I sent a message to 
CS> the sniffer list it never shows up making me suspect the bad rule is 
CS> torpedoing my email correspondence.

CS> This is a big catch-22.  I wish that sortmonster had a web based 
CS> ticketing system.  Anybody have a non email way of getting ahold of 
CS> sortmonster.  The tech support phone number on the armresearch web 
CS> site just goes to voice mail.

CS> Sorry to post this here but I want to get this resolved.

CS> Chuck Schick
CS> Warp 8, Inc.
CS> (303)-421-5140
CS> www.warp8.com

CS> ---
CS> This E-mail came from the Declude.JunkMail mailing list.  To 
CS> unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type 
CS> "unsubscribe Declude.JunkMail".  The archives can be found at 
CS> http://www.mail-archive.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 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.

Re: [Declude.JunkMail] How to get support from sniffer....

[Pete McNeil]

Chuck, I stepped away for a while (started work today at midnight).

I've found your FPs and I will address them immediately.

I note you did not leave a message on the support line (that I can
see).

I'll take the rest of this off list.

Thanks,

_M


On Wednesday, May 24, 2006, 2:12:39 PM, Chuck wrote:

CS> It appears in the sniffer rulebase updated yesterday one of the rules trips
CS> the getrich test on sniffer when emails are sent from or to our domain name.
CS> I have identified the rule and made a panic rule entry.  But it appears the
CS> problem is more wide spread.  I have sent messages to
CS> [EMAIL PROTECTED], [EMAIL PROTECTED], and have submitted several
CS> examples to [EMAIL PROTECTED] with absolutely no response.  I am
CS> concerned that my emails are not getting through because of the bad rule -
CS> when I sent a message to the sniffer list it never shows up making me
CS> suspect the bad rule is torpedoing my email correspondence.

CS> This is a big catch-22.  I wish that sortmonster had a web based ticketing
CS> system.  Anybody have a non email way of getting ahold of sortmonster.  The
CS> tech support phone number on the armresearch web site just goes to voice
CS> mail.

CS> Sorry to post this here but I want to get this resolved.

CS> Chuck Schick
CS> Warp 8, Inc.
CS> (303)-421-5140
CS> www.warp8.com

CS> ---
CS> This E-mail came from the Declude.JunkMail mailing list.  To
CS> unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
CS> type "unsubscribe Declude.JunkMail".  The archives can be found
CS> at http://www.mail-archive.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.

RE: [Declude.JunkMail] How to get support from sniffer....

[Chuck Schick]

Andrew:

Thanks a bunch.

Pete has always been responsive, I just think I have been caught in the
proverbial death spiral on this issue.

Chuck Schick
Warp 8, Inc.
(303)-421-5140
www.warp8.com

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew
Sent: Wednesday, May 24, 2006 12:54 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] How to get support from sniffer


Chuck, since I'm not blocked, I've sent a message on your behalf to Pete as
well as false@ ... while redacting your domain name.

Happy to help,

Andrew 8)




> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Chuck Schick
> Sent: Wednesday, May 24, 2006 11:13 AM
> To: Declude. JunkMail
> Subject: [Declude.JunkMail] How to get support from sniffer
> 
> It appears in the sniffer rulebase updated yesterday one of
> the rules trips the getrich test on sniffer when emails are 
> sent from or to our domain name.
> I have identified the rule and made a panic rule entry.  But 
> it appears the problem is more wide spread.  I have sent 
> messages to [EMAIL PROTECTED], [EMAIL PROTECTED], 
> and have submitted several examples to [EMAIL PROTECTED] 
> with absolutely no response.  I am concerned that my emails 
> are not getting through because of the bad rule - when I sent 
> a message to the sniffer list it never shows up making me 
> suspect the bad rule is torpedoing my email correspondence.
> 
> This is a big catch-22.  I wish that sortmonster had a web
> based ticketing system.  Anybody have a non email way of 
> getting ahold of sortmonster.  The tech support phone number 
> on the armresearch web site just goes to voice mail.
> 
> Sorry to post this here but I want to get this resolved.
> 
> Chuck Schick
> Warp 8, Inc.
> (303)-421-5140
> www.warp8.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 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 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.

RE: [Declude.JunkMail] How to get support from sniffer....

[Colbeck, Andrew]

Chuck, since I'm not blocked, I've sent a message on your behalf to Pete
as well as false@ ... while redacting your domain name.

Happy to help,

Andrew 8)




> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Chuck Schick
> Sent: Wednesday, May 24, 2006 11:13 AM
> To: Declude. JunkMail
> Subject: [Declude.JunkMail] How to get support from sniffer
> 
> It appears in the sniffer rulebase updated yesterday one of 
> the rules trips the getrich test on sniffer when emails are 
> sent from or to our domain name.
> I have identified the rule and made a panic rule entry.  But 
> it appears the problem is more wide spread.  I have sent 
> messages to [EMAIL PROTECTED], [EMAIL PROTECTED], 
> and have submitted several examples to [EMAIL PROTECTED] 
> with absolutely no response.  I am concerned that my emails 
> are not getting through because of the bad rule - when I sent 
> a message to the sniffer list it never shows up making me 
> suspect the bad rule is torpedoing my email correspondence.
> 
> This is a big catch-22.  I wish that sortmonster had a web 
> based ticketing system.  Anybody have a non email way of 
> getting ahold of sortmonster.  The tech support phone number 
> on the armresearch web site just goes to voice mail.
> 
> Sorry to post this here but I want to get this resolved.
> 
> Chuck Schick
> Warp 8, Inc.
> (303)-421-5140
> www.warp8.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 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.

[Declude.JunkMail] How to get support from sniffer....

[Chuck Schick]

It appears in the sniffer rulebase updated yesterday one of the rules trips
the getrich test on sniffer when emails are sent from or to our domain name.
I have identified the rule and made a panic rule entry.  But it appears the
problem is more wide spread.  I have sent messages to
[EMAIL PROTECTED], [EMAIL PROTECTED], and have submitted several
examples to [EMAIL PROTECTED] with absolutely no response.  I am
concerned that my emails are not getting through because of the bad rule -
when I sent a message to the sniffer list it never shows up making me
suspect the bad rule is torpedoing my email correspondence.

This is a big catch-22.  I wish that sortmonster had a web based ticketing
system.  Anybody have a non email way of getting ahold of sortmonster.  The
tech support phone number on the armresearch web site just goes to voice
mail.

Sorry to post this here but I want to get this resolved.

Chuck Schick
Warp 8, Inc.
(303)-421-5140
www.warp8.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.

RE: [Declude.JunkMail] Experience with 4.x

[Erik]

Matt, is your Delcude gatewayed?  Or is it running on the same server as
Imail?

-Erik


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matt
Sent: Wednesday, May 24, 2006 5:58 PM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] Experience with 4.x


I indicated earlier that it looked like a relative 10% improvement 
(about the difference between 35% and 32% hourly average CPU 
utilization).  I would think that this comes primarily from not needing 
to start the old declude executable every time, and the improvement 
might be more substantial on a system with a overtaxed disk.  I don't 
think the code is any more efficient as far as actual scanning goes.  
Besides that, it's typically the virus scanners and external tests that 
eat up most of the CPU on a Declude system and not Declude itself, and 
those things haven't changed.

I'm guessing that it might perform much better when redlined though if 
you tweak it right.  I believed that old Declude when getting rammed 
with overflow seemed to not perform linearly with normal performance 
with free CPU, but instead dropped, probably due to having a lot of CPU 
wait time overhead (there's probably a more accurate term for this).  
The new Declude can be more effectively controlled so as to not bog down 
the system as much.  So performance here might be 2x or more when 
redlined under optimal conditions.  This effect would be maximized if 
Declude would tie launching threads to a CPU monitor instead of a fixed 
number with no real clue as to what is perfect under any particular 
situation.

Matt




Nick Hayer wrote:

>
> Hi Matt,
>
> So you see any substantive performance improvement over 2x?
>
> -Nick
>
> Matt wrote:
>
>> Jay,
>>
>> It's not about moving along, it's about limiting the CPU to only
>> 100%, or at least not piling it on when it gets there.  I could be 
>> wrong in assuming that 1 thread = 1 message (hopefully I will be 
>> corrected if so), but 30 average messages being processed at once 
>> will most definitely peg my processors, and adding more threads when 
>> you are at 100% will actually slow down performance.
>>
>> Another note, not all systems are configured equally.  A vanilla
>> install of Declude would likely handle 4 times the number of messages 
>> that mine does since I run 4 external filters, two virus scanners, 
>> and something like 100 Declude filters (though they mostly get 
>> skipped with SKIPIFWEIGHT and END statements as they are targeted).  
>> Running a single virus scanner and RBL's is just a fraction of the 
>> load.  With my pre-scanning gateways blocking more than 90% of all 
>> traffic (about half of that is dictionary attacks and most of the 
>> rest is done with 'selective greylisting'), I can scale one server to 
>> handle over 20,000 addresses, possibly as many as 40,000 (doesn't 
>> host the accounts though), so despite the heavy config, it is optimized.
>>
>> But back to the real topic...I'm just guessing that 30
>> messages/threads is the limit for my box, but I'm sure that it isn't 
>> as high as 80, though setting it at 80 would be of no consequence 
>> outside of a prolonged heavy load caused by something like a backup 
>> of my spool.  It would be a bigger mistake to set it too low.
>>
>> Matt
>>
>>
>>
>> Jay Sudowski - Handy Networks LLC wrote:
>>
>>> 30 threads seems awfully low.  We set ours to 80 on a dual xeon box
>>> with a separate drive for spool/logging and we move right along 
>>> without any issues.
>>>
>>> Thanks!
>>> -
>>> Jay Sudowski // Handy Networks LLC
>>> Director of Technical Operations
>>> Providing Shared, Reseller, Semi Managed and Fully Managed Windows
>>> 2003 Hosting Solutions
>>> Tel: 877-70 HANDY x882 |  Fax: 888-300-2FAX
>>> www.handynetworks.com
>>> 
>>> From: [EMAIL PROTECTED] 
>>> [mailto:[EMAIL PROTECTED] On Behalf Of Matt
>>> Sent: Tuesday, May 23, 2006 3:25 PM
>>> To: Declude.JunkMail@declude.com
>>> Subject: Re: [Declude.JunkMail] Experience with 4.x
>>>
>>> Andrew,
>>>
>>> Thanks for your notes and their history.
>>>
>>> I'm using the following settings right now:
>>> THREADS30
>>> WAITFORMAIL500
>>> WAITFORTHREADS200
>>> WAITBETWEENTHREADS100
>>> WINSOCKCLEANUPOFF
>>> INVITEFIXON
>>> AUTOREVIEWON
>>> There are a few reasons for trying these values.
>>> THREADS 30 - I'm pretty confident that dual 3.2 Ghz Xeons and RAID
>>> can only handle 30 threads with average messages.  In reality, one 
>>> single message can spike the system to 100%, but these are 
>>> uncommon.  I figure that if I open this up too wide and I am dealing 
>>> with a backup or something, launching more threads when at 100% CPU 
>>> utilization will actually slow the system down.  This was the same 
>>> with 2.x and before.  There is added overhead to managing threads 
>>> and you don't want that to happen on top of 100% CPU utilization.  I 
>>> am going to 

[Declude.JunkMail] Possible Paypal Phishing

[John T \(Lists\)]

Attached are the headers to an e-mail I am suspecting as a clever phising
that has me worried.

It looks like a legit message sent on behalf of Paypal, however, it is sent
from an IP address not owned by Paypal BUT which has a REVDNS that ends in
paypal.com.

The message is full of links to images.postdirect.com but does have legit
links to paypal.com.

John T
eServices For You

"Seek, and ye shall find!"

Received: from srv5.eservicesforyou.net [67.94.227.40] by 
mail.eservicesforyou.net (SMTPD-8.20) id A02A059C;
 Tue, 23 May 2006 12:19:06 -0700
Received: from email-83.paypal.com ([206.165.246.83]) by 
srv5.eservicesforyou.net with Microsoft SMTPSVC(6.0.3790.1830);
 Tue, 23 May 2006 12:19:04 -0700
DomainKey-Signature: a=rsa-sha1;
 
h=Date:From:Subject:To:X-Header-CompanyDBUserName:Errors-To:List-Unsubscribe:Reply-To:X-Header-MasterId:X-Header-Versions:Message-ID:MIME-Version:Content-Type;
 
b=WlXEq1pDWhpajVdRtFzPcMshLTMrz08l/ijYdx+vckIXWxVdYeyr5NIpJxQeNPWyUCarrOPq21w4dRyp2X6KbCRrHgHIfPkX2eXvho3C4KwridkCfzshGGflsDPpkiHE;
 c=nofws; d=email.paypal.com;
 q=dns; s=yesmail1
Date: Tue, 23 May 2006 12:11:03 PDT
From: PayPal <[EMAIL PROTECTED]>
Subject: New: Tips, ID Theft Q&A, and more
To: "Srikanth Gudapati" <[EMAIL PROTECTED]>
X-Header-CompanyDBUserName: paypal
Errors-To: [EMAIL PROTECTED]
List-Unsubscribe: 
Reply-To: [EMAIL PROTECTED]
X-Header-MasterId: 905605
X-Header-Versions: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/html;
 charset=us-ascii
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 23 May 2006 19:19:04.0536 (UTC) 
FILETIME=[C157CD80:01C67E9D]
X-RBL-Warning: SPAMCHECK: Message failed SPAMCHECK: 10.
X-RBL-Warning: WHITEFILTER3: Message failed WHITEFILTER3 test (line 28, weight 
-25)
X-RBL-Warning: GRAYFILTER1: Message failed GRAYFILTER1 test (line 145, weight 5)
X-RBL-Warning: GRAYFILTER2: Message failed GRAYFILTER2 test (line 5, weight 5)
X-RBL-Warning: SUBJECTSTART_IS: Message failed SUBJECTSTART_IS test (line 52, 
weight 15) (weight capped at 15)
X-RBL-Warning: KEYSUBJECT: Message failed KEYSUBJECT test (line 85, weight 15)
X-Note: ###
X-Note:  This message scanned by eServices For You for viruses and junkmail.
X-Note:  Scan time start at 12:20:50 on 23 May 2006.
X-Note:  Total weight of message as a result of tests: 28
X-Note:  TESTS FAILED: NOABUSE, IPNOTINMX, NOLEGITCONTENT, SPAMCHECK, 
SUBJECTSTART_IS, KEYSUBJECT
X-Note:  Sender is [EMAIL PROTECTED] and spool file is D602a007c3bbd.smd
X-Note:  This E-mail was received from RevDNS: [email-83.paypal.com]
X-Note:  This e-mail was received from IP: [206.165.246.83]
X-Note:  To report any issues,
 please contact [EMAIL PROTECTED]
X-Note: ###

Re: [Declude.JunkMail] Experience with 4.x

[Matt]

I indicated earlier that it looked like a relative 10% improvement 
(about the difference between 35% and 32% hourly average CPU 
utilization).  I would think that this comes primarily from not needing 
to start the old declude executable every time, and the improvement 
might be more substantial on a system with a overtaxed disk.  I don't 
think the code is any more efficient as far as actual scanning goes.  
Besides that, it's typically the virus scanners and external tests that 
eat up most of the CPU on a Declude system and not Declude itself, and 
those things haven't changed.


I'm guessing that it might perform much better when redlined though if 
you tweak it right.  I believed that old Declude when getting rammed 
with overflow seemed to not perform linearly with normal performance 
with free CPU, but instead dropped, probably due to having a lot of CPU 
wait time overhead (there's probably a more accurate term for this).  
The new Declude can be more effectively controlled so as to not bog down 
the system as much.  So performance here might be 2x or more when 
redlined under optimal conditions.  This effect would be maximized if 
Declude would tie launching threads to a CPU monitor instead of a fixed 
number with no real clue as to what is perfect under any particular 
situation.


Matt




Nick Hayer wrote:



Hi Matt,

So you see any substantive performance improvement over 2x?

-Nick

Matt wrote:


Jay,

It's not about moving along, it's about limiting the CPU to only 
100%, or at least not piling it on when it gets there.  I could be 
wrong in assuming that 1 thread = 1 message (hopefully I will be 
corrected if so), but 30 average messages being processed at once 
will most definitely peg my processors, and adding more threads when 
you are at 100% will actually slow down performance.


Another note, not all systems are configured equally.  A vanilla 
install of Declude would likely handle 4 times the number of messages 
that mine does since I run 4 external filters, two virus scanners, 
and something like 100 Declude filters (though they mostly get 
skipped with SKIPIFWEIGHT and END statements as they are targeted).  
Running a single virus scanner and RBL's is just a fraction of the 
load.  With my pre-scanning gateways blocking more than 90% of all 
traffic (about half of that is dictionary attacks and most of the 
rest is done with 'selective greylisting'), I can scale one server to 
handle over 20,000 addresses, possibly as many as 40,000 (doesn't 
host the accounts though), so despite the heavy config, it is optimized.


But back to the real topic...I'm just guessing that 30 
messages/threads is the limit for my box, but I'm sure that it isn't 
as high as 80, though setting it at 80 would be of no consequence 
outside of a prolonged heavy load caused by something like a backup 
of my spool.  It would be a bigger mistake to set it too low.


Matt



Jay Sudowski - Handy Networks LLC wrote:

30 threads seems awfully low.  We set ours to 80 on a dual xeon box 
with a separate drive for spool/logging and we move right along 
without any issues.


Thanks!
-
Jay Sudowski // Handy Networks LLC
Director of Technical Operations
Providing Shared, Reseller, Semi Managed and Fully Managed Windows 
2003 Hosting Solutions

Tel: 877-70 HANDY x882 |  Fax: 888-300-2FAX
www.handynetworks.com

From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Matt

Sent: Tuesday, May 23, 2006 3:25 PM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] Experience with 4.x

Andrew,

Thanks for your notes and their history.

I'm using the following settings right now:
THREADS30
WAITFORMAIL500
WAITFORTHREADS200
WAITBETWEENTHREADS100
WINSOCKCLEANUPOFF
INVITEFIXON
AUTOREVIEWON
There are a few reasons for trying these values.
THREADS 30 - I'm pretty confident that dual 3.2 Ghz Xeons and RAID 
can only handle 30 threads with average messages.  In reality, one 
single message can spike the system to 100%, but these are 
uncommon.  I figure that if I open this up too wide and I am dealing 
with a backup or something, launching more threads when at 100% CPU 
utilization will actually slow the system down.  This was the same 
with 2.x and before.  There is added overhead to managing threads 
and you don't want that to happen on top of 100% CPU utilization.  I 
am going to back up my server later tonight to see if I can't find 
what the magic number is since I don't want to be below that magic 
number, and it would probably be best to be a little above it.


WAITFORMAIL 500 - On my server, this never kicks in, but if it did, 
it wouldn't make sense to delay for too long because I could build 
up messages.  A half second seems good.


WAITFORTHREADS 200 - This apparently kicks in only when I reach my 
thread limit; sort of like a throttle.  I don't want it to be too 
long because this should only happen when I am hammere

Re: [Declude.JunkMail] Experience with 4.x

[Nick Hayer]

Hi Matt,

So you see any substantive performance improvement over 2x?

-Nick

Matt wrote:


Jay,

It's not about moving along, it's about limiting the CPU to only 100%, 
or at least not piling it on when it gets there.  I could be wrong in 
assuming that 1 thread = 1 message (hopefully I will be corrected if 
so), but 30 average messages being processed at once will most 
definitely peg my processors, and adding more threads when you are at 
100% will actually slow down performance.


Another note, not all systems are configured equally.  A vanilla 
install of Declude would likely handle 4 times the number of messages 
that mine does since I run 4 external filters, two virus scanners, and 
something like 100 Declude filters (though they mostly get skipped 
with SKIPIFWEIGHT and END statements as they are targeted).  Running a 
single virus scanner and RBL's is just a fraction of the load.  With 
my pre-scanning gateways blocking more than 90% of all traffic (about 
half of that is dictionary attacks and most of the rest is done with 
'selective greylisting'), I can scale one server to handle over 20,000 
addresses, possibly as many as 40,000 (doesn't host the accounts 
though), so despite the heavy config, it is optimized.


But back to the real topic...I'm just guessing that 30 
messages/threads is the limit for my box, but I'm sure that it isn't 
as high as 80, though setting it at 80 would be of no consequence 
outside of a prolonged heavy load caused by something like a backup of 
my spool.  It would be a bigger mistake to set it too low.


Matt



Jay Sudowski - Handy Networks LLC wrote:

30 threads seems awfully low.  We set ours to 80 on a dual xeon box 
with a separate drive for spool/logging and we move right along 
without any issues.


Thanks!
-
Jay Sudowski // Handy Networks LLC
Director of Technical Operations
Providing Shared, Reseller, Semi Managed and Fully Managed Windows 
2003 Hosting Solutions

Tel: 877-70 HANDY x882 |  Fax: 888-300-2FAX
www.handynetworks.com

From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Matt

Sent: Tuesday, May 23, 2006 3:25 PM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] Experience with 4.x

Andrew,

Thanks for your notes and their history.

I'm using the following settings right now:
THREADS30
WAITFORMAIL500
WAITFORTHREADS200
WAITBETWEENTHREADS100
WINSOCKCLEANUPOFF
INVITEFIXON
AUTOREVIEWON
There are a few reasons for trying these values.
THREADS 30 - I'm pretty confident that dual 3.2 Ghz Xeons and RAID 
can only handle 30 threads with average messages.  In reality, one 
single message can spike the system to 100%, but these are uncommon.  
I figure that if I open this up too wide and I am dealing with a 
backup or something, launching more threads when at 100% CPU 
utilization will actually slow the system down.  This was the same 
with 2.x and before.  There is added overhead to managing threads and 
you don't want that to happen on top of 100% CPU utilization.  I am 
going to back up my server later tonight to see if I can't find what 
the magic number is since I don't want to be below that magic number, 
and it would probably be best to be a little above it.


WAITFORMAIL 500 - On my server, this never kicks in, but if it did, 
it wouldn't make sense to delay for too long because I could build up 
messages.  A half second seems good.


WAITFORTHREADS 200 - This apparently kicks in only when I reach my 
thread limit; sort of like a throttle.  I don't want it to be too 
long because this should only happen when I am hammered, but it is 
wise not to keep hammering when you are at 100%.  Sort of a mixed bag 
choice here.


WAITBETWEENTHREADS 100 - I see this setting as being the biggest 
issue with sizing a server.  Setting it at 100 ms means that I can 
only handle 10 messages per second, and this establishes an upper 
limit for what the server can do.   I currently average about 5 
messages per second coming from my gateways at peak hours, so I 
figured that to be safe, I should double that value.


INVITEFIX ON - I have it on because it comes on by default and I 
don't know any better.  I know nothing about the cause for needing 
this outside of brief comments.  It seems strange that my Declude 
setup could ruin an invitation unless I was using footers.  If this 
is only triggered by footer use, I would like to know so that I could 
turn it off.  I would imagine that this causes extra load to do the 
check.


AUTOREVIEW ON - I have this on for the same reason that Andrew 
pointed out.  When I restart Decludeproc, messages land in my review 
folder, and I don't wish to keep manually fishing things out.  If 
there is an issue with looping, it would be wise for Declude to make 
this only trigger say every 15 minutes instead of more regularly.

Feel free to add to this if you want.

Matt











Colbeck, Andrew wrote: I'd second that... on 

RE: [Declude.JunkMail] Experience with 4.x

[David Barker]

We have not seen this issue with SmarterMail.

David B
www.declude.com 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jay Sudowski -
Handy Networks LLC
Sent: Wednesday, May 24, 2006 4:00 AM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] Experience with 4.x

In light of this reference to WINSOCKCLEANUP being an iMail only issue, do I
even need to enable this on our SmarterMail servers?

-Jay


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Barker
Sent: Tuesday, May 23, 2006 6:30 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] Experience with 4.x

The only way that we have detected this was with Imail and mail being stuck
in the spool. "...network stack causing loss of functionality for basic
network operations" is generic but if I remember correctly when this
happened the admin was not even able to ping an outside server, which would
suggest to me other IP communications fail as well.

David B
www.declude.com

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew
Sent: Tuesday, May 23, 2006 6:26 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] Experience with 4.x

Thanks, David.

I've read all of the support forum emails that have been posted on the
WINSOCKCLEANUP and even reviewed them again via the mail archive website
before my own implementation.

What I haven't been able to tell is whether I can diagnose this issue if I
have it before it becomes an outage.

Can it only be detected by it's side-effect of filling up the proc folder?

If I have a mechanism on my IMail server that does DNS queries... Will they
fail when the WinSock needs being cleaned up?  I think not, as at least one
posting specifically mentioned that IMail IP4R tests worked when DecludeProc
IP4R tests timed out.

Your official description for "WINSOCKCLEANUP ON" says "...network stack
causing loss of functionality for basic network operations"; is this
deliberately generic so that you don't have to explain what a DNS test is,
or does it imply that other IP communications will also fail, e.g.
SMTP and (critically for me) RDP?

Andrew.



> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of David Barker
> Sent: Tuesday, May 23, 2006 3:12 PM
> To: Declude.JunkMail@declude.com
> Subject: RE: [Declude.JunkMail] Experience with 4.x
> 
> Andrew,
> 
> In certain cases we found that Imail would stop resolving, it seemed 
> that stop/starting the decludeproc or smtp service fixed the problem 
> by resetting the winsock. So we added WINSOCKCLEANUP to deal with this

> specific Imail issue.
> 
> David B
> www.declude.com
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, 
> Andrew
> Sent: Tuesday, May 23, 2006 3:45 PM
> To: Declude.JunkMail@declude.com
> Subject: RE: [Declude.JunkMail] Experience with 4.x
> 
> David, is there a proactive way to detect if an installation would 
> benefit from the WINSOCKCLEANUP ON directive in declude.cfg?
> 
> I would rather be able to detect this while it's happening than to 
> react when I find that spam is leaking or that the proc folder is 
> continually growing.
> 
> Andrew.
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> David Barker
> > Sent: Tuesday, May 23, 2006 7:48 AM
> > To: Declude.JunkMail@declude.com
> > Subject: RE: [Declude.JunkMail] Experience with 4.x
> > 
> > Mike,
> > 
> > 1. The  WINSOCKCLEANUPON activates when the \Proc reaches 0
> > 2. If Decludeproc stops unexpectedly files it is busy with
> are move to
> > the \review
> > 3. You can use AUTOREVIEW   ON to have these move back to the \proc
> > 4. Be aware though if there is a real problem message you may find 
> > that the message gets looped 5. Make sure you have the
> latest version
> > of decludeproc ... There should be a release later today or
> tommorow.
> > 
> > David B
> > www.declude.com
> > 
> > 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Mike N
> > Sent: Tuesday, May 23, 2006 10:23 AM
> > To: Declude.JunkMail@declude.com
> > Subject: Re: [Declude.JunkMail] Experience with 4.x
> > 
> > I found that WINSOCKCLEANUP ON would force a reset if the \proc 
> > directory
> > never hits 0.   In this case, files build up in the \review 
> > subfolder which
> > require manual processing.
> > 
> > - Original Message -
> > From: "David Barker" <[EMAIL PROTECTED]>
> > To: 
> > Sent: Tuesday, May 23, 2006 7:34 AM
> > Subject: RE: [Declude.JunkMail] Experience with 4.x
> > 
> > 
> > > The purpose of WINSOCKCLEANUPON is to reset the 
> > winsock, what
> > > happens when using this setting is that when the \proc
> > directory hit 0
> > > decludeproc will finish processing all the messages in the \work 
> > > b

Re: [Declude.JunkMail] Experience with 4.x

[Matt]

Jay,

It's not about moving along, it's about limiting the CPU to only 100%, 
or at least not piling it on when it gets there.  I could be wrong in 
assuming that 1 thread = 1 message (hopefully I will be corrected if 
so), but 30 average messages being processed at once will most 
definitely peg my processors, and adding more threads when you are at 
100% will actually slow down performance.


Another note, not all systems are configured equally.  A vanilla install 
of Declude would likely handle 4 times the number of messages that mine 
does since I run 4 external filters, two virus scanners, and something 
like 100 Declude filters (though they mostly get skipped with 
SKIPIFWEIGHT and END statements as they are targeted).  Running a single 
virus scanner and RBL's is just a fraction of the load.  With my 
pre-scanning gateways blocking more than 90% of all traffic (about half 
of that is dictionary attacks and most of the rest is done with 
'selective greylisting'), I can scale one server to handle over 20,000 
addresses, possibly as many as 40,000 (doesn't host the accounts 
though), so despite the heavy config, it is optimized.


But back to the real topic...I'm just guessing that 30 messages/threads 
is the limit for my box, but I'm sure that it isn't as high as 80, 
though setting it at 80 would be of no consequence outside of a 
prolonged heavy load caused by something like a backup of my spool.  It 
would be a bigger mistake to set it too low.


Matt



Jay Sudowski - Handy Networks LLC wrote:


30 threads seems awfully low.  We set ours to 80 on a dual xeon box with a 
separate drive for spool/logging and we move right along without any issues.

Thanks!
-
Jay Sudowski // Handy Networks LLC
Director of Technical Operations
Providing Shared, Reseller, Semi Managed and Fully Managed Windows 2003 Hosting 
Solutions
Tel: 877-70 HANDY x882 |  Fax: 888-300-2FAX
www.handynetworks.com

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt
Sent: Tuesday, May 23, 2006 3:25 PM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] Experience with 4.x

Andrew,

Thanks for your notes and their history.

I'm using the following settings right now:
THREADS30
WAITFORMAIL500
WAITFORTHREADS200
WAITBETWEENTHREADS100
WINSOCKCLEANUPOFF
INVITEFIXON
AUTOREVIEWON
There are a few reasons for trying these values.
THREADS 30 - I'm pretty confident that dual 3.2 Ghz Xeons and RAID can only 
handle 30 threads with average messages.  In reality, one single message can 
spike the system to 100%, but these are uncommon.  I figure that if I open this 
up too wide and I am dealing with a backup or something, launching more threads 
when at 100% CPU utilization will actually slow the system down.  This was the 
same with 2.x and before.  There is added overhead to managing threads and you 
don't want that to happen on top of 100% CPU utilization.  I am going to back 
up my server later tonight to see if I can't find what the magic number is 
since I don't want to be below that magic number, and it would probably be best 
to be a little above it.

WAITFORMAIL 500 - On my server, this never kicks in, but if it did, it wouldn't 
make sense to delay for too long because I could build up messages.  A half 
second seems good.

WAITFORTHREADS 200 - This apparently kicks in only when I reach my thread 
limit; sort of like a throttle.  I don't want it to be too long because this 
should only happen when I am hammered, but it is wise not to keep hammering 
when you are at 100%.  Sort of a mixed bag choice here.

WAITBETWEENTHREADS 100 - I see this setting as being the biggest issue with 
sizing a server.  Setting it at 100 ms means that I can only handle 10 messages 
per second, and this establishes an upper limit for what the server can do.   I 
currently average about 5 messages per second coming from my gateways at peak 
hours, so I figured that to be safe, I should double that value.

INVITEFIX ON - I have it on because it comes on by default and I don't know any 
better.  I know nothing about the cause for needing this outside of brief 
comments.  It seems strange that my Declude setup could ruin an invitation 
unless I was using footers.  If this is only triggered by footer use, I would 
like to know so that I could turn it off.  I would imagine that this causes 
extra load to do the check.

AUTOREVIEW ON - I have this on for the same reason that Andrew pointed out.  
When I restart Decludeproc, messages land in my review folder, and I don't wish 
to keep manually fishing things out.  If there is an issue with looping, it 
would be wise for Declude to make this only trigger say every 15 minutes 
instead of more regularly.
Feel free to add to this if you want.

Matt











Colbeck, Andrew wrote: 
I'd second that... on both the observed behaviour and the request for documentation.


I'm attaching my highly commented declud

RE: [Declude.JunkMail] Experience with 4.x

[Jay Sudowski - Handy Networks LLC]

30 threads seems awfully low.  We set ours to 80 on a dual xeon box with a 
separate drive for spool/logging and we move right along without any issues.

Thanks!
-
Jay Sudowski // Handy Networks LLC
Director of Technical Operations
Providing Shared, Reseller, Semi Managed and Fully Managed Windows 2003 Hosting 
Solutions
Tel: 877-70 HANDY x882 |  Fax: 888-300-2FAX
www.handynetworks.com

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt
Sent: Tuesday, May 23, 2006 3:25 PM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] Experience with 4.x

Andrew,

Thanks for your notes and their history.

I'm using the following settings right now:
THREADS        30
WAITFORMAIL    500
WAITFORTHREADS        200
WAITBETWEENTHREADS    100
WINSOCKCLEANUP        OFF
INVITEFIX    ON
AUTOREVIEW        ON
There are a few reasons for trying these values.
THREADS 30 - I'm pretty confident that dual 3.2 Ghz Xeons and RAID can only 
handle 30 threads with average messages.  In reality, one single message can 
spike the system to 100%, but these are uncommon.  I figure that if I open this 
up too wide and I am dealing with a backup or something, launching more threads 
when at 100% CPU utilization will actually slow the system down.  This was the 
same with 2.x and before.  There is added overhead to managing threads and you 
don't want that to happen on top of 100% CPU utilization.  I am going to back 
up my server later tonight to see if I can't find what the magic number is 
since I don't want to be below that magic number, and it would probably be best 
to be a little above it.

WAITFORMAIL 500 - On my server, this never kicks in, but if it did, it wouldn't 
make sense to delay for too long because I could build up messages.  A half 
second seems good.

WAITFORTHREADS 200 - This apparently kicks in only when I reach my thread 
limit; sort of like a throttle.  I don't want it to be too long because this 
should only happen when I am hammered, but it is wise not to keep hammering 
when you are at 100%.  Sort of a mixed bag choice here.

WAITBETWEENTHREADS 100 - I see this setting as being the biggest issue with 
sizing a server.  Setting it at 100 ms means that I can only handle 10 messages 
per second, and this establishes an upper limit for what the server can do.   I 
currently average about 5 messages per second coming from my gateways at peak 
hours, so I figured that to be safe, I should double that value.

INVITEFIX ON - I have it on because it comes on by default and I don't know any 
better.  I know nothing about the cause for needing this outside of brief 
comments.  It seems strange that my Declude setup could ruin an invitation 
unless I was using footers.  If this is only triggered by footer use, I would 
like to know so that I could turn it off.  I would imagine that this causes 
extra load to do the check.

AUTOREVIEW ON - I have this on for the same reason that Andrew pointed out.  
When I restart Decludeproc, messages land in my review folder, and I don't wish 
to keep manually fishing things out.  If there is an issue with looping, it 
would be wise for Declude to make this only trigger say every 15 minutes 
instead of more regularly.
Feel free to add to this if you want.

Matt











Colbeck, Andrew wrote: 
I'd second that... on both the observed behaviour and the request for 
documentation.
 
I'm attaching my highly commented declude.cfg as a reasonable sample.
 
Andrew 8)
 
 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt
Sent: Tuesday, May 23, 2006 10:36 AM
To: Declude.JunkMail@declude.com
Subject: Re: [Declude.JunkMail] Experience with 4.x
David,

That did the trick.  I can't even see any messages in my proc folder any more.  
I might suggest adding your explanation to the comments in the file just in 
case others feel the need to turn this on like I did.  I recalled the issues 
from the list and I turned it on because I didn't want the possibility of DNS 
crapping out and the leakage that this would cause.

Here's a screen cap of what my processor graph looks like now:


Thanks,

Matt



David Barker wrote: 
The purpose of WINSOCKCLEANUPON is to reset the winsock, what
happens when using this setting is that when the \proc directory hit 0
decludeproc will finish processing all the messages in the \work before
checking the \proc again. As WINSOCKCLEANUP is to be used only by those who
experience DNS issues I would suggest running your tests again with
WINSOCKCLEANUP commented out and see how the behavior differs. Also having
the WAITFORMAIL to low can cause the CPU to process very high as it is
constantly checking the \proc I would suggest a minimum of 500-1000

David B
www.declude.com

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matt
Sent: Monday, May 22, 2006 8:12 PM
To: Declude.JunkMail@declude.com
Subject: Re: 

RE: [Declude.JunkMail] Experience with 4.x

[Jay Sudowski - Handy Networks LLC]

In light of this reference to WINSOCKCLEANUP being an iMail only issue,
do I even need to enable this on our SmarterMail servers?

-Jay


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Barker
Sent: Tuesday, May 23, 2006 6:30 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] Experience with 4.x

The only way that we have detected this was with Imail and mail being
stuck
in the spool. "...network stack causing loss of functionality for basic
network operations" is generic but if I remember correctly when this
happened the admin was not even able to ping an outside server, which
would
suggest to me other IP communications fail as well.

David B
www.declude.com

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, Andrew
Sent: Tuesday, May 23, 2006 6:26 PM
To: Declude.JunkMail@declude.com
Subject: RE: [Declude.JunkMail] Experience with 4.x

Thanks, David.

I've read all of the support forum emails that have been posted on the
WINSOCKCLEANUP and even reviewed them again via the mail archive website
before my own implementation.

What I haven't been able to tell is whether I can diagnose this issue if
I
have it before it becomes an outage.

Can it only be detected by it's side-effect of filling up the proc
folder?

If I have a mechanism on my IMail server that does DNS queries... Will
they
fail when the WinSock needs being cleaned up?  I think not, as at least
one
posting specifically mentioned that IMail IP4R tests worked when
DecludeProc
IP4R tests timed out.

Your official description for "WINSOCKCLEANUP ON" says "...network stack
causing loss of functionality for basic network operations"; is this
deliberately generic so that you don't have to explain what a DNS test
is,
or does it imply that other IP communications will also fail, e.g.
SMTP and (critically for me) RDP?

Andrew.



> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of David Barker
> Sent: Tuesday, May 23, 2006 3:12 PM
> To: Declude.JunkMail@declude.com
> Subject: RE: [Declude.JunkMail] Experience with 4.x
> 
> Andrew,
> 
> In certain cases we found that Imail would stop resolving, it seemed 
> that stop/starting the decludeproc or smtp service fixed the problem 
> by resetting the winsock. So we added WINSOCKCLEANUP to deal with this

> specific Imail issue.
> 
> David B
> www.declude.com
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Colbeck, 
> Andrew
> Sent: Tuesday, May 23, 2006 3:45 PM
> To: Declude.JunkMail@declude.com
> Subject: RE: [Declude.JunkMail] Experience with 4.x
> 
> David, is there a proactive way to detect if an installation would 
> benefit from the WINSOCKCLEANUP ON directive in declude.cfg?
> 
> I would rather be able to detect this while it's happening than to 
> react when I find that spam is leaking or that the proc folder is 
> continually growing.
> 
> Andrew.
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> David Barker
> > Sent: Tuesday, May 23, 2006 7:48 AM
> > To: Declude.JunkMail@declude.com
> > Subject: RE: [Declude.JunkMail] Experience with 4.x
> > 
> > Mike,
> > 
> > 1. The  WINSOCKCLEANUPON activates when the \Proc reaches 0
> > 2. If Decludeproc stops unexpectedly files it is busy with
> are move to
> > the \review
> > 3. You can use AUTOREVIEW   ON to have these move back to the \proc
> > 4. Be aware though if there is a real problem message you may find 
> > that the message gets looped 5. Make sure you have the
> latest version
> > of decludeproc ... There should be a release later today or
> tommorow.
> > 
> > David B
> > www.declude.com
> > 
> > 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Mike N
> > Sent: Tuesday, May 23, 2006 10:23 AM
> > To: Declude.JunkMail@declude.com
> > Subject: Re: [Declude.JunkMail] Experience with 4.x
> > 
> > I found that WINSOCKCLEANUP ON would force a reset if the \proc 
> > directory
> > never hits 0.   In this case, files build up in the \review 
> > subfolder which
> > require manual processing.
> > 
> > - Original Message -
> > From: "David Barker" <[EMAIL PROTECTED]>
> > To: 
> > Sent: Tuesday, May 23, 2006 7:34 AM
> > Subject: RE: [Declude.JunkMail] Experience with 4.x
> > 
> > 
> > > The purpose of WINSOCKCLEANUPON is to reset the 
> > winsock, what
> > > happens when using this setting is that when the \proc
> > directory hit 0
> > > decludeproc will finish processing all the messages in the \work 
> > > before checking the \proc again.
> > 
> > ---
> > 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 came from th