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

2006-01-10 Thread Sanford Whiteman
> 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.

Peter  is  very  smart  developer, but not a systems guy. You probably
noticed  our  back-and-forth  about  ORF's  64-bit support. During our
off-list  continuation,  I  was struck equally by his lack of facility
with  certain  common OS features (such as COM+) and yet the expertise
with  which  he  built  ORF  for scaleability and performance. I don't
expect him to do in-depth tweaking outside of his app (and I'm sure he
didn't touch these parameters here).

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

Tweak  the  settings and open up a lot of sessions to your server; you
will  see  that the number of worker threads (as opposed to I/O ports)
that can be created rises accordingly.

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

I'm sure you _are_ seeing aggravated problems with tarpitting enabled.
Yet  it's  clear  that you've observed problems with oversize messages
_whether  or  not_  tarpitting  is  enabled, and you treated that fact
insufficiently, it seemed to me.

From  what you wrote, it sounds like running the sink that I wrote for
the  non-tarpitting  server would solve both problems. As you may have
noticed,  it  generates  a  DSN  that  does  not  include the original
message, just the subject line, the message size, and the size limit.

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


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

2006-01-10 Thread Sanford Whiteman
> 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.