Murray S. Kucherawy wrote:
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Mark Delany
Sent: Thursday, October 29, 2009 9:42 AM
To: dcrocker(_at_)bbiw(_dot_)net
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] DKIM on envelope level
If the proposal is an attempt to reduce SMTP bandwidth, which is
becoming a vanishingly small part of Internet traffic for most sites
anyway, then stopping after DATA doesn't help as your OS will have
likely received a socket buffer full of data, even if the application
doesn't read it. So it might make you feel good, but it doesn't reduce
the bytes coming down the line consequentially.
Do you mean the server's side of the connection will have buffer data in it?
That would mean the client sent DATA<CR><LF> followed by header/body
information, possibly even in the same packet, without waiting for the reply
from DATA. The server could drop the connection outright in that case for
violating SMTP rules, even with support for PIPELINING which as I recall
requires a synchronization point at DATA. This wouldn't reduce pipe
bandwidth consumption (if that's the goal) but it could reduce resource
consumption at MTAs.
Not always.
If a HALF CLOSE is done
shutdown(socket,SD_SENT)
there will be some remaining buffer. Half Close is the recommended way
to shutdown a TCP session.[1]
It could be just QUIT<cr><lf> remaining in the buffer.
You can test this now but creating a DATA shim that receives the
payload but delays for 3-5 minutes before a response. The Server can
wait for a client connection drop and read the remaining buffer.
We use this to resolve the SMTP Specification NO-QUIT-CANCEL found in
sites that have lengthy DATA filtering scripts. The client did its
part of sending the data and is waiting for the server response. It
doesn't come, so it issues a QUIT and drops the socket. This is
detectable. The server should see if a QUIT was issued before
cancelling the transaction
The point is, that the client is not designed to wait in sending
partial data via SMTP state machine. The SMTP server can not drop
because there is an implicit 451 reply code interpretation by the
client [2].
--
HLS
[1] TCP/IP Illustrated Volume 1, The Protocols. Pages 233, 238.
[2] RFC 5321 Section 3.8. Terminating Sessions and Connections
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html