Re: [Declude.JunkMail] OT: Issues with Windows 2003 FTP service

[Matt]

Sandy, you have such a delicate way with words... I am only passing on what I was told by Peter from VamSoft.  There is a whole thread on this where Peter confirmed the affect on FTP (but not IIS) in VamSoft's o.e.support newsgroup, which I see you found after sending this message. I personally would be surprised to see a fixed (non-tweakable) thread limit, but I can't make a judgment without some form of verification of your suggestion considering the guidance that I was given (I'm not the programmer nor the expert).  This server averages only about 2% CPU utilization, so it would be a shame to have it top out so prematurely.  I did previously search for "CDO_OnArrival thread", but came up with nothing at all that was useful.  Looks like I should have searched for "SMTPSVC threads" instead since I did come across an article mentioning the registry parameters that you mentioned.  I'll wait for Peter to reply to your suggestion. Regarding the MS SMTP tarpitting, you have to trust me on that, or at least test it yourself before suggesting that I am wrong here.  This was a different issue than that other server had.  The issue with that server was that MS SMTP returns 552 errors in the middle of the DATA, and while many servers support that, IMail doesn't.  I have since convinced people at Ipswitch that this needs to be changed even if it isn't technically RFC compliant due to real-world conditions, and the fact that Microsoft's implementation makes more sense and should be easy enough to support.  This hasn't apparently been worked into the software yet because they were in the final stages of testing IMail 2006, and this isn't a quick fix.  I expect to see it happen soon though, hopefully right after they get the major issues worked out with the 2006 release. The MS SMTP tarpitting issue is one that I came across under other circumstances.  When I had this turned on (not the ORF version, but the registry hack), I experienced the condition repeatedly from all sorts of servers where I was the recipient.  After extensive research and testing, I found that it was this registry hack that was causing the majority of the servers to never recognize the 552 error code, and since all this did was delay the response, one has to assume that the delay of the 552 error was responsible.  With this turned off (the default), I am still experiencing some issues with requeued incoming oversized E-mail, but they are much lower in number and related to the sending of 552 errors in the middle of the DATA command.  Microsoft shouldn't be haphazardly delaying all 5xx errors, but instead should just be delaying the ones related to invalid recipients.  This was a bad oversight on their part, and I am 100% positive about the cause.  It may be almost unnoticeable to those that are running this in front of less E-mail addresses and don't actively monitor their bandwidth like I do.  Due to my volume, this issue became so large that it was eating up many times my normal incoming bandwidth on a regular basis. Note that I tried to work around both MS SMTP 552 issues on incoming E-mail by setting MS SMTP to accept messages of unlimited size and then configuring IMail to signal the error, but MS SMTP hears the 552 error that IMail generates and then tries to bounce the entire oversized message through the configured Smart Host, which was the same IMail server that wouldn't accept the message in the first place.  Why you would want to send a 50 MB bounce message is beyond me.  I could kludge something together to bypass the problem, that's not the issue though.  My point is that I have been through this stuff with a fine-toothed comb. Matt Sanford Whiteman wrote: The exact source of the problem was a limit in threads in MS SMTP, which is something like 20 per processor (not sure if hyperthreading counts in this case). . . This isn't an accurate claim. It sounds like you just haven't tried to tune MS SMTP appropriately for load/resources/growth. That's fine, since MS doesn't push you too hard on this, but please do some more lab work before deciding that MS SMTP is broken. Look into the following values: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters\PoolThreadLimit HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSVC\Queuing\MaxPercentPoolThreads HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSVC\Queuing\AdditionalPoolThreadsPerProc You also need to realize the differences between I/O completion port architecture, callbacks, and pure multithreading. It's possible to bottleneck anything, but that's an implementation problem with a given event sink, not a problem with the overall framework. . . . this limitation in the MS SMTP architecture makes it inappropriate for any full scale spam blocking solution such as Declude unless you have that application ride behind MS SMTP instead of being plugged into it. . . . Sorry, man, but that's FUD. I appreciate what you found with FTP in your config, but let's not jump over the available data. One other note. I had previously used the Windows registry hack to enable a native tarpitting feature in MS SMTP with even worse affects. The built-in tarpitting in MS SMTP will delay all 5xx error codes by the time that you set, and this included the 552 error used when messages are over the maximum size. The result of this terrible oversight is that a fair number of servers will not recognize the delayed 552 error and will requeue the oversized messages over and over again, and that eats up a lot of bandwidth real, real quick. Matt, you _know_ this isn't cause and effect, since you and I both looked at a specific server _without_ tarpitting enabled that exhibited the problem with oversize messages. There may be an additional wrinkle added by ttarpitting, but it's not the root cause of the problem. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- [This E-mail was scanned for viruses by Declude EVA 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.