RE: Keep SMTP Client Alive [: Re: Activation points and callout m odes]

Sorry I haven't been following the list lately; I missed this thread when it
was "new".

We had a similar problem in lemonade.  There was a draft, just expired,
draft-burger-smtp-rdlv-00, that standardized an approach very similar to
what Hector worked out here.  The only substantive difference is the client
and server negotiate the time-out period (rather than the guess as to how
long is too long).

We are working on an update.

> -----Original Message-----
> From: Hector Santos [mailto:[email protected]]
> Sent: Wednesday, February 02, 2005 5:08 PM
> To: Tony Finch; The Purple Streak, Hilarie Orman
> Cc: [email protected]
> Subject: Keep SMTP Client Alive [: Re: Activation points and callout
> modes]
> 
> 
> 
> Good News!
> 
> I just explored the idea of keeping an SMTP client alive with 
> a lengthy
> callout using the SMTP "1xx" response code.
> 
> I used Outlook Express (an obvious popular MUA) as the test 
> to see how it
> will behave.  I ran 4 test:
> 
> Test #1 - Does Outlook honor the "1xx " (no dash) response?
> Test #2 - Does Outlook honor the "1xx-" (with dash) response?
> Test #3 - Find the Timeout period for a non-responsive DATA command.
> Test #4- Keep the client alive for over 6 minutes.
> 
> In test #1 and #2, I found out Outlook requires the dash 
> version of the
> continuation.
> 
> So test #1 failed:
> 
>     C: DATA
>     S: 354 Start mail input; end with <CRLF>.<CRLF>
>     S: 150 Please Wait
> 
> As soon as Outlook saw the "150 " (w/ space) response, a 
> Popup Error was
> displayed.
> 
> The "150-" was required, so test #2 was successful:
> 
>     C: DATA
>     S: 354 Start mail input; end with <CRLF>.<CRLF>
>     S: 150-Please Wait
>     S: 250 Message accepted for delivery. (bytes: 2573)
>     C: QUIT
> 
> Outlook accepted the "150-" without any error and waited for the 250
> response.
> 
> For Test #3, I wanted to see what was the timeout when 
> Outlook did not get
> any response.
> 
> To quickly test this, I created a DATA callout with a passive (silent)
> delay:
> 
>         for (int n = 0; n < 10; n++) {
>             Sleep(40000);  // sleep 40 seconds
>         }
> 
> This would be a total delay of 6 minutes and 40 seconds.
> 
> Within 1 minute, Outlook popped up an "Timeout" error dialog.
> 
> So in Test #4, I changed the callout to issue the "150-" 
> response between
> delays:
> 
>         for (int n = 0; n < 10; n++) {
>             Send("150-Hello There #%d\r\n",n);
>             Sleep(40000);  // sleep 40 seconds
>         }
> 
> Eureka!!
> 
> I was able to keep Outlook alive for the entire duration!  No errors!
> 
> Here is the conversation and the 40 second time intervals:
> 
> 16:39:48 C: DATA
> 16:39:48 S: 354 Start mail input; end with <CRLF>.<CRLF>
> 16:39:48 S: 150-Hello there #0.
> 16:40:28 S: 150-Hello there #1.
> 16:41:08 S: 150-Hello there #2.
> 16:41:48 S: 150-Hello there #3.
> 16:42:28 S: 150-Hello there #4.
> 16:43:08 S: 150-Hello there #5.
> 16:43:48 S: 150-Hello there #6.
> 16:44:28 S: 150-Hello there #7.
> 16:45:08 S: 150-Hello there #8.
> 16:45:48 S: 150-Hello there #9.
> 16:46:28 S: 250 Message accepted for delivery. (bytes: 2573)
> 16:46:28 C: QUIT
> 
> This is great news!  It will add life to extended 
> applications simply by
> keeping the client alive using the 1xx response code.
> 
> Of course, this has to be tested with other mail clients/MUAs.
> 
> And of course, in my opinion,  if we expect an increase of 
> such activity,
> then there should be some
> recommendation for the maximum wait time. It should not a 
> "Forever Thing."
> 
> Sincerely,
> 
> Hector Santos, CTO
> Santronics Software, Inc.
> http://www.santronics.com
> 305-431-2846 Cell
> 305-248-3204 Office
> 
> 
> ----- Original Message -----
> From: "Hector Santos" <[email protected]>
> To: "Tony Finch" <[email protected]>; "The Purple Streak, Hilarie Orman"
> <[email protected]>
> Cc: <[email protected]>
> Sent: Wednesday, February 02, 2005 2:32 PM
> Subject: Re: Activation points and callout modes
> 
> 
> > ....
> > We can probably do the same thing for SMTP.
> >
> > A integrated OPES callout can issue continuation lines at a 
> particular
> state
> > to help prevent a timeout.  I wonder if the 1xx can be used 
> here. The RFC
> > 2821 specs say:
> >
> >   1yz   Positive Preliminary reply
> >
> >       The command has been accepted, but the requested 
> action is being
> >       held in abeyance, pending confirmation of the 
> information in this
> >       reply.  The SMTP client should send another command specifying
> >       whether to continue or abort the action.  Note: 
> unextended SMTP
> >       does not have any commands that allow this type of 
> reply, and so
> >       does not have continue or abort commands.
> >
> > So I can see the following examples:
> >
> >     150-Process OPES Callout. Please wait....
> >     150-Process OPES Callout. Please wait....
> >     150-Process OPES Callout. Please wait....
> >     150-Process OPES Callout. Please wait....
> >     250 Accepted Message
> >
> >     150-Process OPES Callout. Please wait....
> >     150-Process OPES Callout. Please wait....
> >     150-Process OPES Callout. Please wait....
> >     150-Process OPES Callout. Please wait....
> >     550 Sorry Message not acceptable.
> >
> > The only issue I see is that I think some servers will 
> expect the same
> > response code on each line.
> >
> > I think it is worth while to explore this, and if need be 
> the OPES specs
> > provide an 2821 Update provision to make it work.
> >
> > Sincerely,
> >
> > Hector Santos, CTO
> > Santronics Software, Inc.
> > http://www.santronics.com
> > 305-431-2846 Cell
> > 305-248-3204 Office
> >
> >
> >
> > ----- Original Message -----
> > From: "Tony Finch" <[email protected]>
> > To: "The Purple Streak, Hilarie Orman" <[email protected]>
> > Cc: <[email protected]>
> > Sent: Wednesday, February 02, 2005 1:02 PM
> > Subject: RE: Activation points and callout modes
> >
> >
> > >
> > > On Wed, 2 Feb 2005, The Purple Streak, Hilarie Orman wrote:
> > > >
> > > > An implementation can certainly cache a message during 
> simultaneous
> > > > receive/send and defer storage until it is clear that 
> the delivery
> > > > won't complete?
> > >
> > > In principle, yes, but timeouts become much more likely 
> (e.g. because of
> > > anti-spam measures on the next hop server) which greatly 
> increases the
> > > likelihood of accidental message duplication. There's a 
> huge amout of
> > > added complexity if the message has multiple recipients 
> and the MTA
> isn't
> > > relaying to a single destination.
> > >
> > > Tony.
> > > --
> > > f.a.n.finch  <[email protected]>  http://dotat.at/
> > > DOGGER FISHER GERMAN BIGHT: WEST OR NORTHWEST 5 OR 6, 
> DECREASING 4.
> > OCCASIONAL
> > > DRIZZLE. MODERATE OR GOOD.
> > >
> > >
> >
> >
> >
>