Sandy,

I have a lot of interest in finding a workaround to the thread issue, and no doubt this has promise.  I'm just saying that I'm reserving judgment until it is tested.  I will probably test it myself later today since Peter didn't respond yet to your post.  If you have some suggestions for what to set these registry values as, please don't hesitate to post them here or on the o.e.support group.

Regarding the MS SMTP tarpitting, this was figured out long before issues with that client that turned out to be related to the interaction of IMail and MS SMTP.  The MS SMTP tarpitting issue is much more widespread.  Certainly it doesn't make sense to delay a 552 response when tarpitting, and either the delay itself, or the fact that this is combined with MS SMTP sending the response out of sequence, produces very understandable issues.  When I disabled this tweak, almost all of the issues disappeared immediately.  The only remaining issues are ones specifically related to the out of sequence response from MS SMTP, but they are much less frequent than what I was seeing.

Matt



Sanford Whiteman wrote:
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.


  

Reply via email to