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.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com