Hector Santos wrote:
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.