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:hsantos(_at_)santronics(_dot_)com]
Sent: Wednesday, February 02, 2005 5:08 PM
To: Tony Finch; The Purple Streak, Hilarie Orman
Cc: ietf-openproxy(_at_)imc(_dot_)org
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" <hsantos(_at_)santronics(_dot_)com>
To: "Tony Finch" <dot(_at_)dotat(_dot_)at>; "The Purple Streak, Hilarie Orman"
<ho(_at_)alum(_dot_)mit(_dot_)edu>
Cc: <ietf-openproxy(_at_)imc(_dot_)org>
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" <dot(_at_)dotat(_dot_)at>
To: "The Purple Streak, Hilarie Orman" <ho(_at_)alum(_dot_)mit(_dot_)edu>
Cc: <ietf-openproxy(_at_)imc(_dot_)org>
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 <dot(_at_)dotat(_dot_)at> http://dotat.at/
DOGGER FISHER GERMAN BIGHT: WEST OR NORTHWEST 5 OR 6,
DECREASING 4.
OCCASIONAL
DRIZZLE. MODERATE OR GOOD.