Hi Tony,
In practice, SMTP clients also follow the specs from a timeout perspective,
which I believe the current recommendation is 5 minutes depending on the
state.
But in any case, for us, one of the anti-spoof callout features we added was
the CBV (call back verifier). Over time, we discovered we needed to offer
an option to set a lower timeout for the SMTP-based CBV callout. I believe
it was set to 1 minute by default and since then, we have not had report of
problems with this CBV setting.
Hmmm, I just thought of this. Here is an suggestion to solve this problem.
In our FTP server, we had a similar callout timeout problem.
Not to get into details, the general issue was that most, if not all, FTP
clients (per FTP specifications) will timeout if it doesn't get a DATA
channel response within X seconds for file transfers (in particular
uploads). This was discovered to be around 30-35 seconds.
FTP servers which have a 1 to 1 upload to storage location design do not see
this problem.
For a virtual FTP server like ours, a large upload (150 megs or larger), our
FTP server will move the uploaded file from temporary storage to a final
backend operator defined storage location. The FTP server can be in New
York City, and a virtual directory setup in a file server in Japan!
But even with a LAN, if a virtual directory was defined with a storage
location across the network machines, this creating the potential a huge
network I/O delays and thus a delay in the FTP server response to the FTP
client as the server was copying/moving the file to permanent storage.
As a result, the FTP Client (again, per FTP RFC specification) assumed a
TIMEOUT and closed the connection socket. This timeout is about 30-35
seconds after the final block is sent by the client and was now in a state
waiting for the final FTP server file transfer (PUT) response.
In order to solve this problem, we issue a FTP client response as a continue
line. So the client would see this:
226-Processing file please wait (10 megs...)
226-Processing file please wait (20 megs...)
226-Processing file please wait (30 megs...)
226-Processing file please wait (40 megs...)
226-Processing file please wait (50 megs...)
....
226 Transfer complete (150.4 K/s).
This solved the timeout problem for the FTP client expecting a response
within 30/35 seconds. The problem was generic to most FTP clients and this
solution solved it across the board.
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.