[Top] [All Lists]

Re: Proposal: Using Conservative EHLO Response Parser Behaviour For Tarpitting

2007-06-18 18:40:38

David F. Skoll wrote:

The five minute timeout is the minimum required, so it would be the foreign host in violation. A zealot wouldn't care, but I would. This idea doesn't use that timeout, though; it sends continuation lines periodically at short intervals that all hosts are practically guaranteed to tolerate.

If this list is archived anywhere, please read the exchange between Hector
Santos and me.  He wanted to use this idea to get an SMTP server to "force"
(or at least "encourage") a client to wait longer than its normal timeout.
I believe this will annoy legitimate SMTP clients enough that they'll find it
worthwhile to code an overall timeout rather than a per-read timeout (as is
commonly done now.)

[if you are going to use my name in vain, please do so correctly]

Nahhhhhhh, as was already indicated, this was proven to work from a 100% SMTP compliant standpoint.

The only problem is that, as Tony and myself eventually showed by actually checking a selected group of open source software, there is enough legacy software out there that don't follow or follow the parsing of responds code in different ways.

In other words, SMTP COMPATIBILITY WAS THE MAIN ISSUE, thus it wasn't prudent to clarify the specification as I proposed it to be clarified. I knew exactly what I was doing when I proposed it and took my chances the opposite would prevail - as it did. I knew exactly what I was doing and would not have had proposed it if it wasn't an issue that was discussed and put into motion in other forums. It wasn't a devil on my shoulder, nor a raised hair in my back idea - but actual exploratory work studied with a working history based on precedence that does back 25 years.

It, nor its conclusion, had absolutely nothing to do what you are talking about, other than it was simply a matter of compatibility across the board.

But guess what, I still believe we are still leave the industry with the potential timeout design delimma which may not show up at all, but could depending on how certain new technologies on the horizon are adopted. I will guarantee you someone will come across he need: "Hmmmm, I need something that will tell the client - please hold." once they attempt begin to implement dynamic server-side processing concepts with potential for delays - for one reason only - without, you can have premature drops as it happen under FTP scenarios where general FILE processing is more of a reality before EMAIL AVS processing came about.


Hector Santos, CTO

<Prev in Thread] Current Thread [Next in Thread>