On Tue, 10 Apr 2007, David F. Skoll wrote:
Hector Santos wrote:
C: DATA
S: 352 Begin sending your data
[client uploads data]
S: 150-DKIM signature found!
S: 150-Please wait while we process your DKIM message!
S: 150-Waiting for trust server to respond...
S: 150-Still waiting for trust server to respond...
C: 550-Sorry, The DKIM POLICY has failed this transaction
C: 550 Please see http://trust-r-us.com/msgid=123213123
This is what the RFC says about timeouts:
An SMTP client MUST provide a timeout mechanism. It MUST use per-
command timeouts rather than somehow trying to time the entire mail
transaction. Timeouts SHOULD be easily reconfigurable, preferably
without recompiling the SMTP code. To implement this, a timer is set
for each SMTP command and for each buffer of the data transfer. The
latter means that the overall timeout is inherently proportional to
the size of the message.
It says the client MUST user per-command timeouts, so I don't see how
a server can expect to increase a client's timeout by providing parts
of a multiline response. My understanding is that the timeout starts
when the command has been transmitted, and stops when the timer expires
or the complete reply code has been received. The only exception (as
noted in the RFC) is the Data Block timeout.
I really don't think we want to bless this (mis-)use of 150 in a revision
to RFC 2821, even if it is only in an example in a MAY section.
As with any may one of the issues would be inability to tell if client
would or would not support this. SMTP protocol is not very good at
negotiation of capabilities ("good" is in the eye of ... what I mean
is that some advanced functionalities that other protocols have are
not there) and it also does not properly support bi-directional
communication, i.e. it would have been nice if in above case client
could tell "I'm tired of waiting for your full reply, in 2 seconds
I'll close connection and will retry this message later".
One other thing to note about above, the SMTP text states that
DATA Termination: 10 minutes.
This is while awaiting the "250 OK" reply.
So personally I think if server needs to wait more then 10 minutes
to give reply to DATA, it should just go ahead and give 45x reply
(but feel free to put 100 codes as in your example to say what
server is doing).
BTW, I always thought it would be neat (for greylisting for example) to
have capability for SMTP server to tell client to retry and specify how
long after current time it should/can retry. For above case it
would mean after 10 minutes it could give shorter reply and cache
the data about previous message so next time server attempts to deliver
this message it would know how to answer.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net